netdev - Re: [PATCH RFC v2 00/32] Make DSA switches linux devices.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56E357C7.7090309@gmail.com>
Date:	Fri, 11 Mar 2016 15:41:59 -0800
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Andrew Lunn <andrew@...n.ch>
Cc:	Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH RFC v2 00/32] Make DSA switches linux devices.

On 03/03/16 12:27, Andrew Lunn wrote:
>> - first of all, the original design around the special platform device
>> did not allow multiple switch trees within the same system to coexist
>> (dsa platform device were not numbered (id = -1)), but such a thing
>> could exist and is desirable, you could have a single switch hanging off
>> eth0, and more switches hanging off eth1 for instance, and not be part
>> of the same tree
> 
> I have hardware i can test such a setup on. 
> 
>>
>> - the direction we want to move people to is to make them use DSA for
>> their switch needs and get the proven benefits from having a consistent
>> per-port slave network device model along with a good binding for
>> representing ports within a switch (and all thedetails associated with
>> that), the next step is to make this available to not just MDIO drivers,
>> which you are addressing here, but then, being able to call
>> dsa_switch_register() just becomes a service from the network stack with
>> DSA support included, if we need the special dsa platform device again,
>> we are not way better than where we were before
> 
> We are a bit better. dsa_switch_register() does not care about the
> communication channel to the switch. An SPI based switch should now be
> possible, as well as a cleaner way to do MMIO switches.

Right, thanks to your patch series and recent efforts, and that is
exactly the direction we want.

[snip]

> 
> The third switch is as you would expect, dsa,member = <0 2>;

I like that representation.

> 
> The probe order does not actually matter. You allocate the dst when
> the first switch arrives, and plug that switch in. You then evaluate
> the dst. Are all dsa links fulfilled. If yes, you have the full tree,
> and you can set it up and running. If no, wait until more switches are
> registered.

So does that mean you agree we do not need the DSA platform device
anymore :)? If not, why, and how much help from the Device Tree do we
need to instantiate that special "dsa" platform device?

> 
> This is quite a big change, so why not make it bigger...
> 
> One thing i don't like is the complexity we have in matching phys to
> ports, and fixed-link phys. Maybe we should consolidate this:

Very true, we support a wide variety of setups, and that creates a lot
of complexity that could probably be absorbed by a more generic helper
function?

> 
> 1) The switch device should use mdiobus_alloc()/mdiobus_register() for
> its own MDIO bus.

Agreed, possibly with the help of the DSA slave code, since some of that
is already doing its magic for most drivers here.

> 2) ports use phy-handle to point to phys on their own mdio bus.

I would refrain from needing that unless the mapping between Port and
built-in PHY is design/board-level configurable, or we connect to PHYs
external to the switch which are not located on its own internal MDIO
bus controller.
-- 
Florian