On 03/03/16 12:27, Andrew Lunn wrote: >> - first of all, the original design around the special platform device >> did not allow multiple switch trees within the same system to coexist >> (dsa platform device were not numbered (id = -1)), but such a thing >> could exist and is desirable, you could have a single switch hanging off >> eth0, and more switches hanging off eth1 for instance, and not be part >> of the same tree > > I have hardware i can test such a setup on. > >> >> - the direction we want to move people to is to make them use DSA for >> their switch needs and get the proven benefits from having a consistent >> per-port slave network device model along with a good binding for >> representing ports within a switch (and all thedetails associated with >> that), the next step is to make this available to not just MDIO drivers, >> which you are addressing here, but then, being able to call >> dsa_switch_register() just becomes a service from the network stack with >> DSA support included, if we need the special dsa platform device again, >> we are not way better than where we were before > > We are a bit better. dsa_switch_register() does not care about the > communication channel to the switch. An SPI based switch should now be > possible, as well as a cleaner way to do MMIO switches.
Right, thanks to your patch series and recent efforts, and that is exactly the direction we want. [snip] > > The third switch is as you would expect, dsa,member = <0 2>; I like that representation. > > The probe order does not actually matter. You allocate the dst when > the first switch arrives, and plug that switch in. You then evaluate > the dst. Are all dsa links fulfilled. If yes, you have the full tree, > and you can set it up and running. If no, wait until more switches are > registered. So does that mean you agree we do not need the DSA platform device anymore :)? If not, why, and how much help from the Device Tree do we need to instantiate that special "dsa" platform device? > > This is quite a big change, so why not make it bigger... > > One thing i don't like is the complexity we have in matching phys to > ports, and fixed-link phys. Maybe we should consolidate this: Very true, we support a wide variety of setups, and that creates a lot of complexity that could probably be absorbed by a more generic helper function? > > 1) The switch device should use mdiobus_alloc()/mdiobus_register() for > its own MDIO bus. Agreed, possibly with the help of the DSA slave code, since some of that is already doing its magic for most drivers here. > 2) ports use phy-handle to point to phys on their own mdio bus. I would refrain from needing that unless the mapping between Port and built-in PHY is design/board-level configurable, or we connect to PHYs external to the switch which are not located on its own internal MDIO bus controller. -- Florian
