netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: netdev <netdev@vger.kernel.org>
Subject: Re: [RFC PATCH net-next 00/24] Support MDIO devices
Date: Tue, 5 Jan 2016 03:57:53 +0100	[thread overview]
Message-ID: <20160105025753.GH7485@lunn.ch> (raw)
In-Reply-To: <568B28BB.60804@gmail.com>

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

      reply	other threads:[~2016-01-05  2:57 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-04 17:36 [RFC PATCH net-next 00/24] Support MDIO devices Andrew Lunn
2016-01-04 17:36 ` [RFC PATCH net-next 01/24] phy: Consistently use addr for address on an MII bus Andrew Lunn
2016-01-04 20:01   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 02/24] mdio: Move mdiobus_read/write operatings into mdio.h Andrew Lunn
2016-01-04 20:02   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 03/24] phy: Use phy_read() instead of mdiobus_read() Andrew Lunn
2016-01-04 20:07   ` Florian Fainelli
2016-01-05 13:40     ` Andrew Lunn
2016-01-04 17:36 ` [RFC PATCH net-next 04/24] phy: Add phydev_err() and phydev_dbg() macros Andrew Lunn
2016-01-04 20:08   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 05/24] phy: add phydev_name() macro Andrew Lunn
2016-01-04 17:48   ` Joe Perches
2016-01-04 17:36 ` [RFC PATCH net-next 06/24] net: dnet: Use phy_find_first() helper Andrew Lunn
2016-01-04 20:08   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 07/24] phy: phy_{read|write}_mmd_indirect: get addr from phydev Andrew Lunn
2016-01-04 20:10   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 08/24] phy: Centralise print about attached phy Andrew Lunn
2016-01-04 20:15   ` Florian Fainelli
2016-01-04 21:16     ` Andrew Lunn
2016-01-04 17:36 ` [RFC PATCH net-next 09/24] phy: mdio-octeon: Use devm_mdiobus_alloc_size() Andrew Lunn
2016-01-04 20:18   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 10/24] mdio: Move allocation of interrupts into core Andrew Lunn
2016-01-04 20:17   ` Florian Fainelli
2016-01-06 14:07   ` Shaohui Xie
2016-01-04 17:36 ` [RFC PATCH net-next 11/24] phy: Add an mdio_device structure Andrew Lunn
2016-01-05  1:53   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 12/24] of: phy: Only register a phy device for phys Andrew Lunn
2016-01-04 20:01   ` Florian Fainelli
2016-01-04 21:04     ` Andrew Lunn
2016-01-04 17:36 ` [RFC PATCH net-next 13/24] phy: Add API for {un{registering an mdio device to a bus Andrew Lunn
2016-01-05  1:55   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 14/24] phy_device: Move phy attributes into phy_device Andrew Lunn
2016-01-05  1:57   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 15/24] dsa: Register netdev before phy Andrew Lunn
2016-01-05  1:59   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 16/24] phy: Move PHY PM operations into phy_device Andrew Lunn
2016-01-05  2:00   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 17/24] phy: Centralize setting driver module owner Andrew Lunn
2016-01-05  2:00   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 18/24] phy: Move phy specific bus match into phy_device Andrew Lunn
2016-01-05  2:01   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 19/24] mdio_bus: Generalise of_mdiobus_link_phydev() Andrew Lunn
2016-01-05  2:01   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 20/24] mdio_bus: Add comment to mdiobus_scan() and __mdiobus_register() Andrew Lunn
2016-01-05  2:02   ` Florian Fainelli
2016-01-04 17:36 ` [RFC PATCH net-next 21/24] mdio: Add support for mdio drivers Andrew Lunn
2016-01-05  2:03   ` Florian Fainelli
2016-01-04 17:37 ` [RFC PATCH net-next 22/24] mdio: Abstract device_remove() and device_free() Andrew Lunn
2016-01-05  2:04   ` Florian Fainelli
2016-01-04 17:37 ` [RFC PATCH net-next 23/24] mdio: mdio-nop: Dummy driver to testing Andrew Lunn
2016-01-04 17:37 ` [RFC PATCH net-next 24/24] Add linux,mdio-nop support for testing Andrew Lunn
2016-01-05  2:21 ` [RFC PATCH net-next 00/24] Support MDIO devices Florian Fainelli
2016-01-05  2:57   ` Andrew Lunn [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160105025753.GH7485@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=f.fainelli@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).