diff mbox series

[net-next,v3,12/12] dt-bindings: net: add Microchip's LAN865X 10BASE-T1S MACPHY

Message ID 20240306085017.21731-13-Parthiban.Veerasooran@microchip.com
State Changes Requested
Headers show
Series Add support for OPEN Alliance 10BASE-T1x MACPHY Serial Interface | expand

Checks

Context Check Description
robh/checkpatch success
robh/patch-applied success
robh/dtbs-check warning build log
robh/dt-meta-schema success

Commit Message

Parthiban Veerasooran March 6, 2024, 8:50 a.m. UTC 
The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
PHY to enable 10BASE-T1S networks. The Ethernet Media Access Controller
(MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
integrated into the LAN8650/1. The communication between the Host and the
MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
Interface (TC6).

Signed-off-by: Parthiban Veerasooran <Parthiban.Veerasooran@microchip.com>
---
 .../bindings/net/microchip,lan865x.yaml       | 80 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 2 files changed, 81 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/microchip,lan865x.yaml

Comments

Conor Dooley March 6, 2024, 6:16 p.m. UTC | #1 
On Wed, Mar 06, 2024 at 02:20:17PM +0530, Parthiban Veerasooran wrote:
> The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
> PHY to enable 10BASE-T1S networks. The Ethernet Media Access Controller
> (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
> with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
> integrated into the LAN8650/1. The communication between the Host and the
> MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
> Interface (TC6).
> 
> Signed-off-by: Parthiban Veerasooran <Parthiban.Veerasooran@microchip.com>
> ---
>  .../bindings/net/microchip,lan865x.yaml       | 80 +++++++++++++++++++
>  MAINTAINERS                                   |  1 +
>  2 files changed, 81 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/microchip,lan865x.yaml
> 
> diff --git a/Documentation/devicetree/bindings/net/microchip,lan865x.yaml b/Documentation/devicetree/bindings/net/microchip,lan865x.yaml
> new file mode 100644
> index 000000000000..ee52f9d8e93c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/microchip,lan865x.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/microchip,lan865x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip LAN8650/1 10BASE-T1S MACPHY Ethernet Controllers
> +
> +maintainers:
> +  - Parthiban Veerasooran <parthiban.veerasooran@microchip.com>
> +
> +description:
> +  The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
> +  PHY to enable 10BASE‑T1S networks. The Ethernet Media Access Controller
> +  (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
> +  with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
> +  integrated into the LAN8650/1. The communication between the Host and
> +  the MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
> +  Interface (TC6).
> +
> +allOf:
> +  - $ref: ethernet-controller.yaml#
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - items:
> +          - const: microchip,lan8650
> +          - const: microchip,lan8651

The order here is wrong, lan8561 needs to come before the fallback of
lan8650.

> +      - enum:
> +          - microchip,lan8650
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    description:
> +      Interrupt from MAC-PHY asserted in the event of Receive Chunks
> +      Available, Transmit Chunk Credits Available and Extended Status
> +      Event.
> +    maxItems: 1
> +
> +  spi-max-frequency:
> +    minimum: 15000000
> +    maximum: 25000000

You're missing a reference to spi-peripheral-props where this property
is defined.

Thanks,
Conor.
Andrew Lunn March 6, 2024, 6:48 p.m. UTC | #2 
> > +description:
> > +  The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
> > +  PHY to enable 10BASE‑T1S networks. The Ethernet Media Access Controller
> > +  (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
> > +  with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
> > +  integrated into the LAN8650/1. The communication between the Host and
> > +  the MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
> > +  Interface (TC6).
> > +
> > +allOf:
> > +  - $ref: ethernet-controller.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    oneOf:
> > +      - items:
> > +          - const: microchip,lan8650
> > +          - const: microchip,lan8651
> 
> The order here is wrong, lan8561 needs to come before the fallback of
> lan8650.

I don't think it is a fallback. There are two devices, and hence two
different compatibles. So i suspect the -items: is wrong here?

	  Andrew
Conor Dooley March 6, 2024, 7:01 p.m. UTC | #3 
On Wed, Mar 06, 2024 at 07:48:57PM +0100, Andrew Lunn wrote:
> > > +description:
> > > +  The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
> > > +  PHY to enable 10BASE‑T1S networks. The Ethernet Media Access Controller
> > > +  (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
> > > +  with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
> > > +  integrated into the LAN8650/1. The communication between the Host and
> > > +  the MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
> > > +  Interface (TC6).
> > > +
> > > +allOf:
> > > +  - $ref: ethernet-controller.yaml#
> > > +
> > > +properties:
> > > +  compatible:
> > > +    oneOf:
> > > +      - items:
> > > +          - const: microchip,lan8650
> > > +          - const: microchip,lan8651
> > 
> > The order here is wrong, lan8561 needs to come before the fallback of
> > lan8650.
> 
> I don't think it is a fallback. There are two devices, and hence two
> different compatibles. So i suspect the -items: is wrong here?

It'd just be a two entry enum then, but I did take a quick look at the
driver earlier and saw:
+static const struct of_device_id lan865x_dt_ids[] = {
+	{ .compatible = "microchip,lan8650" },
+	{ .compatible = "microchip,lan8651" },
+	{ /* Sentinel */ }
+};

That, along with no other of_device_is_compatible() type operations
made me think that having a fallback actually was suitable.

You cropped it out, but the patch had:
> +  compatible:
> +    oneOf:
> +      - items:
> +          - const: microchip,lan8650
> +          - const: microchip,lan8651
> +      - enum:
> +          - microchip,lan8650

So it doesn't appear to be an accidental items in place of an enum,
since the other compatible is in another enum.

I just noticed also that that enum should actually be const, so I'd
expect this to be:
  compatible:
    oneOf:
      - items:
          - const: microchip,lan8651
          - const: microchip,lan8650

      - const: microchip,lan8650
Parthiban Veerasooran March 20, 2024, 8:40 a.m. UTC | #4 
Hi Conor & Andrew,

Please find my reply below by consolidating other two emails comments 
related to this.

On 07/03/24 12:31 am, Conor Dooley wrote:
> On Wed, Mar 06, 2024 at 07:48:57PM +0100, Andrew Lunn wrote:
>>>> +description:
>>>> +  The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
>>>> +  PHY to enable 10BASE‑T1S networks. The Ethernet Media Access Controller
>>>> +  (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
>>>> +  with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
>>>> +  integrated into the LAN8650/1. The communication between the Host and
>>>> +  the MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
>>>> +  Interface (TC6).
>>>> +
>>>> +allOf:
>>>> +  - $ref: ethernet-controller.yaml#
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    oneOf:
>>>> +      - items:
>>>> +          - const: microchip,lan8650
>>>> +          - const: microchip,lan8651
>>> The order here is wrong, lan8561 needs to come before the fallback of
>>> lan8650.
>> I don't think it is a fallback. There are two devices, and hence two
>> different compatibles. So i suspect the -items: is wrong here?
> It'd just be a two entry enum then, but I did take a quick look at the
> driver earlier and saw:
> +static const struct of_device_id lan865x_dt_ids[] = {
> +	{ .compatible = "microchip,lan8650" },
> +	{ .compatible = "microchip,lan8651" },
> +	{ /* Sentinel */ }
> +};
> 
> That, along with no other of_device_is_compatible() type operations
> made me think that having a fallback actually was suitable.
> 
> You cropped it out, but the patch had:
>> +  compatible:
>> +    oneOf:
>> +      - items:
>> +          - const: microchip,lan8650
>> +          - const: microchip,lan8651
>> +      - enum:
>> +          - microchip,lan8650
> So it doesn't appear to be an accidental items in place of an enum,
> since the other compatible is in another enum.
As per Andrew's comment in another email, both LAN8650 and LAN8651 are 
two different variants but they both share almost all characteristics 
except one thing that is LAN8651 has "Single 3.3V supply with integrated 
1.8V regulator" which doesn't have anything to do with driver. That's 
why I have kept them as fallback as Conor said in this email. Hope you 
all OK with this.
> 
> I just noticed also that that enum should actually be const, so I'd
> expect this to be:
>    compatible:
>      oneOf:
>        - items:
>            - const: microchip,lan8651
>            - const: microchip,lan8650
> 
>        - const: microchip,lan8650
OK, I will update this in the next version.

Best regards,
Parthiban V
Parthiban Veerasooran March 20, 2024, 8:40 a.m. UTC | #5 
Hi Conor,

On 06/03/24 11:46 pm, Conor Dooley wrote:
> On Wed, Mar 06, 2024 at 02:20:17PM +0530, Parthiban Veerasooran wrote:
>> The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
>> PHY to enable 10BASE-T1S networks. The Ethernet Media Access Controller
>> (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
>> with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
>> integrated into the LAN8650/1. The communication between the Host and the
>> MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
>> Interface (TC6).
>>
>> Signed-off-by: Parthiban Veerasooran<Parthiban.Veerasooran@microchip.com>
>> ---
>>   .../bindings/net/microchip,lan865x.yaml       | 80 +++++++++++++++++++
>>   MAINTAINERS                                   |  1 +
>>   2 files changed, 81 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/net/microchip,lan865x.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/net/microchip,lan865x.yaml b/Documentation/devicetree/bindings/net/microchip,lan865x.yaml
>> new file mode 100644
>> index 000000000000..ee52f9d8e93c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/microchip,lan865x.yaml
>> @@ -0,0 +1,80 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id:http://devicetree.org/schemas/net/microchip,lan865x.yaml#
>> +$schema:http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip LAN8650/1 10BASE-T1S MACPHY Ethernet Controllers
>> +
>> +maintainers:
>> +  - Parthiban Veerasooran<parthiban.veerasooran@microchip.com>
>> +
>> +description:
>> +  The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
>> +  PHY to enable 10BASE‑T1S networks. The Ethernet Media Access Controller
>> +  (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
>> +  with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
>> +  integrated into the LAN8650/1. The communication between the Host and
>> +  the MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
>> +  Interface (TC6).
>> +
>> +allOf:
>> +  - $ref: ethernet-controller.yaml#
>> +
>> +properties:
>> +  compatible:
>> +    oneOf:
>> +      - items:
>> +          - const: microchip,lan8650
>> +          - const: microchip,lan8651
> The order here is wrong, lan8561 needs to come before the fallback of
> lan8650.
Reply to this comment is in another email.
> 
>> +      - enum:
>> +          - microchip,lan8650
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  interrupts:
>> +    description:
>> +      Interrupt from MAC-PHY asserted in the event of Receive Chunks
>> +      Available, Transmit Chunk Credits Available and Extended Status
>> +      Event.
>> +    maxItems: 1
>> +
>> +  spi-max-frequency:
>> +    minimum: 15000000
>> +    maximum: 25000000
> You're missing a reference to spi-peripheral-props where this property
> is defined.
OK, I will add the below line in the above "allOf" section.

- $ref: /schemas/spi/spi-peripheral-props.yaml#

Best regards,
Parthiban V
> 
> Thanks,
> Conor.
Krzysztof Kozlowski March 20, 2024, 9:53 a.m. UTC | #6 
On 20/03/2024 09:40, Parthiban.Veerasooran@microchip.com wrote:
> Hi Conor & Andrew,
> 
> Please find my reply below by consolidating other two emails comments 
> related to this.
> 
> On 07/03/24 12:31 am, Conor Dooley wrote:
>> On Wed, Mar 06, 2024 at 07:48:57PM +0100, Andrew Lunn wrote:
>>>>> +description:
>>>>> +  The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
>>>>> +  PHY to enable 10BASE‑T1S networks. The Ethernet Media Access Controller
>>>>> +  (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
>>>>> +  with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
>>>>> +  integrated into the LAN8650/1. The communication between the Host and
>>>>> +  the MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
>>>>> +  Interface (TC6).
>>>>> +
>>>>> +allOf:
>>>>> +  - $ref: ethernet-controller.yaml#
>>>>> +
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    oneOf:
>>>>> +      - items:
>>>>> +          - const: microchip,lan8650
>>>>> +          - const: microchip,lan8651
>>>> The order here is wrong, lan8561 needs to come before the fallback of
>>>> lan8650.
>>> I don't think it is a fallback. There are two devices, and hence two
>>> different compatibles. So i suspect the -items: is wrong here?
>> It'd just be a two entry enum then, but I did take a quick look at the
>> driver earlier and saw:
>> +static const struct of_device_id lan865x_dt_ids[] = {
>> +	{ .compatible = "microchip,lan8650" },
>> +	{ .compatible = "microchip,lan8651" },
>> +	{ /* Sentinel */ }
>> +};
>>
>> That, along with no other of_device_is_compatible() type operations
>> made me think that having a fallback actually was suitable.
>>
>> You cropped it out, but the patch had:
>>> +  compatible:
>>> +    oneOf:
>>> +      - items:
>>> +          - const: microchip,lan8650
>>> +          - const: microchip,lan8651
>>> +      - enum:
>>> +          - microchip,lan8650
>> So it doesn't appear to be an accidental items in place of an enum,
>> since the other compatible is in another enum.
> As per Andrew's comment in another email, both LAN8650 and LAN8651 are 
> two different variants but they both share almost all characteristics 
> except one thing that is LAN8651 has "Single 3.3V supply with integrated 
> 1.8V regulator" which doesn't have anything to do with driver. That's 

So why this is not reflected in your driver? Why didn't you address that
part, but ignored?

> why I have kept them as fallback as Conor said in this email. Hope you 
> all OK with this.

Did you read the feedback? Your response is not solving here anything.
How 8650 can be used twice? Please point me to DTS showing both usages.

Best regards,
Krzysztof
Parthiban Veerasooran March 21, 2024, 8:38 a.m. UTC | #7 
Hi Krzysztof,

On 20/03/24 3:23 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 20/03/2024 09:40, Parthiban.Veerasooran@microchip.com wrote:
>> Hi Conor & Andrew,
>>
>> Please find my reply below by consolidating other two emails comments
>> related to this.
>>
>> On 07/03/24 12:31 am, Conor Dooley wrote:
>>> On Wed, Mar 06, 2024 at 07:48:57PM +0100, Andrew Lunn wrote:
>>>>>> +description:
>>>>>> +  The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
>>>>>> +  PHY to enable 10BASE‑T1S networks. The Ethernet Media Access Controller
>>>>>> +  (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
>>>>>> +  with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
>>>>>> +  integrated into the LAN8650/1. The communication between the Host and
>>>>>> +  the MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
>>>>>> +  Interface (TC6).
>>>>>> +
>>>>>> +allOf:
>>>>>> +  - $ref: ethernet-controller.yaml#
>>>>>> +
>>>>>> +properties:
>>>>>> +  compatible:
>>>>>> +    oneOf:
>>>>>> +      - items:
>>>>>> +          - const: microchip,lan8650
>>>>>> +          - const: microchip,lan8651
>>>>> The order here is wrong, lan8561 needs to come before the fallback of
>>>>> lan8650.
>>>> I don't think it is a fallback. There are two devices, and hence two
>>>> different compatibles. So i suspect the -items: is wrong here?
>>> It'd just be a two entry enum then, but I did take a quick look at the
>>> driver earlier and saw:
>>> +static const struct of_device_id lan865x_dt_ids[] = {
>>> +    { .compatible = "microchip,lan8650" },
>>> +    { .compatible = "microchip,lan8651" },
>>> +    { /* Sentinel */ }
>>> +};
>>>
>>> That, along with no other of_device_is_compatible() type operations
>>> made me think that having a fallback actually was suitable.
>>>
>>> You cropped it out, but the patch had:
>>>> +  compatible:
>>>> +    oneOf:
>>>> +      - items:
>>>> +          - const: microchip,lan8650
>>>> +          - const: microchip,lan8651
>>>> +      - enum:
>>>> +          - microchip,lan8650
>>> So it doesn't appear to be an accidental items in place of an enum,
>>> since the other compatible is in another enum.
>> As per Andrew's comment in another email, both LAN8650 and LAN8651 are
>> two different variants but they both share almost all characteristics
>> except one thing that is LAN8651 has "Single 3.3V supply with integrated
>> 1.8V regulator" which doesn't have anything to do with driver. That's
> 
> So why this is not reflected in your driver? Why didn't you address that
> part, but ignored?
No, it is not ignored. This difference is specific to hardware and there 
is no configuration/setting to be done from driver.
> 
>> why I have kept them as fallback as Conor said in this email. Hope you
>> all OK with this.
> 
> Did you read the feedback? Your response is not solving here anything.
> How 8650 can be used twice? Please point me to DTS showing both usages.
May be I have a misunderstanding here. Let's clarify it.

LAN8650 and LAN8651 both are two different variants but both implements 
same functionality. The only difference is LAN8651 has "Single 3.3V 
supply with integrated" where LAN8650 doesn't have this. This is 
hardware specific difference and there is no configuration/setting to be 
done in the driver specific to this difference in the LAN8651. So 
basically the driver can support for both variants without any 
additional settings.

LAN8650: https://www.microchip.com/en-us/product/lan8650
LAN8651: https://www.microchip.com/en-us/product/lan8651

The below link shows the difference between them,
https://www.microchip.com/en-us/product-comparison.lan8650.lan8651

With the above details, I would change the microchip,lan865x.yaml with 
the below details.

compatible:
   enum:
     - microchip,lan8650
     - microchip,lan8651

And in the lan865x.c, I would remove the below line because
.compatible = "microchip,lan8650" already supports for LAN8651 as well.

.compatible = "microchip,lan8651"

Let me know your opinion on this proposal? or do you have any 
misunderstanding here?

Best regards,
Parthiban V

> 
> Best regards,
> Krzysztof
> 
>
Krzysztof Kozlowski March 21, 2024, 8:40 a.m. UTC | #8 
On 21/03/2024 09:38, Parthiban.Veerasooran@microchip.com wrote:
> Hi Krzysztof,
> 
> On 20/03/24 3:23 pm, Krzysztof Kozlowski wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> On 20/03/2024 09:40, Parthiban.Veerasooran@microchip.com wrote:
>>> Hi Conor & Andrew,
>>>
>>> Please find my reply below by consolidating other two emails comments
>>> related to this.
>>>
>>> On 07/03/24 12:31 am, Conor Dooley wrote:
>>>> On Wed, Mar 06, 2024 at 07:48:57PM +0100, Andrew Lunn wrote:
>>>>>>> +description:
>>>>>>> +  The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
>>>>>>> +  PHY to enable 10BASE‑T1S networks. The Ethernet Media Access Controller
>>>>>>> +  (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
>>>>>>> +  with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
>>>>>>> +  integrated into the LAN8650/1. The communication between the Host and
>>>>>>> +  the MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
>>>>>>> +  Interface (TC6).
>>>>>>> +
>>>>>>> +allOf:
>>>>>>> +  - $ref: ethernet-controller.yaml#
>>>>>>> +
>>>>>>> +properties:
>>>>>>> +  compatible:
>>>>>>> +    oneOf:
>>>>>>> +      - items:
>>>>>>> +          - const: microchip,lan8650
>>>>>>> +          - const: microchip,lan8651
>>>>>> The order here is wrong, lan8561 needs to come before the fallback of
>>>>>> lan8650.
>>>>> I don't think it is a fallback. There are two devices, and hence two
>>>>> different compatibles. So i suspect the -items: is wrong here?
>>>> It'd just be a two entry enum then, but I did take a quick look at the
>>>> driver earlier and saw:
>>>> +static const struct of_device_id lan865x_dt_ids[] = {
>>>> +    { .compatible = "microchip,lan8650" },
>>>> +    { .compatible = "microchip,lan8651" },
>>>> +    { /* Sentinel */ }
>>>> +};
>>>>
>>>> That, along with no other of_device_is_compatible() type operations
>>>> made me think that having a fallback actually was suitable.
>>>>
>>>> You cropped it out, but the patch had:
>>>>> +  compatible:
>>>>> +    oneOf:
>>>>> +      - items:
>>>>> +          - const: microchip,lan8650
>>>>> +          - const: microchip,lan8651
>>>>> +      - enum:
>>>>> +          - microchip,lan8650
>>>> So it doesn't appear to be an accidental items in place of an enum,
>>>> since the other compatible is in another enum.
>>> As per Andrew's comment in another email, both LAN8650 and LAN8651 are
>>> two different variants but they both share almost all characteristics
>>> except one thing that is LAN8651 has "Single 3.3V supply with integrated
>>> 1.8V regulator" which doesn't have anything to do with driver. That's
>>
>> So why this is not reflected in your driver? Why didn't you address that
>> part, but ignored?
> No, it is not ignored. This difference is specific to hardware and there 
> is no configuration/setting to be done from driver.
>>
>>> why I have kept them as fallback as Conor said in this email. Hope you
>>> all OK with this.
>>
>> Did you read the feedback? Your response is not solving here anything.
>> How 8650 can be used twice? Please point me to DTS showing both usages.
> May be I have a misunderstanding here. Let's clarify it.
> 
> LAN8650 and LAN8651 both are two different variants but both implements 
> same functionality. The only difference is LAN8651 has "Single 3.3V 
> supply with integrated" where LAN8650 doesn't have this. This is 
> hardware specific difference and there is no configuration/setting to be 
> done in the driver specific to this difference in the LAN8651. So 
> basically the driver can support for both variants without any 
> additional settings.
> 
> LAN8650: https://www.microchip.com/en-us/product/lan8650
> LAN8651: https://www.microchip.com/en-us/product/lan8651
> 
> The below link shows the difference between them,
> https://www.microchip.com/en-us/product-comparison.lan8650.lan8651
> 
> With the above details, I would change the microchip,lan865x.yaml with 
> the below details.
> 
> compatible:
>    enum:
>      - microchip,lan8650
>      - microchip,lan8651
> 
> And in the lan865x.c, I would remove the below line because
> .compatible = "microchip,lan8650" already supports for LAN8651 as well.
> 
> .compatible = "microchip,lan8651"
> 
> Let me know your opinion on this proposal? or do you have any 
> misunderstanding here?

It's still wrong. Upstream your DTS and then test it. You will
immediately see that it does not work. So first make it working, then
send code to review.

Best regards,
Krzysztof
Parthiban Veerasooran March 21, 2024, noon UTC | #9 
Hi Krzysztof,

On 21/03/24 2:10 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 21/03/2024 09:38, Parthiban.Veerasooran@microchip.com wrote:
>> Hi Krzysztof,
>>
>> On 20/03/24 3:23 pm, Krzysztof Kozlowski wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On 20/03/2024 09:40, Parthiban.Veerasooran@microchip.com wrote:
>>>> Hi Conor & Andrew,
>>>>
>>>> Please find my reply below by consolidating other two emails comments
>>>> related to this.
>>>>
>>>> On 07/03/24 12:31 am, Conor Dooley wrote:
>>>>> On Wed, Mar 06, 2024 at 07:48:57PM +0100, Andrew Lunn wrote:
>>>>>>>> +description:
>>>>>>>> +  The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
>>>>>>>> +  PHY to enable 10BASE‑T1S networks. The Ethernet Media Access Controller
>>>>>>>> +  (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
>>>>>>>> +  with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
>>>>>>>> +  integrated into the LAN8650/1. The communication between the Host and
>>>>>>>> +  the MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
>>>>>>>> +  Interface (TC6).
>>>>>>>> +
>>>>>>>> +allOf:
>>>>>>>> +  - $ref: ethernet-controller.yaml#
>>>>>>>> +
>>>>>>>> +properties:
>>>>>>>> +  compatible:
>>>>>>>> +    oneOf:
>>>>>>>> +      - items:
>>>>>>>> +          - const: microchip,lan8650
>>>>>>>> +          - const: microchip,lan8651
>>>>>>> The order here is wrong, lan8561 needs to come before the fallback of
>>>>>>> lan8650.
>>>>>> I don't think it is a fallback. There are two devices, and hence two
>>>>>> different compatibles. So i suspect the -items: is wrong here?
>>>>> It'd just be a two entry enum then, but I did take a quick look at the
>>>>> driver earlier and saw:
>>>>> +static const struct of_device_id lan865x_dt_ids[] = {
>>>>> +    { .compatible = "microchip,lan8650" },
>>>>> +    { .compatible = "microchip,lan8651" },
>>>>> +    { /* Sentinel */ }
>>>>> +};
>>>>>
>>>>> That, along with no other of_device_is_compatible() type operations
>>>>> made me think that having a fallback actually was suitable.
>>>>>
>>>>> You cropped it out, but the patch had:
>>>>>> +  compatible:
>>>>>> +    oneOf:
>>>>>> +      - items:
>>>>>> +          - const: microchip,lan8650
>>>>>> +          - const: microchip,lan8651
>>>>>> +      - enum:
>>>>>> +          - microchip,lan8650
>>>>> So it doesn't appear to be an accidental items in place of an enum,
>>>>> since the other compatible is in another enum.
>>>> As per Andrew's comment in another email, both LAN8650 and LAN8651 are
>>>> two different variants but they both share almost all characteristics
>>>> except one thing that is LAN8651 has "Single 3.3V supply with integrated
>>>> 1.8V regulator" which doesn't have anything to do with driver. That's
>>>
>>> So why this is not reflected in your driver? Why didn't you address that
>>> part, but ignored?
>> No, it is not ignored. This difference is specific to hardware and there
>> is no configuration/setting to be done from driver.
>>>
>>>> why I have kept them as fallback as Conor said in this email. Hope you
>>>> all OK with this.
>>>
>>> Did you read the feedback? Your response is not solving here anything.
>>> How 8650 can be used twice? Please point me to DTS showing both usages.
>> May be I have a misunderstanding here. Let's clarify it.
>>
>> LAN8650 and LAN8651 both are two different variants but both implements
>> same functionality. The only difference is LAN8651 has "Single 3.3V
>> supply with integrated" where LAN8650 doesn't have this. This is
>> hardware specific difference and there is no configuration/setting to be
>> done in the driver specific to this difference in the LAN8651. So
>> basically the driver can support for both variants without any
>> additional settings.
>>
>> LAN8650: https://www.microchip.com/en-us/product/lan8650
>> LAN8651: https://www.microchip.com/en-us/product/lan8651
>>
>> The below link shows the difference between them,
>> https://www.microchip.com/en-us/product-comparison.lan8650.lan8651
>>
>> With the above details, I would change the microchip,lan865x.yaml with
>> the below details.
>>
>> compatible:
>>     enum:
>>       - microchip,lan8650
>>       - microchip,lan8651
>>
>> And in the lan865x.c, I would remove the below line because
>> .compatible = "microchip,lan8650" already supports for LAN8651 as well.
>>
>> .compatible = "microchip,lan8651"
>>
>> Let me know your opinion on this proposal? or do you have any
>> misunderstanding here?
> 
> It's still wrong. Upstream your DTS and then test it. You will
> immediately see that it does not work. So first make it working, then
> send code to review.
Sorry for the inconvenience. I did the below changes in my 
microchip,lan865x.yaml file and executed dt_binding_check. It 
successfully created the microchip,lan865x.example.dts without any 
errors. Herewith I have attached the updated microchip,lan865x.yaml file 
and the generated microchip,lan865x.example.dts file for your reference.

properties:
   compatible:
     oneOf:
       - items:
           - const: microchip,lan8651
           - const: microchip,lan8650
....

       ethernet@0 {
         compatible = "microchip,lan8651", "microchip,lan8650";
         reg = <0>;
         pinctrl-names = "default";
         pinctrl-0 = <&eth0_pins>;
         interrupt-parent = <&gpio>;
         interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
         local-mac-address = [04 05 06 01 02 03];
         spi-max-frequency = <15000000>;
       };

LAN8650 is the fallback here as the driver uses the compatible string as 
"microchip,lan8650". I am using LAN8651 in my RPI4 test setup. So I 
added the below compatible string

compatible = "microchip,lan8651", "microchip,lan8650"

in my RPI 4 DT overlay file and tested in my RPI 4 test setup and it 
worked well.

Herewith I have attached my RPI 4 dt overlay file lan8651-overlay.dts 
for your reference.

Hope this is OK now?

Best regards,
Parthiban V
> 
> Best regards,
> Krzysztof
> 
>
Conor Dooley March 21, 2024, 3:34 p.m. UTC | #10 
On Thu, Mar 21, 2024 at 12:00:56PM +0000, Parthiban.Veerasooran@microchip.com wrote:
> Hi Krzysztof,
> 
> On 21/03/24 2:10 pm, Krzysztof Kozlowski wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > On 21/03/2024 09:38, Parthiban.Veerasooran@microchip.com wrote:
> >> Hi Krzysztof,
> >>
> >> On 20/03/24 3:23 pm, Krzysztof Kozlowski wrote:
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>
> >>> On 20/03/2024 09:40, Parthiban.Veerasooran@microchip.com wrote:
> >>>> Hi Conor & Andrew,
> >>>>
> >>>> Please find my reply below by consolidating other two emails comments
> >>>> related to this.
> >>>>
> >>>> On 07/03/24 12:31 am, Conor Dooley wrote:
> >>>>> On Wed, Mar 06, 2024 at 07:48:57PM +0100, Andrew Lunn wrote:
> >>>>>>>> +description:
> >>>>>>>> +  The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
> >>>>>>>> +  PHY to enable 10BASE‑T1S networks. The Ethernet Media Access Controller
> >>>>>>>> +  (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
> >>>>>>>> +  with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
> >>>>>>>> +  integrated into the LAN8650/1. The communication between the Host and
> >>>>>>>> +  the MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
> >>>>>>>> +  Interface (TC6).
> >>>>>>>> +
> >>>>>>>> +allOf:
> >>>>>>>> +  - $ref: ethernet-controller.yaml#
> >>>>>>>> +
> >>>>>>>> +properties:
> >>>>>>>> +  compatible:
> >>>>>>>> +    oneOf:
> >>>>>>>> +      - items:
> >>>>>>>> +          - const: microchip,lan8650
> >>>>>>>> +          - const: microchip,lan8651
> >>>>>>> The order here is wrong, lan8561 needs to come before the fallback of
> >>>>>>> lan8650.
> >>>>>> I don't think it is a fallback. There are two devices, and hence two
> >>>>>> different compatibles. So i suspect the -items: is wrong here?
> >>>>> It'd just be a two entry enum then, but I did take a quick look at the
> >>>>> driver earlier and saw:
> >>>>> +static const struct of_device_id lan865x_dt_ids[] = {
> >>>>> +    { .compatible = "microchip,lan8650" },
> >>>>> +    { .compatible = "microchip,lan8651" },
> >>>>> +    { /* Sentinel */ }
> >>>>> +};
> >>>>>
> >>>>> That, along with no other of_device_is_compatible() type operations
> >>>>> made me think that having a fallback actually was suitable.
> >>>>>
> >>>>> You cropped it out, but the patch had:
> >>>>>> +  compatible:
> >>>>>> +    oneOf:
> >>>>>> +      - items:
> >>>>>> +          - const: microchip,lan8650
> >>>>>> +          - const: microchip,lan8651
> >>>>>> +      - enum:
> >>>>>> +          - microchip,lan8650
> >>>>> So it doesn't appear to be an accidental items in place of an enum,
> >>>>> since the other compatible is in another enum.
> >>>> As per Andrew's comment in another email, both LAN8650 and LAN8651 are
> >>>> two different variants but they both share almost all characteristics
> >>>> except one thing that is LAN8651 has "Single 3.3V supply with integrated
> >>>> 1.8V regulator" which doesn't have anything to do with driver. That's
> >>>
> >>> So why this is not reflected in your driver? Why didn't you address that
> >>> part, but ignored?
> >> No, it is not ignored. This difference is specific to hardware and there
> >> is no configuration/setting to be done from driver.
> >>>
> >>>> why I have kept them as fallback as Conor said in this email. Hope you
> >>>> all OK with this.
> >>>
> >>> Did you read the feedback? Your response is not solving here anything.
> >>> How 8650 can be used twice? Please point me to DTS showing both usages.
> >> May be I have a misunderstanding here. Let's clarify it.
> >>
> >> LAN8650 and LAN8651 both are two different variants but both implements
> >> same functionality. The only difference is LAN8651 has "Single 3.3V
> >> supply with integrated" where LAN8650 doesn't have this. This is
> >> hardware specific difference and there is no configuration/setting to be
> >> done in the driver specific to this difference in the LAN8651. So
> >> basically the driver can support for both variants without any
> >> additional settings.
> >>
> >> LAN8650: https://www.microchip.com/en-us/product/lan8650
> >> LAN8651: https://www.microchip.com/en-us/product/lan8651
> >>
> >> The below link shows the difference between them,
> >> https://www.microchip.com/en-us/product-comparison.lan8650.lan8651
> >>
> >> With the above details, I would change the microchip,lan865x.yaml with
> >> the below details.
> >>
> >> compatible:
> >>     enum:
> >>       - microchip,lan8650
> >>       - microchip,lan8651
> >>
> >> And in the lan865x.c, I would remove the below line because
> >> .compatible = "microchip,lan8650" already supports for LAN8651 as well.
> >>
> >> .compatible = "microchip,lan8651"
> >>
> >> Let me know your opinion on this proposal? or do you have any
> >> misunderstanding here?
> > 
> > It's still wrong. Upstream your DTS and then test it. You will
> > immediately see that it does not work. So first make it working, then
> > send code to review.
> Sorry for the inconvenience. I did the below changes in my 
> microchip,lan865x.yaml file and executed dt_binding_check. It 
> successfully created the microchip,lan865x.example.dts without any 
> errors. Herewith I have attached the updated microchip,lan865x.yaml file 
> and the generated microchip,lan865x.example.dts file for your reference.
> 
> properties:
>    compatible:
>      oneOf:
>        - items:
>            - const: microchip,lan8651
>            - const: microchip,lan8650

No, this is not right either. You need to also allow the lan8650 on its
own. All you had to do with the original items list was flip the order
of the lan8650 and lan8651.
Parthiban Veerasooran March 22, 2024, 6:25 a.m. UTC | #11 
Hi Conor,

On 21/03/24 9:04 pm, Conor Dooley wrote:
> On Thu, Mar 21, 2024 at 12:00:56PM +0000,Parthiban.Veerasooran@microchip.com  wrote:
>> Hi Krzysztof,
>>
>> On 21/03/24 2:10 pm, Krzysztof Kozlowski wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On 21/03/2024 09:38,Parthiban.Veerasooran@microchip.com  wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On 20/03/24 3:23 pm, Krzysztof Kozlowski wrote:
>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>>>
>>>>> On 20/03/2024 09:40,Parthiban.Veerasooran@microchip.com  wrote:
>>>>>> Hi Conor & Andrew,
>>>>>>
>>>>>> Please find my reply below by consolidating other two emails comments
>>>>>> related to this.
>>>>>>
>>>>>> On 07/03/24 12:31 am, Conor Dooley wrote:
>>>>>>> On Wed, Mar 06, 2024 at 07:48:57PM +0100, Andrew Lunn wrote:
>>>>>>>>>> +description:
>>>>>>>>>> +  The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
>>>>>>>>>> +  PHY to enable 10BASE‑T1S networks. The Ethernet Media Access Controller
>>>>>>>>>> +  (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
>>>>>>>>>> +  with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
>>>>>>>>>> +  integrated into the LAN8650/1. The communication between the Host and
>>>>>>>>>> +  the MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
>>>>>>>>>> +  Interface (TC6).
>>>>>>>>>> +
>>>>>>>>>> +allOf:
>>>>>>>>>> +  - $ref: ethernet-controller.yaml#
>>>>>>>>>> +
>>>>>>>>>> +properties:
>>>>>>>>>> +  compatible:
>>>>>>>>>> +    oneOf:
>>>>>>>>>> +      - items:
>>>>>>>>>> +          - const: microchip,lan8650
>>>>>>>>>> +          - const: microchip,lan8651
>>>>>>>>> The order here is wrong, lan8561 needs to come before the fallback of
>>>>>>>>> lan8650.
>>>>>>>> I don't think it is a fallback. There are two devices, and hence two
>>>>>>>> different compatibles. So i suspect the -items: is wrong here?
>>>>>>> It'd just be a two entry enum then, but I did take a quick look at the
>>>>>>> driver earlier and saw:
>>>>>>> +static const struct of_device_id lan865x_dt_ids[] = {
>>>>>>> +    { .compatible = "microchip,lan8650" },
>>>>>>> +    { .compatible = "microchip,lan8651" },
>>>>>>> +    { /* Sentinel */ }
>>>>>>> +};
>>>>>>>
>>>>>>> That, along with no other of_device_is_compatible() type operations
>>>>>>> made me think that having a fallback actually was suitable.
>>>>>>>
>>>>>>> You cropped it out, but the patch had:
>>>>>>>> +  compatible:
>>>>>>>> +    oneOf:
>>>>>>>> +      - items:
>>>>>>>> +          - const: microchip,lan8650
>>>>>>>> +          - const: microchip,lan8651
>>>>>>>> +      - enum:
>>>>>>>> +          - microchip,lan8650
>>>>>>> So it doesn't appear to be an accidental items in place of an enum,
>>>>>>> since the other compatible is in another enum.
>>>>>> As per Andrew's comment in another email, both LAN8650 and LAN8651 are
>>>>>> two different variants but they both share almost all characteristics
>>>>>> except one thing that is LAN8651 has "Single 3.3V supply with integrated
>>>>>> 1.8V regulator" which doesn't have anything to do with driver. That's
>>>>> So why this is not reflected in your driver? Why didn't you address that
>>>>> part, but ignored?
>>>> No, it is not ignored. This difference is specific to hardware and there
>>>> is no configuration/setting to be done from driver.
>>>>>> why I have kept them as fallback as Conor said in this email. Hope you
>>>>>> all OK with this.
>>>>> Did you read the feedback? Your response is not solving here anything.
>>>>> How 8650 can be used twice? Please point me to DTS showing both usages.
>>>> May be I have a misunderstanding here. Let's clarify it.
>>>>
>>>> LAN8650 and LAN8651 both are two different variants but both implements
>>>> same functionality. The only difference is LAN8651 has "Single 3.3V
>>>> supply with integrated" where LAN8650 doesn't have this. This is
>>>> hardware specific difference and there is no configuration/setting to be
>>>> done in the driver specific to this difference in the LAN8651. So
>>>> basically the driver can support for both variants without any
>>>> additional settings.
>>>>
>>>> LAN8650:https://www.microchip.com/en-us/product/lan8650
>>>> LAN8651:https://www.microchip.com/en-us/product/lan8651
>>>>
>>>> The below link shows the difference between them,
>>>> https://www.microchip.com/en-us/product-comparison.lan8650.lan8651
>>>>
>>>> With the above details, I would change the microchip,lan865x.yaml with
>>>> the below details.
>>>>
>>>> compatible:
>>>>      enum:
>>>>        - microchip,lan8650
>>>>        - microchip,lan8651
>>>>
>>>> And in the lan865x.c, I would remove the below line because
>>>> .compatible = "microchip,lan8650" already supports for LAN8651 as well.
>>>>
>>>> .compatible = "microchip,lan8651"
>>>>
>>>> Let me know your opinion on this proposal? or do you have any
>>>> misunderstanding here?
>>> It's still wrong. Upstream your DTS and then test it. You will
>>> immediately see that it does not work. So first make it working, then
>>> send code to review.
>> Sorry for the inconvenience. I did the below changes in my
>> microchip,lan865x.yaml file and executed dt_binding_check. It
>> successfully created the microchip,lan865x.example.dts without any
>> errors. Herewith I have attached the updated microchip,lan865x.yaml file
>> and the generated microchip,lan865x.example.dts file for your reference.
>>
>> properties:
>>     compatible:
>>       oneOf:
>>         - items:
>>             - const: microchip,lan8651
>>             - const: microchip,lan8650
> No, this is not right either. You need to also allow the lan8650 on its
> own. All you had to do with the original items list was flip the order
> of the lan8650 and lan8651.
Ah ok, now I understand this. Then it is supposed to be like below,

properties: 

   compatible: 

     oneOf: 

       - const: microchip,lan8650 

       - items: 

           - const: microchip,lan8651 

           - const: microchip,lan8650

Executed dt_binding_check with the above update and it was successful. 
Hope this is OK?

Best regards,
Parthiban V
Krzysztof Kozlowski March 22, 2024, 7:03 a.m. UTC | #12 
On 22/03/2024 07:25, Parthiban.Veerasooran@microchip.com wrote:
>>> properties:
>>>     compatible:
>>>       oneOf:
>>>         - items:
>>>             - const: microchip,lan8651
>>>             - const: microchip,lan8650
>> No, this is not right either. You need to also allow the lan8650 on its
>> own. All you had to do with the original items list was flip the order
>> of the lan8650 and lan8651.
> Ah ok, now I understand this. Then it is supposed to be like below,
> 
> properties: 
> 
>    compatible: 
> 
>      oneOf: 
> 
>        - const: microchip,lan8650 
> 
>        - items: 
> 
>            - const: microchip,lan8651 
> 
>            - const: microchip,lan8650
> 
> Executed dt_binding_check with the above update and it was successful. 
> Hope this is OK?

This is the third time you ask us. None of the previous cases were
actually tested. Maybe this one was, maybe not. I assume the latter.

First, test your code.

Best regards,
Krzysztof
Parthiban Veerasooran March 22, 2024, 8:28 a.m. UTC | #13 
Hi Krzysztof,

On 22/03/24 12:33 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 22/03/2024 07:25, Parthiban.Veerasooran@microchip.com wrote:
>>>> properties:
>>>>      compatible:
>>>>        oneOf:
>>>>          - items:
>>>>              - const: microchip,lan8651
>>>>              - const: microchip,lan8650
>>> No, this is not right either. You need to also allow the lan8650 on its
>>> own. All you had to do with the original items list was flip the order
>>> of the lan8650 and lan8651.
>> Ah ok, now I understand this. Then it is supposed to be like below,
>>
>> properties:
>>
>>     compatible:
>>
>>       oneOf:
>>
>>         - const: microchip,lan8650
>>
>>         - items:
>>
>>             - const: microchip,lan8651
>>
>>             - const: microchip,lan8650
>>
>> Executed dt_binding_check with the above update and it was successful.
>> Hope this is OK?
> 
> This is the third time you ask us. None of the previous cases were
> actually tested. Maybe this one was, maybe not. I assume the latter.
> 
> First, test your code.
As I mentioned in the previous email itself, I tested this case and the 
previous case both in my RPI 4 setup before replying to the comment. The 
question I ask is to check whether the person who comments is OK with 
the changes or not. Didn't you see the attachments in my previous email 
which I used in my RPI 4 dts setup for my testing? if not I can forward 
it again.

Best regards,
Parthiban V
> 
> Best regards,
> Krzysztof
>
Conor Dooley March 22, 2024, 6:08 p.m. UTC | #14 
On Fri, Mar 22, 2024 at 06:25:02AM +0000, Parthiban.Veerasooran@microchip.com wrote:
> Ah ok, now I understand this. Then it is supposed to be like below,
> 
> properties: 
> 
>    compatible: 
> 
>      oneOf: 
> 
>        - const: microchip,lan8650 
> 
>        - items: 
> 
>            - const: microchip,lan8651 
> 
>            - const: microchip,lan8650
> 
> Executed dt_binding_check with the above update and it was successful. 
> Hope this is OK?

That looks about what I would expect to see, yes.
Krzysztof Kozlowski March 23, 2024, 10:24 a.m. UTC | #15 
On 22/03/2024 09:28, Parthiban.Veerasooran@microchip.com wrote:
>>>
>>>         - const: microchip,lan8650
>>>
>>>         - items:
>>>
>>>             - const: microchip,lan8651
>>>
>>>             - const: microchip,lan8650
>>>
>>> Executed dt_binding_check with the above update and it was successful.
>>> Hope this is OK?
>>
>> This is the third time you ask us. None of the previous cases were
>> actually tested. Maybe this one was, maybe not. I assume the latter.
>>
>> First, test your code.
> As I mentioned in the previous email itself, I tested this case and the 
> previous case both in my RPI 4 setup before replying to the comment. The 

I don't understand how one can test bindings and DTS on RPI 4. Testing
is with dt_bindings_check and dtbs_check.



Best regards,
Krzysztof
Parthiban Veerasooran March 25, 2024, 7:10 a.m. UTC | #16 
Hi Krzysztof,

On 23/03/24 3:54 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 22/03/2024 09:28, Parthiban.Veerasooran@microchip.com wrote:
>>>>
>>>>          - const: microchip,lan8650
>>>>
>>>>          - items:
>>>>
>>>>              - const: microchip,lan8651
>>>>
>>>>              - const: microchip,lan8650
>>>>
>>>> Executed dt_binding_check with the above update and it was successful.
>>>> Hope this is OK?
>>>
>>> This is the third time you ask us. None of the previous cases were
>>> actually tested. Maybe this one was, maybe not. I assume the latter.
>>>
>>> First, test your code.
>> As I mentioned in the previous email itself, I tested this case and the
>> previous case both in my RPI 4 setup before replying to the comment. The
> 
> I don't understand how one can test bindings and DTS on RPI 4. Testing
> is with dt_bindings_check and dtbs_check.
Ok, may be I had a misunderstanding here. Every time I used to test the 
driver with the generated dts in RPI 4. I thought you are asking about 
it. I used the below commands to check the dt bindings and dtbs.

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- 
DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/microchip,lan865x.yaml 
dt_binding_check

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- 
DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/microchip,lan865x.yaml 
dtbs_check

They didn't report any error.

Best regards,
Parthiban V
> 
> 
> 
> Best regards,
> Krzysztof
> 
>
Parthiban Veerasooran March 25, 2024, 7:10 a.m. UTC | #17 
Hi Krzysztof,

On 23/03/24 3:54 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 22/03/2024 09:28, Parthiban.Veerasooran@microchip.com wrote:
>>>>
>>>>          - const: microchip,lan8650
>>>>
>>>>          - items:
>>>>
>>>>              - const: microchip,lan8651
>>>>
>>>>              - const: microchip,lan8650
>>>>
>>>> Executed dt_binding_check with the above update and it was successful.
>>>> Hope this is OK?
>>>
>>> This is the third time you ask us. None of the previous cases were
>>> actually tested. Maybe this one was, maybe not. I assume the latter.
>>>
>>> First, test your code.
>> As I mentioned in the previous email itself, I tested this case and the
>> previous case both in my RPI 4 setup before replying to the comment. The
> 
> I don't understand how one can test bindings and DTS on RPI 4. Testing
> is with dt_bindings_check and dtbs_check.
Ok, may be I had a misunderstanding here. Every time I used to test the 
driver with the generated dts in RPI 4. I thought you are asking about 
it. I used the below commands to check the dt bindings and dtbs.

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- 
DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/microchip,lan865x.yaml 
dt_binding_check

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- 
DT_SCHEMA_FILES=Documentation/devicetree/bindings/net/microchip,lan865x.yaml 
dtbs_check

They didn't report any error.

Best regards,
Parthiban V
> 
> 
> 
> Best regards,
> Krzysztof
> 
>
Parthiban Veerasooran March 25, 2024, 7:12 a.m. UTC | #18 
Hi Conor,

On 22/03/24 11:38 pm, Conor Dooley wrote:
> On Fri, Mar 22, 2024 at 06:25:02AM +0000,Parthiban.Veerasooran@microchip.com  wrote:
>> Ah ok, now I understand this. Then it is supposed to be like below,
>>
>> properties:
>>
>>     compatible:
>>
>>       oneOf:
>>
>>         - const: microchip,lan8650
>>
>>         - items:
>>
>>             - const: microchip,lan8651
>>
>>             - const: microchip,lan8650
>>
>> Executed dt_binding_check with the above update and it was successful.
>> Hope this is OK?
> That looks about what I would expect to see, yes.
OK, thanks for the confirmation. I will update this change in the next 
version.

Best regards,
Parthiban V
>
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/net/microchip,lan865x.yaml b/Documentation/devicetree/bindings/net/microchip,lan865x.yaml
new file mode 100644
index 000000000000..ee52f9d8e93c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,lan865x.yaml
@@ -0,0 +1,80 @@ 
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/microchip,lan865x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip LAN8650/1 10BASE-T1S MACPHY Ethernet Controllers
+
+maintainers:
+  - Parthiban Veerasooran <parthiban.veerasooran@microchip.com>
+
+description:
+  The LAN8650/1 combines a Media Access Controller (MAC) and an Ethernet
+  PHY to enable 10BASE‑T1S networks. The Ethernet Media Access Controller
+  (MAC) module implements a 10 Mbps half duplex Ethernet MAC, compatible
+  with the IEEE 802.3 standard and a 10BASE-T1S physical layer transceiver
+  integrated into the LAN8650/1. The communication between the Host and
+  the MAC-PHY is specified in the OPEN Alliance 10BASE-T1x MACPHY Serial
+  Interface (TC6).
+
+allOf:
+  - $ref: ethernet-controller.yaml#
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+          - const: microchip,lan8650
+          - const: microchip,lan8651
+      - enum:
+          - microchip,lan8650
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    description:
+      Interrupt from MAC-PHY asserted in the event of Receive Chunks
+      Available, Transmit Chunk Credits Available and Extended Status
+      Event.
+    maxItems: 1
+
+  spi-max-frequency:
+    minimum: 15000000
+    maximum: 25000000
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 0
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - spi-max-frequency
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/gpio/gpio.h>
+
+    spi {
+      #address-cells = <1>;
+      #size-cells = <0>;
+
+      ethernet@0 {
+        compatible = "microchip,lan8650";
+        reg = <0>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&eth0_pins>;
+        interrupt-parent = <&gpio>;
+        interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+        local-mac-address = [04 05 06 01 02 03];
+        spi-max-frequency = <15000000>;
+      };
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index f41b7f2257d2..2172431a1935 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14378,6 +14378,7 @@  MICROCHIP LAN8650/1 10BASE-T1S MACPHY ETHERNET DRIVER
 M:	Parthiban Veerasooran <parthiban.veerasooran@microchip.com>
 L:	netdev@vger.kernel.org
 S:	Maintained
+F:	Documentation/devicetree/bindings/net/microchip,lan865x.yaml
 F:	drivers/net/ethernet/microchip/lan865x/lan865x.c
 
 MICROCHIP LAN87xx/LAN937x T1 PHY DRIVER