Re: [RFC PATCH net-next 1/2] dt-bindings: net: Add documentation for Half duplex support.

[Roger Quadros]

On 01/09/2023 08:21, Md Danish Anwar wrote:
> 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@xxxxxx>
>>> ---
>>>  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.

But the half-duplex advertising is always enabled by default. Whether it gets
used or not will depend on negotiation with link partner.

That's why you had to explicitly disable them in your next patch with

+	if (!emac->half_duplex) {
+		dev_dbg(prueth->dev, "half duplex mode is not supported\n");
+		phy_remove_link_mode(ndev->phydev, ETHTOOL_LINK_MODE_10baseT_Half_BIT);
+		phy_remove_link_mode(ndev->phydev, ETHTOOL_LINK_MODE_100baseT_Half_BIT);
+	}

-- 
cheers,
-roger