netdev - Re: [RFC PATCH net-next 00/24] Support MDIO devices

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

Message-ID: <20160105025753.GH7485@lunn.ch>
Date:	Tue, 5 Jan 2016 03:57:53 +0100
From:	Andrew Lunn <andrew@...n.ch>
To:	Florian Fainelli <f.fainelli@...il.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH net-next 00/24] Support MDIO devices

> - what kind of API do we need to offer to Ethernet MAC driver? Would
> attach/detach and maybe adjust_link be good enough?

I was not going to offer it any! At least not at the MDIO layer.

Maybe i have DSA too much in mind. But all we need for DSA is probe
and remove. When the MDIO device is probed, based on DT information,
it registers its DSA OPs with the DSA framework. When the device is
removed, it unregisters its DSA ops. Nothing else is needed.

Also, don't forget you can have an MDIO bus without an MII bus. The
classic examples are using a couple of gpio lines to bit bang, or
using a mux to give you multiple MDIO busses from one real MDIO bus
and some gpio pins.

> - should we consider modeling a MDIO connected switch as a MDIO device
> (responding at the pseudo PHY address on the MDIO bus) which then
> eventually creates a child MDIO bus and per-port individual PHY devices?

Sort of. The Marvell switch actually take up quite a few addresses on
the MDIO bus, not just the one listed in the DT. By convention, if the
address is zero, the switch is assumed to be in single chip mode, and
will respond to 10 or more different addresses. Depending on the
switch model, some of those addresses are actually phys, and should be
listed in DT as phys.

If the address is not zero, the switch is in multi-chip mode, and it
will respond to registers 0x00 and 0x01 on that one address. These two
registers give an indirect access to all the other registers.

> - for MDIO switches with a data-path to an Ethernet MAC (which is
> probably 99% of the cases, are there some which do not have such a thing
> and are still managed switches?), how much of the existing PHY device
> properties (speed, duplex, interface, pause capability) should we think
> about moving to the common MDIO device structure? Then this kind of
> circles back to the first question about the Ethernet MAC interface API [1]

To me, MII and MDIO are separate busses and should not be mixed
together. Think about the case of a switch with two MII busses for
greater frame throughput, but only one MDIO bus for management?  Some
of the Marvell switches can also be manged using messages in Ethernet
frames. So you could even have a switch with only MII and no MDIO!

What also comes to play here is Russell Kings phylink code.

We have this 20+ part patchset. This gives us enough we can look at
integrating the 20+ part DSA probing patchset and then look at RMKs
20+ patchset. That alone should keep us busy for a while without
needed to add yet more.

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