netdev - 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+vNU1Urkd4A8BdvP7H9W_H2DDOH2_khXesh49KzWoVqjk_iw@mail.gmail.com>
Date:   Thu, 3 Feb 2022 08:02:49 -0800
From:   Tim Harvey <tharvey@...eworks.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, Martin Schiller <ms@....tdt.de>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        martin.blumenstingl@...glemail.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 7:12 PM Florian Fainelli <f.fainelli@...il.com> wrote:
>
>
>
> On 2/2/2022 5:01 PM, Andrew Lunn 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.
>
> This is really trying to take advantage of the boot loader setting
> things up in a way that Linux can play dumb by using the Generic PHY
> driver and being done with it. This works... until it stops, which
> happens very very quickly in general. The perfect counter argument to
> using the Generic PHY driver is when your system implements a low power
> mode where the PHY loses its power/settings, comes up from suspend and
> the strap configuration is insufficient and the boot loader is not part
> of the resume path *prior* to Linux. In that case Linux needs to restore
> the settings, but it needs a PHY driver for that.

Florian,

That makes sense - I'm always trying to figure out what the advantage
of using some of these PHY drivers really is vs disabling them.

>
> If your concern Tim is with minimizing the amount of time the link gets
> dropped and re-established, then there is not really much that can be
> done that is compatible with Linux setting things up, short of
> minimizing the amount of register writes that do need the "commit phase"
> via BMCR.RESET.

No, my reasoning has nothing to do with link time - I have just run
into several cases where some new change in a PHY driver blatantly
either resets the PHY reverting to pin-strapping config which is wrong
(happend to me with DP83867 but replacing the 'reset' to a 'restart'
solved that) or imposes some settings without dt bindings to guide it
(this case with the LEDs) or imposes some settings based on 'new'
dt-bindings which I was simply not aware of (a lesser issue as dt
bindings can be added to resolve it).

>
> I do agree that blindly imposing LED settings that are different than
> those you want is not great, and should be remedied. Maybe you can
> comment this part out in your downstream tree for a while until the LED
> binding shows up (we have never been so close I am told).

or disable the driver in defconfig, or blacklist the module if I want
to do it via rootfs.

Can you point me to something I can look at for these new LED bindings
that are being worked on?

Best Regards,

Tim