netdev - Re: [PATCH RFC v2 28/32] 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:	Mon, 29 Feb 2016 14:42:40 +0300
From:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To:	Andrew Lunn <andrew@...n.ch>,
	Florian Fainelli <f.fainelli@...il.com>,
	Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH RFC v2 28/32] Documentation: DSA: Describe how probe of
 DSA and switches work.

Hello.

On 2/28/2016 7:41 PM, Andrew Lunn wrote:

> 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

    Linux.

> +flow is somewhat complex. The component framework is used to link the
> +dsa framework as the master, with switch devices, as slaves.

    Commas not needed before "as".

> +
> +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.
> +
> +The DSA probe function then creates a dsa_switch_tree structure which
> +is the overarching structure representing a switch cluster. The probe
> +function then looks in the platform data for the phandles to slave

    Platform data and phandles?

> +devices, and adds a component match based on the phandle. The
> +component master is then created. This causes the component framework
> +to link slaves to the master.
> +
> +If all the slave switch can be found, the masters bind function is

    Switches? Master's?

> +called, dsa_bind(). This in tern causes the switch slaves bind

    In term?

> +function to be called.
> +
> +The switches bind function allocated memory for its own private use,

    Switch's?

> +and for a dsa_switch structure, which represents one switch in a DSA
> +cluster. The switch then registers with the DSA framework using
> +dsa_switch_register().
> +
> +dsa_switch_register() looks in the platform data and finds the
> +position within the cluster for the switch which is registering. The
> +switches dsa_switch structure is then attached to the dsa_switch_tree

    Switch's?

> +structure in the correct place.
[...]

MBR, Sergei