netdev - Re: sja1105q: proper way to solve PHY clk dependecy

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] [day] [month] [year] [list]

Message-ID: <20220324143519.yvcgt3u2icnbbafy@skbuf>
Date:   Thu, 24 Mar 2022 16:35:19 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Oleksij Rempel <o.rempel@...gutronix.de>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Yangbo Lu <yangbo.lu@....com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel@...gutronix.de
Subject: Re: sja1105q: proper way to solve PHY clk dependecy

On Thu, Mar 24, 2022 at 02:48:24PM +0100, Oleksij Rempel wrote:
> > 3. Clock gating the PHY won't make it lose its settings.
> > 
> > I expect that during the time when the sja1105 switch needs to reset,
> > the PHY just sees this as a few hundreds of ms during which there are no
> > clock edges on the crystal input pin. Sure, the PHY won't do anything
> > during that time, but this is quite different from a reset, is it not?
> > So asserting the hardware reset line of the PHY during the momentary
> > loss of clock, which is what you seem to suggest, will actively do more
> > harm than good.
> 
> can i be sure that MDIO access happens in the period where PHY is
> supplied with stable clk

This is a good question. I suppose not, but I never ran into this issue.
You can try to force this by having the PHY library use poll mode for an
RMII PHY (case in which, IIRC, 3 or 4 PHY registers will be read every 2
seconds), then from user space do something like this:

ip link add br0 type bridge && ip link set br0 up
ip link set swp0 master br0 && ip link set swp0 up
while :; do
	ip link set br0 type bridge vlan_filtering 1
	sleep 1
	ip link set br0 type bridge vlan_filtering 0
	sleep 1
done

Every VLAN awareness change triggers a reset in the switch, and this
ends up calling sja1105_static_config_reload().

If you can artificially reproduce PHY access failures, first it's
interesting to analyze their impact, does the PHY state machine
transition to a halted state, or does it ignore the errors and continue
with the next poll cycle? If it continues, it's probably not worth doing
something.

To avoid the problem, you should probably need to iterate using
dsa_switch_for_each_user_port(), and mutex_lock(&dp->slave->phydev->lock)
for each RMII PHY during the reset procedure (similar to the other
things we lock out during the switch reset). The tricky part seems to be
releasing the locks in the reverse order of the acquire...