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

Powered by Openwall GNU/*/Linux Powered by OpenVZ