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 23:53:22 +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 25/28] Documentation: DSA: Describe how probe of DSA
 and switches work.

On Wed, Dec 23, 2015 at 12:48:28PM -0800, Florian Fainelli wrote:
> 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.

The component framework needs one master device and a number of slave
devices. The master device effectively gives the framework a list of
slave devices it needs. When the slave devices probe they register
with the component framework. The master then asks the framework if
its slaves are present, and if not returns -EPRODE_DEFERS and tries
again later.

So the dsa platform device is the master, and the switch devices are
the slaves.

It sounds like you want to 'optimise' for a DSA cluster consisting of
a single switch, throwing away the D in DSA. Now the SF2 is a bit
'odd'. Since it is embedded in the SoC, you cannot have multiple of
them in a cluster. So such an optimization could make sense for the
SF2. But can we do this without adding too more complexity?

     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