atom feed22 messages in org.freebsd.freebsd-archRe: Ethernet Switch Framework
FromSent OnAttachments
Aleksandr RybalkoJan 20, 2012 12:12 pm 
Stefan BethkeJan 20, 2012 3:34 pm 
Stefan BethkeJan 22, 2012 7:30 am 
Aleksandr RybalkoJan 22, 2012 9:51 am 
Adrian ChaddJan 24, 2012 11:12 pm 
Stefan BethkeJan 25, 2012 12:57 am 
Adrian ChaddJan 26, 2012 10:03 pm 
Aleksandr RybalkoJan 28, 2012 2:12 pm 
Juli MallettJan 28, 2012 2:59 pm 
Warner LoshJan 28, 2012 11:05 pm 
Aleksandr RybalkoJan 29, 2012 3:14 am 
Stefan BethkeJan 29, 2012 4:25 am 
Aleksandr RybalkoJan 29, 2012 4:43 am 
Stefan BethkeJan 29, 2012 4:48 am 
Stefan BethkeJan 29, 2012 5:14 am 
Marius StroblJan 29, 2012 7:31 am 
Stefan BethkeJan 29, 2012 8:00 am 
Marius StroblJan 29, 2012 8:19 am 
Stefan BethkeJan 29, 2012 8:21 am 
Marius StroblJan 29, 2012 9:31 am 
Adrian ChaddJan 29, 2012 10:59 am 
Marius StroblJan 29, 2012 2:12 pm 
Subject:Re: Ethernet Switch Framework
From:Marius Strobl (mar@alchemy.franken.de)
Date:Jan 29, 2012 9:31:54 am
List:org.freebsd.freebsd-arch

On Sun, Jan 29, 2012 at 05:21:52PM +0100, Stefan Bethke wrote:

Am 29.01.2012 um 17:19 schrieb Marius Strobl:

We really need to find a proper way of dealing with the constraints of the embedded- world rather than to sprinkle hacks all over the place.

Why is the above is less of a hack than making the ordering in nexus
configurable through a hint?

If it's generally true that driver A must be attached before driver B as B has a dependency on A than this should be expressed and configured in the drivers themselves and not need an extra hint to configure it at the runtime of the kernel.

Except that it is not generally true, but only in specific configurations.
Other boards have other combinations of devices. The Atheros family of switches
is available both embedded into certain SoC as well as separate silicon.

It still seems to be true to me that as soon as you have a separate MDIO driver that this one needs to be attached before any Ethernet, switch or whatever driver that needs to talk via the MDIO lines of the former. Similarly, if the switch attaches to an MDIO instance directly, that switch would need to be attached before the Ethernet driver (if there is one) that the switch is the MDIO master for (this isn't exactly the problematic arge-case). Multi-pass is per driver module, so if the switch attaches to a "regular" Ethernet driver providing both the MAC and the MDIO master instead, you can leave the default probe order and attach the switch after the Ethernet driver. So for the problematic arge-case you would attach the MDIO driver first (corresponding to the MDIO of arge1), then the switch to the MDIO driver and both arge0 and arge1 in whatever order last. Allowing that one special case to work properly shouldn't interfere with other device combinations as it basically boils down to the presence of a separate MDIO instance. Actually that should also work just fine when the MDIO master sits on the IIC bus as that again would mean that it needs to be attached before a Ethernet or switch driver can use it.

Marius