43 messages in org.freebsd.freebsd-archRe: Extending sys/dev/mii| From | Sent On | Attachments |
|---|---|---|
| Stefan Bethke | Jan 4, 2012 8:03 am | |
| Adrian Chadd | Jan 4, 2012 9:07 am | |
| Marius Strobl | Jan 4, 2012 1:59 pm | |
| Stefan Bethke | Jan 5, 2012 12:52 pm | |
| Stefan Bethke | Jan 6, 2012 4:56 am | |
| Stefan Bethke | Jan 6, 2012 5:02 am |  .diff |
| Marius Strobl | Jan 6, 2012 10:27 am | |
| Stefan Bethke | Jan 6, 2012 12:35 pm | |
| Marius Strobl | Jan 6, 2012 1:47 pm | |
| Stefan Bethke | Jan 6, 2012 1:52 pm | |
| Marius Strobl | Jan 8, 2012 5:00 am | |
| Stefan Bethke | Jan 8, 2012 2:27 pm | |
| Adrian Chadd | Jan 10, 2012 5:18 pm | |
| Marius Strobl | Jan 11, 2012 11:37 am | |
| Adrian Chadd | Jan 14, 2012 8:15 pm | |
| Warner Losh | Jan 14, 2012 9:13 pm | |
| Stefan Bethke | Jan 20, 2012 3:08 pm | .patch |
| Warner Losh | Jan 20, 2012 5:43 pm | |
| Oleksandr Tymoshenko | Jan 20, 2012 8:12 pm | |
| Stefan Bethke | Jan 21, 2012 4:02 am | |
| Aleksandr Rybalko | Jan 21, 2012 5:12 am | |
| Oleksandr Tymoshenko | Jan 23, 2012 11:45 pm | |
| Aleksandr Rybalko | Jan 24, 2012 5:53 am | |
| Marius Strobl | Jan 25, 2012 2:17 pm | |
| Warner Losh | Jan 25, 2012 2:28 pm | |
| Marius Strobl | Jan 25, 2012 3:21 pm | |
| Hans Petter Selasky | Jan 26, 2012 8:24 am | |
| Stefan Bethke | Jan 26, 2012 8:24 am | |
| Stefan Bethke | Jan 26, 2012 8:30 am | |
| Marius Strobl | Jan 27, 2012 6:15 am | |
| Adrian Chadd | Feb 10, 2012 9:22 pm | |
| Marius Strobl | Feb 11, 2012 3:17 am | |
| Aleksandr Rybalko | Feb 11, 2012 4:45 am | |
| Adrian Chadd | Feb 11, 2012 4:59 pm | |
| Warner Losh | Feb 11, 2012 5:15 pm | |
| Adrian Chadd | Feb 11, 2012 8:48 pm | |
| Warner Losh | Feb 11, 2012 8:58 pm | |
| Juli Mallett | Feb 11, 2012 9:05 pm | |
| Adrian Chadd | Feb 11, 2012 9:19 pm | |
| Aleksandr Rybalko | Feb 12, 2012 9:51 am | |
| Aleksandr Rybalko | Feb 12, 2012 10:04 am | |
| Juli Mallett | Feb 12, 2012 10:30 am | |
| Aleksandr Rybalko | Feb 12, 2012 10:38 am |
| Subject: | Re: Extending sys/dev/mii | |
|---|---|---|
| From: | Stefan Bethke (st...@lassitu.de) | |
| Date: | Jan 6, 2012 1:52:51 pm | |
| List: | org.freebsd.freebsd-arch | |
Am 06.01.2012 um 22:47 schrieb Marius Strobl:
On Fri, Jan 06, 2012 at 09:35:40PM +0100, Stefan Bethke wrote:
Am 06.01.2012 um 19:27 schrieb Marius Strobl:
On Fri, Jan 06, 2012 at 01:57:06PM +0100, Stefan Bethke wrote:
Am 05.01.2012 um 21:52 schrieb Stefan Bethke:
The problem with this is that the miibus instance might not be a (transitive)
child of the ethernet driver that has the MII that needs to be adjusted to the
new PHY settings. And since the method does not provide any parameters about
which phy or miibus did issue the method, or which ifp it applies to, bubbling
it up won't work (that the scenario where the PHY for arge0 is connected to the
switch's MDIO, which is attached to arge1's MDIO).
Since the parent will now be the mdiobus, miibus needs effectively two
attachments, one to the provider of the MDIO access, the other for the ethernet
interface. I propose to associate the ethernet interface by a modified
mii_attach() function that takes a device_t (of the ethernet driver) instead of
the two callback function pointers.
Please elaborate on why these changes are technically necessary to implement what you are trying do. Otherwise I prefer to avoid them given the rototilling they'd cause.
Necessary is a strong word. Right now, I'm trying to understand how a sensible
change would even look like, and which combination of glue code and miibus
changes make the most sense.
Let me see if I can come up with a prototype patch the next couple of days, so
we don't have to theorize about the changes that might or might not be
necessary.
Here's a patch that causes zero rototilling, if I'm not mistaken.
The patch implements the split between the MDIO access and notifications posted
to the ethernet interface device that has the MII that needs to be adjusted in
accordance with the PHY autonegotiation results. I've added a field to the
ivars struct and not the softc, because the softc is included by many network
drivers, while the ivars are private to mii.c For this reason, I believe this
change is API and ABI compatible, and likely can be MFCed. (I believe MFCing is
not high on the priority list because many other parts in sys/mips would need to
be MFCed first for all the Atheros platforms to become fully usable, but Adrian
can correct me.)
By calling an newbus method on a device that is not the parent this patch hacks around how newbus is intended to work.
Admittedly, it adds a reference across the tree.
I also still don't see why for the scenarios you describe you can't simply use
miibus(4) as-is in a clean way.
[ Scenarios for which the existing model works ]
That's why I proposed the model that puc(4), scc(4) etc are following to solve this in a clean way, which for arge(4) would look like: nexus0 | miimux0 / \ arge0 arge1 | | ethswitch0 | | | miibus0 miibus1 | | foophy0 foophy1
[ Explanation on how things work with above setup ]
Except that your diagram does not correlate with the scenario I've outlined.
I'll try to explain again: the MDIO master access for the PHY which MII lines
are connected to arge1 are hosted on a separate device. Please refer to this
diagram:
http://wiki.freebsd.org/StefanBethke/EtherSwitch?action=AttachFile&do=get&target=embedded-switch.png
(arge0 and phy4)
To make things as clear as possible, consider an RTL836x controller which is
attached to the system through an I2C bus. (Never mind that it has a switch,
that's not relevant to the discussion here.) It has one MII bus connection
connecting one ethernet interface MAC to one PHY; the MDIO master that can talk
to that PHY is in the RTL836x. The common ancestor for the ethernet driver and
the MDIO driver then are likely to be very near the top, meaning that the
interposed driver would need support not only for the ethernet driver in
question, but the I2C bus as well. An interposed driver at nexus level that
gets the phy linkchg message bubbled up to it does need to send it back down to
the ethernet driver. The message sent by miibus does contains neither source
nor destination information, so that miibus needs to be attached to a unique
driver instances that adds that information to the message before bubbling it
up. Of course, it also needs to get this information from somewhere, so a
reference to the ethernet driver needs to be injected somehow.
Okay, now I'm confused; I don't know the RTL836x but you seem to say that essentially for this discussion this is a I2C to MDIO bridge, with iicbus(4) being involved to access the MDIO of PHYs being new information. Is this scenario supposed to be also covered by embedded-switch.png? If it is, what purpose does the MDIO connection between arge1 and the switch in there serve for?
Yes, for the purpose of this discussion, the RTL836x series is an I2C to MDIO
bridge; the diagram for the Atheros chip is an MDIO to MDIO bridge in that
sense.
Atheros switches, as well as the RTL803x series, have an MDIO slave instead of
an I2C slave, but the basic layout remains the same. The ethernet driver for
arge0 cannot directly talk to PHY4 because it's hanging off some more or less
remote part of the device tree. That's what I'm trying to get across, and
that's the problem I'm trying to solve in a more or less generic way.
Stefan
-- Stefan Bethke <st...@lassitu.de> Fon +49 151 14070811
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "free...@freebsd.org"