linux-kernel - Re: [PATCH net v3] net: phy: intel-xway: enable integrated led functions

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: <YfwEvgerYddIUp1V@lunn.ch>
Date:   Thu, 3 Feb 2022 17:37:18 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Tim Harvey <tharvey@...eworks.com>
Cc:     Martin Schiller <ms@....tdt.de>, Hauke Mehrtens <hauke@...ke-m.de>,
        martin.blumenstingl@...glemail.com,
        Florian Fainelli <f.fainelli@...il.com>, hkallweit1@...il.com,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        David Miller <davem@...emloft.net>, kuba@...nel.org,
        netdev <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net v3] net: phy: intel-xway: enable integrated led
 functions

> Andrew,
> 
> I agree with the goal of having PHY drivers and dt-bindings in Linux
> to configure everything but in the case I mention in the other thread
> adding rgmii delay configuration which sets a default if a new dt
> binding is missing is wrong in my opinion as it breaks backward
> compatibility. If a new dt binding is missing then I feel that the
> register fields those bindings act on should not be changed.

I would like that understand this specific case in more detail.  We
have seen a few cases were the DT is broken, yet works. This is often
caused by having a wrong phy-mode, which historically the PHY driver
was ignoring. Then support for honouring the phy-mode was added to the
PHY driver, and all the boards with broken DT files actually break.

So it could be that is what has happened here. Or it could be the
driver is plan wrong. If i understand correctly, you say it is adding
a default delay of 2ns. That would be correct for a phy-mode of
rgmii-id, but wrong for a phy-mode of rgmii.

> > LEDs are trickier. There is a slow on going effort to allow PHY LEDs
> > to be configured as standard Linux LEDs. That should result in a DT
> > binding which can be used to configure LEDs from DT.
> 
> Can you point me to something I can look at? PHY LED bindings don't at
> all behave like normal LED's as they are blinked internally depending
> on a large set of rules that differ per PHY.

Yes, this is what is slowing the work done, agreeing on details like
this, and how the user space API would actually work. In the end, i
suspect a subset of LED modes will be supported, covering the common
blink patterns.

> Completely off topic, but due to the chip shortage we have had to
> redesign many of our boards with different PHY's that now have
> different bindings for RGMII delays so I have to add multiple PHY
> configurations to DT's if I am going to support the use of PHY
> drivers. What is your suggestion there? Using DT overlays I suppose is
> the right approach.

I would try to only use phy-mode, and avoid all PHY specific tweaks.
So long as the track lengths don't change too much on your redesign,
and are kept about the same length, the standard 2ns delay should
work.

	Andrew