lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f4431158-c177-8d09-4125-3fb01062f1fd@kernel.org>
Date:   Thu, 7 Sep 2023 15:16:43 +0300
From:   Roger Quadros <rogerq@...nel.org>
To:     Md Danish Anwar <a0501179@...com>, Rob Herring <robh@...nel.org>,
        MD Danish Anwar <danishanwar@...com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vignesh Raghavendra <vigneshr@...com>,
        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.



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@...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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ