netdev - Re: [PATCH RFC 25/28] Documentation: DSA: Describe how probe of DSA and switches work.

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]

Date:	Wed, 23 Dec 2015 12:48:28 -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 25/28] Documentation: DSA: Describe how probe of DSA
 and switches work.

Le 23/12/2015 04:56, Andrew Lunn a écrit :
> With the introduction of switches as linux devices and the use of the
> component framework, probing has become more complex. Add some
> documentation.
> 
> Signed-off-by: Andrew Lunn <andrew@...n.ch>
> ---
>  Documentation/networking/dsa/dsa.txt | 48 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
> 
> diff --git a/Documentation/networking/dsa/dsa.txt b/Documentation/networking/dsa/dsa.txt
> index aa9c1f9313cd..376afa135a81 100644
> --- a/Documentation/networking/dsa/dsa.txt
> +++ b/Documentation/networking/dsa/dsa.txt
> @@ -398,6 +398,54 @@ Switch configuration
>    on the management interface and "hardcode"/"force" this MAC address for the
>    CPU/management interface as an optimization
>  
> +Call flow
> +---------
> +
> +With the ability for switch devices to be true linux devices, the call
> +flow is somewhat complex. The component framework is used to link the
> +dsa framework as the master, with switch devices, as slaves.
> +
> +A switch device should add itself as a component in its probe
> +function.
> +
> +The DSA framework can either be configured using a platform_data
> +structure or from the device tree. If device tree is being used, the
> +dsa framework probe function will allocate a platform_data structure,
> +and populate it using the device tree, via the dsa_of_probe()
> +function.  Within the DSA device tree, switch devices are represented
> +by a phandle to the switch device. These phandles are saved into the
> +platform data so that when switch slaves register themselves, they can
> +be correctly positioned in the DSA cluster.

Humm, I guess I am still not clear on that, in a DT-only system, do I
still need to get the DSA platform device to be probed via DT, along
with references to the switches I want? If that is the case, that seems
a little awkward, could not we probe the individual switches, and see if
they need DSA instead? Or is that how the component framework works,
just being a bit confused here.

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