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] [day] [month] [year] [list]
Message-ID: <0ee94fd3-d099-4d82-9ba8-eb1939450cc3@lunn.ch>
Date: Fri, 10 Jan 2025 16:38:18 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Ninad Palsule <ninad@...ux.ibm.com>
Cc: Jacky Chou <jacky_chou@...eedtech.com>,
	"andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
	"andrew@...econstruct.com.au" <andrew@...econstruct.com.au>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"eajames@...ux.ibm.com" <eajames@...ux.ibm.com>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"joel@....id.au" <joel@....id.au>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"minyard@....org" <minyard@....org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"openipmi-developer@...ts.sourceforge.net" <openipmi-developer@...ts.sourceforge.net>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"ratbert@...aday-tech.com" <ratbert@...aday-tech.com>,
	"robh@...nel.org" <robh@...nel.org>
Subject: Re: 回覆: 回覆: [PATCH v2 05/10]
 ARM: dts: aspeed: system1: Add RGMII support

> Do we need updates on this description. It doesn't talk about external PCB
> level delays?
> 
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L77-L90
> 
> This is what you explained:
> 
> MAC driver reads following phy-mode from device tree. 95% of mac driver
> directly
>  pass it to PHY through phy_connect.
> 
> rgmii - PCB has long clock lines so delay is added by PCB
>         On this mode PHY does nothing.
> rgmii-id - PCB doesn't add delay. Either MAC or PHY needs to add the delay
>            Add delays in both directions. Some PHY may not add delay in that
>            case MAC needs to add the delay mask rgmii-id to rgmii.
> rgmii-rxid - If there is an extra long TX clock line, but not RX clock,
>              you would use rgmii-rxid
> rgmii-txid - When there is an extra long RX clock line on the PCB, but not
>              the TX clock line, you would use rgmii-txid

The documentation is not great, that has been said a few times.  What
is described here is the view from the PHY, which is not ideal.

      # RX and TX delays are added by the MAC when required
      - rgmii

>From the perspective of the PHY, this means it does not need to add
delays, because the MAC has added the delays, if required, e.g. the
PCB has not added the delays.

We have the problem that DT is supposed to describe the
hardware. Saying the PHY should add the delays, but if the MAC adds
the delays it needs to mask the value passed to the PHY does not
describe the hardware, it is Linix implementation details. The DT
Maintainers don't want that in the DT binding because other OSes might
decide to implement the details differently.

So your description becomes:

rgmii      - PCB has long clock lines so delays are added by the PCB
rgmii-id   - PCB doesn't add delay. Either MAC or PHY needs to add the delays
             in both directions.
rgmii-rxid - There is an extra long TX clock line on the PCB, but not the RX clock.
rgmii-txid - There is an extra long RX clock line on the PCB, but not the TX clock.

It is correct, but leaves so much unsaid developers will still get it
wrong. What we really want is that developers:

1) Read the mailing list. Patches for RGMII delays are posted at least
   once an month and i point out how they are wrong. If developers
   actually read the mails, they would not make the same mistake again
   and again.

2) Developers for some reason like to invent their own code, rather
   than taking the easy route of copy from a driver already in Linux.
   The majority of drivers in Linux get this right, so if you copy
   another driver, you should get it right for free as well.

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ