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
| ||
|
Date: Thu, 30 Apr 2015 09:46:11 -0700 From: Florian Fainelli <f.fainelli@...il.com> To: Guenter Roeck <linux@...ck-us.net>, netdev@...r.kernel.org CC: davem@...emloft.net, vivien.didelot@...oirfairelinux.com, jerome.oufella@...oirfairelinux.com, andrew@...n.ch, cphealy@...il.com, mathieu@...eaurora.org, jonasj76@...il.com, andrey.volkov@...vision.fr, Chris.Packham@...iedtelesis.co.nz Subject: Re: [RFC PATCH net-next 7/8] net: dsa: mv88e6060: make it a proper PHY driver On 30/04/15 06:49, Guenter Roeck wrote: > On 04/29/2015 06:57 PM, Florian Fainelli wrote: >> Convert the Marvell 88E6060 switch driver into a proper PHY library >> driver that can be registered. To make sure we do not introduce >> functional changes, the PHY driver provides autoneg and status callbacks >> to make sure the attached Ethernet MAC driver still sees a link UP at >> the CPU port full speed. >> >> Signed-off-by: Florian Fainelli <f.fainelli@...il.com> >> --- >> drivers/net/dsa/mv88e6060.c | 114 >> ++++++++++++++++++++++++++++++++++++++++++-- >> 1 file changed, 109 insertions(+), 5 deletions(-) >> > > The whole complexity added here makes me wonder if we are really on the > right track. > After all, switches are _not_ phy devices. Forcing them to register as > phy devices > just because they use mdio and just because the Linux mdio > implementation assumes > that anything connected to it is a phy seems odd. The net advantage I see with this approach is that currently, with DSA, you get to do the following: - register a "dsa" platform device - force your CPU Ethernet MAC to hardcode link parameters, either via a "fixed PHY" or via custom settings (ala mv643xx_eth) - probing needs to occur in a *very* specific order: MDIO first, Ethernet device second, DSA last Now, with this patchset, you don't need to have DSA awareness in anything but the "provider" driver which in this case is a PHY driver because it sits on the MDIO bus (see below on that topic) and things tend to "flow" a bit more naturally one you do that. > > A much better solution might be be to disconnect mdio from phy, ie to > create a new > mdio bus framework, as then use this framework for anything connected to > an mdio bus. So essentially end-up creating a separate class of MDIO addressable devices which are switches? I guess we could try to do that. We would still have to update existing Ethernet MAC drivers which speak phylib to know what to do with their CPU port and set correct link parameters, would we want to create a special PHY drivers for these, just for the CPU port? > > Does this make any sense, or am I completely off track ? I think this is very valid, my main point behind this entire patch series is to divorce from the special "dsa" platform_device for common cases: MDIO or MMIO connected switches to a SoC, because it is convoluted and prevents a lot of things from being done: module unloading, proper device reference (and parenting), need for "out of band" link information to be provided to unmodified Ethernet drivers etc... -- Florian -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists