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: <YfspazpWoKuHEwPU@lunn.ch>
Date:   Thu, 3 Feb 2022 02:01:31 +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

> 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.

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.

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.

       Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ