[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220719181113.q5jf7mpr7ygeioqw@skbuf>
Date: Tue, 19 Jul 2022 21:11:13 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Sean Anderson <sean.anderson@...o.com>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
Jakub Kicinski <kuba@...nel.org>,
Madalin Bucur <madalin.bucur@....com>,
"David S . Miller" <davem@...emloft.net>,
Paolo Abeni <pabeni@...hat.com>,
Ioana Ciornei <ioana.ciornei@....com>,
linux-kernel@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
Andrew Lunn <andrew@...n.ch>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Claudiu Manoil <claudiu.manoil@....com>,
Florian Fainelli <f.fainelli@...il.com>,
Frank Rowand <frowand.list@...il.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Li Yang <leoyang.li@....com>,
Michael Ellerman <mpe@...erman.id.au>,
Paul Mackerras <paulus@...ba.org>,
Rob Herring <robh+dt@...nel.org>,
Saravana Kannan <saravanak@...gle.com>,
Shawn Guo <shawnguo@...nel.org>, UNGLinuxDriver@...rochip.com,
Vivien Didelot <vivien.didelot@...il.com>,
Vladimir Oltean <vladimir.oltean@....com>,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [RFC PATCH net-next 0/9] net: pcs: Add support for devices
probed in the "usual" manner
On Tue, Jul 19, 2022 at 11:46:23AM -0400, Sean Anderson wrote:
> I'm saying that patches 4 and 5 [1] provide "...a working migration
> path to [my] PCS driver model." Since enetc/ocelot do not use
> devicetree for the PCS, patch 9 should have no effect.
>
> That said, if you've tested this on actual hardware, I'm interested
> in your results. I do not have access to enetc/ocelot hardware, so
> I was unable to test whether my proposed migration would work.
>
> --Sean
>
> [1] I listed 6 but it seems like it just has some small hunks which should have been in 5 instead
Got it, thanks. So things actually work up until the end, after fixing
the compilation errors and warnings and applying my phy_mask patch first.
However, as mentioned by Russell King, this patch set now gives us the
possibility of doing this, which happily kills the system:
echo "0000:00:00.5-imdio:03" > /sys/bus/mdio_bus/drivers/lynx-pcs/unbind
For your information, pcs-rzn1-miic.c already has a device_link_add()
call to its consumer, and it does avoid the unbinding problem. It is a
bit of a heavy hammer as Russell points out (a DSA switch is a single
struct device, but has multiple net_devices and phylink instances, and
the switch device would be unregistered in its entirety), but on the
other hand, this is one of the simpler things we can do, until we have
something more fine-grained. I, for one, am perfectly happy with a
device link. The alternative would be reworking phylink to react on PCS
devices coming and going. I don't even know what the implications are
upon mac_select_pcs() and such...
Powered by blists - more mailing lists