[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <90669794-2fc1-bff1-104b-cf1daa2e9998@ti.com>
Date: Fri, 1 Sep 2023 10:51:02 +0530
From: Md Danish Anwar <a0501179@...com>
To: Rob Herring <robh@...nel.org>, MD Danish Anwar <danishanwar@...com>
CC: Andrew Lunn <andrew@...n.ch>,
Vignesh Raghavendra <vigneshr@...com>,
Roger Quadros <rogerq@...nel.org>,
Jacob Keller <jacob.e.keller@...el.com>,
Simon Horman <horms@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Paolo Abeni <pabeni@...hat.com>,
Jakub Kicinski <kuba@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
"David S. Miller" <davem@...emloft.net>,
<linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
<netdev@...r.kernel.org>, <srk@...com>, <r-gunasekaran@...com>
Subject: Re: [RFC PATCH net-next 1/2] dt-bindings: net: Add documentation for
Half duplex support.
Hi Rob,
On 31/08/23 11:46 pm, Rob Herring wrote:
> On Wed, Aug 30, 2023 at 05:01:33PM +0530, MD Danish Anwar wrote:
>> In order to support half-duplex operation at 10M and 100M link speeds, the
>> PHY collision detection signal (COL) should be routed to ICSSG
>> GPIO pin (PRGx_PRU0/1_GPI10) so that firmware can detect collision signal
>> and apply the CSMA/CD algorithm applicable for half duplex operation. A DT
>> property, "ti,half-duplex-capable" is introduced for this purpose. If
>> board has PHY COL pin conencted to PRGx_PRU1_GPIO10, this DT property can
>> be added to eth node of ICSSG, MII port to support half duplex operation at
>> that port.
>
> I take it the GPIO here is not visble to the OS and that's why it's not
> described in DT?
>
Yes the GPIO here is not visible in the OS and we need to indicate whether the
PHY COL signal is routed to PRGx_PRU0/1_GPI10 pin or not by setting the
property "ti,half-duplex-capable" as true.
>>
>> Signed-off-by: MD Danish Anwar <danishanwar@...com>
>> ---
>> Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
>> index 13371159515a..59da9aeaee7e 100644
>> --- a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
>> +++ b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml
>> @@ -107,6 +107,13 @@ properties:
>> phandle to system controller node and register offset
>> to ICSSG control register for RGMII transmit delay
>>
>> + ti,half-duplex-capable:
>
> capable or...
>
>> + type: boolean
>> + description:
>> + Enable half duplex operation on ICSSG MII port. This requires
>
> enable the mode?
>
I think capable is good here. The property "ti,half-duplex-capable" indicates
that the board is capable of half duplex operation. This doesn't necessarily
means we have to enable the half duplex mode. The user can modify the duplex
settings from ethtool and enable / disable is controlled by the user. This
property basically let's the driver know that it can support half duplex
operations and when user enables half duplex mode through ethtool, the driver
can do the necessary configurations.
When this property is false, half duplex is not supported. If user still wants
to change the duplex mode, it will get an error saying half duplex is not
supported.
So the property "ti,half-duplex-capable" let's the driver know whether half
duplex is supported or not. Enable / disable is controlled by user through ethtool.
> Maybe too late if it's already been assumed not supported, but shouldn't
> supporting half duplex be the default? I guess half duplex isn't too
> common any more.
>
Unfortunately ICSSG doesn't support half duplex by default. Routing the PHY COL
signal is necessary.
> Rob
--
Thanks and Regards,
Danish.
Powered by blists - more mailing lists