|Aleksandr Rybalko||Jan 20, 2012 12:12 pm|
|Stefan Bethke||Jan 20, 2012 3:34 pm|
|Stefan Bethke||Jan 22, 2012 7:30 am|
|Aleksandr Rybalko||Jan 22, 2012 9:51 am|
|Adrian Chadd||Jan 24, 2012 11:12 pm|
|Stefan Bethke||Jan 25, 2012 12:57 am|
|Adrian Chadd||Jan 26, 2012 10:03 pm|
|Aleksandr Rybalko||Jan 28, 2012 2:12 pm|
|Juli Mallett||Jan 28, 2012 2:59 pm|
|Warner Losh||Jan 28, 2012 11:05 pm|
|Aleksandr Rybalko||Jan 29, 2012 3:14 am|
|Stefan Bethke||Jan 29, 2012 4:25 am|
|Aleksandr Rybalko||Jan 29, 2012 4:43 am|
|Stefan Bethke||Jan 29, 2012 4:48 am|
|Stefan Bethke||Jan 29, 2012 5:14 am|
|Marius Strobl||Jan 29, 2012 7:31 am|
|Stefan Bethke||Jan 29, 2012 8:00 am|
|Marius Strobl||Jan 29, 2012 8:19 am|
|Stefan Bethke||Jan 29, 2012 8:21 am|
|Marius Strobl||Jan 29, 2012 9:31 am|
|Adrian Chadd||Jan 29, 2012 10:59 am|
|Marius Strobl||Jan 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|
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.
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "free...@freebsd.org"