Messages in this thread | | | From | Tim Harvey <> | Date | Thu, 3 Feb 2022 07:57:52 -0800 | Subject | Re: [PATCH net v3] net: phy: intel-xway: enable integrated led functions |
| |
On Wed, Feb 2, 2022 at 5:01 PM Andrew Lunn <andrew@lunn.ch> wrote: > > > As a person responsible for boot firmware through kernel for a set of > > boards I continue to do the following to keep Linux from mucking with > > various PHY configurations: > > - remove PHY reset pins from Linux DT's to keep Linux from hard resetting PHY's > > - disabling PHY drivers > > > > What are your thoughts about this? > > Hi Tim > > I don't like the idea that the bootloader is controlling the hardware, > not linux. > > There are well defined ways for telling Linux how RGMII delays should > be set, and most PHY drivers do this. Any which don't should be > extended to actually set the delay as configured.
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.
> > 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.
> > You probably are going to have more and more issues if you think the > bootloader is controlling the hardware, so you really should stop > trying to do that. >
Trust me, I would love to stop trying to hide PHY config from Linux. It's painful to bump to a new kernel and find something broken. In this case I found that my LED configuration broke and in the other patch I found that my RGMII delays broke.
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.
Tim
| |