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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20160314205136.GA4964@lunn.ch>
Date:	Mon, 14 Mar 2016 21:51:36 +0100
From:	Andrew Lunn <andrew@...n.ch>
To:	Florian Fainelli <f.fainelli@...il.com>
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 Mon, Mar 14, 2016 at 12:36:18PM -0700, Florian Fainelli wrote:
> On 12/03/16 09:08, Andrew Lunn wrote:
> >> [snip]
> >>
> >>>
> >>> The third switch is as you would expect, dsa,member = <0 2>;
> >>
> >> I like that representation.
> >>
> > 
> > ...
> > 
> >> So does that mean you agree we do not need the DSA platform device
> >> anymore :)?
> > 
> > It looks like it can be	done without the DSA platform device.
> > 
> > My previous approach was to keep the new binding as similar as
> > possible to the current one. If however, we decide we are going for
> > something totally new, we can remove this platform device.
> 
> The old binding can and should remain available

Agreed. "marvell,dsa" will remain and will invoke a platform device,
as is today. That is the old binding.

I'm currently thinking that switch drivers will probe, and then call
something like

int dsa_switch_register(struct dsa_switch *ds, struct device_node *np);

The code behind that will be responsible for allocating the dst,
parsing the binding pointed to by np. It will also evaluate if all the
dsa links are available, and if so, call the setup() method in
ds->drv, etc.

> The new binding looks very similar to the previous one and this is
> certainly a good thing to do. With that in mind the new binding should
> probably be keeping the per-port Device Tree node representation and
> properties, because that one seems correct.

There are some changes. A cpu node will have the phandle to the
ethernet device. I really would like to only have a phandle to a phy,
but we will see, and i want to remove the limit of one cpu node. The
driver can then return -EINVAL during setup() if it cannot handle it.

> the parts that had gone
> wrong were definitively the "reg" property and the dsa,mii-bus property
> if not the dsa,ethernet as well, but code will talk.

reg at the switch level. Yes. We still need reg at the port level.
dsa,mii-bus is gone, and dsa,ethernet moved into the cpu port.

	    Andrew