Subject: Re: [PATCH RFC 00/28] DSA: Restructure probing

From: Andrew Lunn <[email-masked]>
Date: Wed, 23 Dec 2015 23:33:03 +0100

On Wed, Dec 23, 2015 at 12:44:59PM -0800, Florian Fainelli wrote:
> Hi Andrew,
> 
> Le 23/12/2015 04:56, Andrew Lunn a écrit :
> > As noted in Documentation/networking/dsa/dsa.txt, the current DSA
> > architecture has a few architecture problems:
> > 
> > DSA is implemented as a DSA platform device driver which is convenient because
> > it will register the entire DSA switch tree attached to a master network device
> > in one-shot, facilitating the device creation and simplifying the device driver
> > model a bit, this comes however with a number of limitations:
> > 
> > - building DSA and its switch drivers as modules is currently not working
> > - the device driver parenting does not necessarily reflect the original
> >   bus/device the switch can be created from
> > - supporting non-MDIO and non-MMIO (platform) switches is not possible
> > 
> > This RFC patchset attempts to address this. It allows the switch
> > device to be true Linux devices, and use of the device component
> > framework to bind the switch devices to the DSA framework, similar to
> > the way GPU engines are bound to the master GPU driver. The drivers
> > are now modules, which can be loaded and unloaded. Reloading however
> > currently causes an Opps, hence RFC.
> > 
> > The code remains backwards compatible with the old binding, and adds a
> > new property to facilitate the component framework. Switch drivers get
> > there own binding, allowing them to be probed independent of DSA.

Hi Florian

> Well, sort of, and that is the part that gives me mixed feelings right
> now. Your conversion of the bcm_sf2 driver, although it looks good and
> gets us where we should go, still poses a major problem for my platforms
> where a wrong DTB is frozen (at least for some time).

I hope i've not broken backwards compatibility, so your old DT blobs
should still work. If they don't work, we should debug why.

> I still think that using a 'dsa' platform device and having to bind
> other drivers to it is just an artifact and relic from the original
> design that we do not necessarily need anymore but with the components
> framework, it seems to get us in a better shape.

I don't really see how we can do without a dsa platform driver. We
need something that brings together all the switches in a cluster. We
need somewhere which holds the information about how these switches
are connected together and connected to the host.

    Andrew