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

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: <20151223223303.GD25485@lunn.ch>
Date:	Wed, 23 Dec 2015 23:33:03 +0100
From:	Andrew Lunn <andrew@...n.ch>
To:	Florian Fainelli <f.fainelli@...il.com>
Cc:	narmstrong@...libre.com, vivien.didelot@...oirfairelinux.com,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH RFC 00/28] DSA: Restructure probing

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