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: <567B07CB.5080308@gmail.com>
Date:	Wed, 23 Dec 2015 12:44:59 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Andrew Lunn <andrew@...n.ch>, narmstrong@...libre.com,
	vivien.didelot@...oirfairelinux.com
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH RFC 00/28] DSA: Restructure probing

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.

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 would very much like to make it possible for the bcm_sf2 driver to be
a real platform driver, call into dsa_switch_register(), yet remain
compatible with the old binding by using dsa_of_probe(), it could be
based on the compatible string we get probed with, it could be up to the
caller or the callee to attempt both bindings to be parsed etc.

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.

That being said, thanks a lot for getting the patches out!
-- 
Florian
--
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