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]

Message-ID: <567C9C16.5020005@gmail.com>
Date:	Thu, 24 Dec 2015 17:29:58 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Andrew Lunn <andrew@...n.ch>
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.

Le 23/12/2015 14:53, Andrew Lunn a écrit :
> 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.

Ok, but then that means I still need to have a "marvell,dsa" node in
Device Tree, that does not make sense to me with your changes, because
the individual compatible and nodes for the switches are enough
information to get their driver to probe, and as a consequence, register
with DSA their switch devices, but let's keep following this point in
the cover letter thread.

> 
> 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?

The distributed case is the complex one, the one with a single switch
hanging off an Ethernet MAC is the most common one and is much simpler
to deal with.
-- 
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