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:	Thu, 30 Apr 2015 09:50:36 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Andrew Lunn <andrew@...n.ch>
CC:	netdev@...r.kernel.org, davem@...emloft.net,
	vivien.didelot@...oirfairelinux.com,
	jerome.oufella@...oirfairelinux.com, linux@...ck-us.net,
	cphealy@...il.com, mathieu@...eaurora.org, jonasj76@...il.com,
	andrey.volkov@...vision.fr, Chris.Packham@...iedtelesis.co.nz
Subject: Re: [RFC PATCH net-next 0/8] net: dsa: New registration API

On 30/04/15 06:12, Andrew Lunn wrote:
>> Note that there are currenlty no incompatibles changes made to existing Device
>> Tree sources, rather, depending on the bus we are probed for, e.g: MDIO
>> the dsa,mii-bus and dsa,ethernet phandles and first cell of the  "reg" property
>> will become obsolete, everything else remains entirely compatible. 
> 
> Hi Florian
> 
> I'm not sure dsa,mii-bus and dsa,ethernet will become obsolete. At
> least they are probably needed for multi switch setups, and the
> possible but probably unlikely multi DSA setups.
> 
> You cannot assume that dsa,mii-bus and dsa,ethernet have the same
> parent. In a multi switch setup, it could be there is an mdio-mux in
> the picture. So all your probe really tells you, is that there is a
> switch on this mii bus, but you don't know what ethernet it is hanging
> off.

Good point.

> 
> The switch could be hanging off multiple ethernets. I'm working on
> supporting this for the WRT1900AC, where i use the bond driver on the
> host side. So dsa,ethernet is a phandle to a bond interface.

Humm, bond is a software constructs, don't you rather want two phandles
to the relevant Ethernet interfaces instead and then learn through
netlink/netdevice notifiers that these are eventually part of the same bond?

> 
> The probe is likely to find all switches in a multi switch setup. But
> i guess we only want the probe of the root devices in a switch tree to
> cause a DSA setup.

Right.

> 
> So i think there needs to be some matching performed when looking in
> the device tree. The dsa,mii-bus and address discovered by probing
> need to match what is in the DSA properties.

Sure, that's a good point. I tried to start with simple case first, if
you can recommend consumer/off the shelf hardware which has a cascaded
setup, that could help too.

The configuration I have access to with Broadcom switches looks like
this: internal SF2 switch MMIO-mapped, with an external RGMII interface
to a MDIO connected BCM53125 switch.

so this not a true switch tree here, they can (and should) be treated as
different switch trees, attached to different interfaces: eth0 for CPU
for the internal one and the DSA-created "rgmii" interface for the
second switch.
-- 
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ