[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241220101557.t4fcic457kbvvcol@skbuf>
Date: Fri, 20 Dec 2024 12:15:57 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>
Cc: "andrew@...n.ch" <andrew@...n.ch>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net: dsa: honor "max-speed" for implicit PHYs
on user ports
On Fri, Dec 20, 2024 at 07:17:37AM +0000, Sverdlin, Alexander wrote:
> Thanks for the references!
>
> I've complitely missed the story of
> fe7324b93222 ("net: dsa: OF-ware slave_mii_bus")
> vs ae94dc25fd73
> ("net: dsa: remove OF-based MDIO bus registration from DSA core").
>
> But I'm still having hard time to get the motivation behind removing
> 2 function calls from the DSA core and forcing all individual DSA drivers
> to have this very same boilerplate...
>
> But well, if all the DSA maintainers are so committed to it, this answers
> my original question... Please ignore the patch!
My motivation is that as things stand, ds->ops->phy_read() and
ds->ops->phy_write() are just too attractive to implement, but lure
developers into an OF-unaware internal MDIO bus model which is just
redundant and provides less functionality compared to its OF-aware
counterpart. You can surely understand this if you look at what prompted
you to submit this patch.
As for the OF-aware MDIO bus, the idea would be for DSA to focus less on
imposing a device model, and more on just the Ethernet switch component.
I'm yet to be convinced that it's exactly DSA's business to assist with that.
Being slimmer helps. For example if somebody wanted to add ACPI bindings
for the DSA core, not having to think about MDIO as part of the core
bindings, but as a device specific thing, is a simplifying factor.
You're also exaggerating that all DSA switches have internal PHYs.
Powered by blists - more mailing lists