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: <20151224125812.GB29139@lunn.ch>
Date:	Thu, 24 Dec 2015 13:58:12 +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

> I do not think you need the platform device because ultimately what the
> DSA platform device does is bind some data to the master network device
> the DSA switch tree is hanging off. Sure you need some piece of code
> that is resident in kernel or module space to be able to parse and
> allocate that data structure and bind multiple switch drivers together,
> but that could be a consequence of probing switch driver using their bus
> probe function.
> 
> The way I would imagine this in a cluster configuration is that you
> probe switches in the order in which they should appear in the final
> switch tree (if this order cannot be guaranteed, then defer until it
> is), and as you parse Device Tree for these switches you allocate their
> resources and update the dsa_switch_tree structure "live".

How do you get this ordering? You cannot control the probe order in
Linux.

> If we are using Device Tree this is relatively easy since we can lookup
> the entire Device Tree to know the switch tree topology whenever we
> probe a switch device driver. If we are using platform data, then, we
> should have a way to associate a given MDIO bus address with
> supplementary information, very much like what this patch does:

One of my aims is to abstract away the MDIO bus from DSA. How you talk
to the switch is a switch device property. SF2 has a different way to
talk to the switch, memory mapped IO, etc.

Anyway, who do you think the device tree binding will look? Maybe take
the .dts file in patches 2 and 20 to build an example?

	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