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: <CAJ+vNU2v9WD2kzB9uTD5j6DqnBBKhv-XOttKLoZ-VzkwdzwjXw@mail.gmail.com>
Date:   Thu, 3 Feb 2022 07:57:52 -0800
From:   Tim Harvey <tharvey@...eworks.com>
To:     Andrew Lunn <andrew@...n.ch>
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

On Wed, Feb 2, 2022 at 5:01 PM Andrew Lunn <andrew@...n.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