22 messages in org.freebsd.freebsd-archRe: Ethernet Switch Framework| From | Sent On | Attachments |
|---|---|---|
| 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 2:12:53 pm | |
| List: | org.freebsd.freebsd-arch | |
On Sun, Jan 29, 2012 at 11:00:22AM -0800, Adrian Chadd wrote:
I think for switches, that doesn't necessarily hold.
Err, what exactly doesn't hold? The suggestion about using multi-pass probing was just for the case when there's a separate MDIO master other drivers depend on. The latter would just use the default ordering (unless there are again ordering constraints whithin them). So if there's no separate MDIO master driver invovled that is attached first, the other drivers would still just be attached in the default ordering.
ie, mii_attach() for single-PHY devices may work that way, but the weird
What way?
and wonderful world of embedded switch SoC's doesn't. You're lucky in most instances since the bootloader does give you a mostly-working switch config. But I doubt that's a guarantee on all platforms.
So for those (ethernet) devices, splitting out the mii/mdio stuff and _not_ necessarily presenting a working PHY may be acceptable. For now it's going
If there isn't a single working PHY, why would one want to attach miibus(4) in the first place? What is about the opposite case, when all you have is a MDIO master and a switch connected to it, but no MAC on the MII lines of the switch?
to be a subset, to having it export an MDIO bus and doing late MII attachment may not be as architecturally "no-no" as I interpret your post.
Originally, Stefan said that he wants to find a way to support all the odd combinations found in the embedded-world and I try to come up with model that is able to do that without needing hacks and hints left and right. As imp@ said, interrupt controllers and GPIO basically suffer the same dependency constraints across otherwise unrelated devices there, so we really should find a way to properly deal with that situation without again needing another set of hacks and hints in other types of drivers. As for MDIO you actually can have another layer of dependencies between MDIO master, Ethernet switch and PHY, f.e. at work we use a single MDIO master and switch it to different slave busses using a multiplexer managed via GPIO ... not that I'd ever wanted to support this via generic means in FreeBSD.
Marius
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "free...@freebsd.org"