Extending sys/dev/mii

[Stefan Bethke-2]

As discussed recently, ray@, adrian@ and myself are trying to get a framework and utility into the tree that allows the use and configuration of ethernet switch chips.  The switch controllers we've looked at so far share a number of features, in particular they use 802.3 MII, MDIO and PHYs to implement and configure the ports they offer.  In addition to being a switch, some of them also offer one of the built-in PHYs to the ethernet controller as a classical PHY.

Since the switch is already using MDIO and PHYs, it seems sensible to reuse the existig sys/dev/mii code.  However, the current code assumes a simple model where the ethernet controller has one MAC and an MDIO master, and the PHYs are attached to these two busses.  In addition, the code assumes that all attached child drivers of an miibus will always be PHY drivers (using custom dispatch table, specific ivars, etc.)

I'd like to extend miibus in such a way that the one-to-one mapping between MDIO and MII is broken up.  For that, I propose to add a new bus driver "mdiobus" (with appropriate resource management) that uses methods similar to miibus_if.m readreg and writereg to access an ethernet controllers' MDIO master.  miibus then attaches to it as a child, claims one or more PHY addresses and attaches PHYs to itself (as currently implemented).

This allows our new switch drivers to attach to the mdiobus as children and claim appropriate PHY addresses as resources, as well.

The current miibus code assumes that it is attached to the ethernet driver, and will call MIIBUS_STATCHG on its parent to inform it of PHY link changes.  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.

At the same time, I'd like to unravel the use of callbacks in miibus and in the PHY drivers.  On the one hand the miibus_if.m has three callbacks (statchg, linkchg, mediainit), on the other hand the bus keeps three function pointers (mii_data.mii_readreg, mii_writereg, mii_statchg) that it never uses(?), plus two others (miibus_ivars.ifmedia_upd and ifmedia_sts) that are regularly called to provide link updates to the interface.  I would be interested to learn why these are spread out like this (hysterical raisins?), and why they can't just be handled in the usual bus method manner.  (Documentation wouldn't hurt either :-)

Despite this long description, I believe that the code changes are relatively minor.  The major issue is the proposed ABI change for the callback functions, which probably will involve updating all drivers calling mii_attach().  It might be possible to have the existing function provide a compatibility wrapper around the new attachment code.

There's one issue that I don't have a proposal for yet: in one platform (AR7241), we have PHY4 of the SoC talking via MII to arge0's MAC, while it is being controlled via the switch controller's MDIO master, and the switch controller being attached to arge1's MDIO.  If we want to attach an miibus for PHY4, we'd have to defer attachment of arge0 until arge1 has been probed and can provide the MDIO attachment (and transitively the switch and it's mdio).  Note that we also have boards without a switch, but the two PHYs still being attached to only a single MDIO.  One possible way would be for the MDIO driver to be separate from the ethernet driver, so that the normal newbus dependency resolution can be used to ensure that mdio1 is attached before arge0 is probed.  For the time being, I've worked around this through hackery in if_arge.c.

I currently have some parts of this implemented to the point where the PHY in the switch is properly working together with arge0.  I hope to have a complete patch for review in a couple of weeks, but I'd appreciate comments on the general approach I have outlined here.

You can find my current code in the work/ath branch at http://www.gitorious.org/~stb/freebsd/stb-adrianchadd-freebsd-work.  I've written up a couple of points about the ethernet switch work at http://wiki.freebsd.org/StefanBethke/EtherSwitch.


Stefan

--
Stefan Bethke <[hidden email]>   Fon [phone]

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Adrian Chadd-2]

I'm including -net here so we can try and pull in further feedback
from network-cluey people.

On 4 January 2012 08:03, Stefan Bethke <[hidden email]> wrote:
> As discussed recently, ray@, adrian@ and myself are trying to get a framework and utility into the tree that allows the use and configuration of ethernet switch chips.  The switch controllers we've looked at so far share a number of features, in particular they use 802.3 MII, MDIO and PHYs to implement and configure the ports they offer.  In addition to being a switch, some of them also offer one of the built-in PHYs to the ethernet controller as a classical PHY.

[snip]

> I'd like to extend miibus in such a way that the one-to-one mapping between MDIO and MII is broken up.  For that, I propose to add a new bus driver "mdiobus" (with appropriate resource management) that uses methods similar to miibus_if.m readreg and writereg to access an ethernet controllers' MDIO master.  miibus then attaches to it as a child, claims one or more PHY addresses and attaches PHYs to itself (as currently implemented).

This sounds like a good idea. I wonder what's stopping us from doing that. :)

> There's one issue that I don't have a proposal for yet: in one platform (AR7241), we have PHY4 of the SoC talking via MII to arge0's MAC, while it is being controlled via the switch controller's MDIO master, and the switch controller being attached to arge1's MDIO.  If we want to attach an miibus for PHY4, we'd have to defer attachment of arge0 until arge1 has been probed and can provide the MDIO attachment (and transitively the switch and it's mdio).  Note that we also have boards without a switch, but the two PHYs still being attached to only a single MDIO.  One possible way would be for the MDIO driver to be separate from the ethernet driver, so that the normal newbus dependency resolution can be used to ensure that mdio1 is attached before arge0 is probed.  For the time being, I've worked around this through hackery in if_arge.c.

juli@ proposed something quite similar a few weeks ago. Now that I'm a
little more clued up on this whole area, I now understand why she
suggested it.

I'm happy with "hacky" being in if_arge for now (I mean, there already
_is_ ..) but this work seems like the right path to take to bring
sanity to this whole setup in the longer term.

Thanks for tackling this!


Adrian
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Marius Strobl]

On Wed, Jan 04, 2012 at 05:03:41PM +0100, Stefan Bethke wrote:
> As discussed recently, ray@, adrian@ and myself are trying to get a framework and utility into the tree that allows the use and configuration of ethernet switch chips.  The switch controllers we've looked at so far share a number of features, in particular they use 802.3 MII, MDIO and PHYs to implement and configure the ports they offer.  In addition to being a switch, some of them also offer one of the built-in PHYs to the ethernet controller as a classical PHY.
>
> Since the switch is already using MDIO and PHYs, it seems sensible to reuse the existig sys/dev/mii code.

The intention of miibus(4) was to factor out the common code for
handling PHYs conforming to IEEE 802.3, specifically chapter 22.
Before Ethernet drivers for controllers that have an MII interface
duplicated that code over and over again.
The problem with switches is that even if they ave an MII management
interface they often don't comply with IEEE 802.3 (also note that
chapter 22 right at the beginning says that the MII is for connecting
MACs with PHYs) in that they don't implement the basic registers and/
or the ID registers and/or implement something entirely different at
the same addresses. Also a switch with an MII isn't necessarily
connected to a MAC in he first place, f.e. you could simply drive it
via bitbanging using GPIOs of a microcontroller. All that stuff makes
it rather hard to support these with a generic framework that's
laid out around IEEE 802.3. That's also why I think that miibus(4)
isn't the right vehicle to support all these kinds of switches even
if they have an MII interface. If the idea is to only support those
via miibus(4) that actually hang off of a MAC and act like a IEEE
802.3 PHY I'm fine with that though.

> However, the current code assumes a simple model where the ethernet controller has one MAC and an MDIO master, and the PHYs are attached to these two busses.  In addition, the code assumes that all attached child drivers of an miibus will always be PHY drivers (using custom dispatch table, specific ivars, etc.)

I'd say that description is to strict. Currently the only real
"limiting" factor is that miibus(4) attaches and adds ifmedia and
while that only partly makes sense for a switch when it's connected
to a MAC it completely doesn't if there's no MAC. But as far as
miibus(4) goes its parent doesn't necessarily need to be a MAC
driver and also while it's children need to have a mii_softc or
at least a softc that begins with a struct mii_softc for the
most part you could also just ignore that miibus(4) assigns instance
variables to it and a child also doesn't necessarily need to do
anything in the mii_phy_funcs that are part of the mii_softc.
A child of the miibus(4) could also just sit there and twiddle some
registers of something that isn't a PHY but then the question is
why you'd want to handle the whole thing via miibus(4) in the first
place ...

>
> I'd like to extend miibus in such a way that the one-to-one mapping between MDIO and MII is broken up.  For that, I propose to add a new bus driver "mdiobus" (with appropriate resource management) that uses methods similar to miibus_if.m readreg and writereg to access an ethernet controllers' MDIO master.  miibus then attaches to it as a child, claims one or more PHY addresses and attaches PHYs to itself (as currently implemented).
>
> This allows our new switch drivers to attach to the mdiobus as children and claim appropriate PHY addresses as resources, as well.

This generally sounds fine so far.

>
> The current miibus code assumes that it is attached to the ethernet driver, and will call MIIBUS_STATCHG on its parent to inform it of PHY link changes.

That's not correct. It's true that miibus(4) calls the statchg method
of its parent but that doesn't necessarily need to be an Ethernet
driver. It could as well be mdiobus(4) which then bubbles up the
request to the Ethernet driver (if there is one). Actually that's
one of the benefits of newbus. In the past there was a requirement
that the parent had the ifnet pointer at the beginning of it's
softc but I fixed that with the introduction of mii_attach() so
you now can supply a ifnet pointer from anywhere higher in the
hierarchy you want.

> 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.

Again I see no technical reason for such a change. While it would
be nice to only need to pass one pointer around instead of two this
IMO doesn't outweight the churn throughout all MAC drivers and the
ABI breakage this would cause, which means that such a change can't
be MFC'ed, needs #ifdefs on drivers that are maintained as multi-
release versions etc. It could very well be that there actually is
the technical necessity to change the API of mii_attach() in order
to support switch PHYs but so far you failed to make clear what
that would be.

> At the same time, I'd like to unravel the use of callbacks in miibus and in the PHY drivers.  On the one hand the miibus_if.m has three callbacks (statchg, linkchg, mediainit), on the other hand the bus keeps three function pointers (mii_data.mii_readreg, mii_writereg, mii_statchg) that it never uses(?), plus two others (miibus_ivars.ifmedia_upd and ifmedia_sts) that are regularly called to provide link updates to the interface.  I would be interested to learn why these are spread out like this (hysterical raisins?), and why they can't just be handled in the usual bus method manner.  (Documentation wouldn't hurt either :-)

Just read the comments and the VCS history; mii{,bus}(4) origins
in BSD/OS and was reimplemented in NetBSD using a compatible API.
>From there it was ported/copied to OpenBSD and also ported to
FreeBSD. The FreeBSD implementation is a compromise between
integrating it with newbus and maintaining API-compatibility
with NetBSD (to-date the FreeBSD miibus(4) actually is still
highly API-compatible with NetBSD; if you use the helper
functions FreeBSD has grown since then all it really takes to
port a PHY driver from NetBSD is to replace some headers and to
adjust the arguments of the probe and attach methods). The
newbus integration without doubts could have been done a bit
better in some respects though.
The mii_readreg, mii_writereg and mii_statchg pointers of struct
mii_data you mention are what NetBSD and OpenBSD use instead of
the newbus interface. I'm aware that they are unused in FreeBSD
and they probably were forgotten to be removed when the code
was ported over. Though as they already were there I decided to
keep them as placeholders in case we wanted to MFC an otherwise
ABI-breaking change extending struct mii_data back. It might make
sense to rename them in order to make it clear that they only
serve as placeholders.
The ifmedia_upd and ifmedia_sts pointers could be implemented
as newbus methods as well but given that these are passed to
ifmedia_init(9) using pointers passed via instance variables
probably was the more straight forward approach given that
you don't really need to support a hierarchy here.

>
> Despite this long description, I believe that the code changes are relatively minor.  The major issue is the proposed ABI change for the callback functions, which probably will involve updating all drivers calling mii_attach().  It might be possible to have the existing function provide a compatibility wrapper around the new attachment code.

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.

>
> There's one issue that I don't have a proposal for yet: in one platform (AR7241), we have PHY4 of the SoC talking via MII to arge0's MAC, while it is being controlled via the switch controller's MDIO master, and the switch controller being attached to arge1's MDIO.  If we want to attach an miibus for PHY4, we'd have to defer attachment of arge0 until arge1 has been probed and can provide the MDIO attachment (and transitively the switch and it's mdio).  Note that we also have boards without a switch, but the two PHYs still being attached to only a single MDIO.  One possible way would be for the MDIO driver to be separate from the ethernet driver, so that the normal newbus dependency resolution can be used to ensure that mdio1 is attached before arge0 is probed.  For the time being, I've worked around this through hackery in if_arge.c.
>

What I proposed here to properly deal with this case is to
multiplex the MII sharing above the MAC drivers, which then
also is independent of the probe order:
http://lists.freebsd.org/pipermail/freebsd-net/2011-December/030646.html
With your latter approach it's unclear to me how you would
link mdio1 and arge0, which would be siblings on the same
bus if I get you right, i.e. either you attach miibus(4) to
mdio(4) and then would need to pass the status and update
handlers of arge0 to mdio1 or you attach miibus(4) to
arge1 and then would need to somehow access the MII readreg
and writereg methods of mdio1 there.

Marius

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Stefan Bethke-2]

Thank you for your extensive reply, that really helps my understanding of the code!

Am 04.01.2012 um 22:59 schrieb Marius Strobl:

> On Wed, Jan 04, 2012 at 05:03:41PM +0100, Stefan Bethke wrote:
>> As discussed recently, ray@, adrian@ and myself are trying to get a framework and utility into the tree that allows the use and configuration of ethernet switch chips.  The switch controllers we've looked at so far share a number of features, in particular they use 802.3 MII, MDIO and PHYs to implement and configure the ports they offer.  In addition to being a switch, some of them also offer one of the built-in PHYs to the ethernet controller as a classical PHY.
>>
>> Since the switch is already using MDIO and PHYs, it seems sensible to reuse the existig sys/dev/mii code.
>
> The intention of miibus(4) was to factor out the common code for
> handling PHYs conforming to IEEE 802.3, specifically chapter 22.
> Before Ethernet drivers for controllers that have an MII interface
> duplicated that code over and over again.
> The problem with switches is that even if they ave an MII management
> interface they often don't comply with IEEE 802.3 (also note that
> chapter 22 right at the beginning says that the MII is for connecting
> MACs with PHYs) in that they don't implement the basic registers and/
> or the ID registers and/or implement something entirely different at
> the same addresses. Also a switch with an MII isn't necessarily
> connected to a MAC in he first place, f.e. you could simply drive it
> via bitbanging using GPIOs of a microcontroller. All that stuff makes
> it rather hard to support these with a generic framework that's
> laid out around IEEE 802.3. That's also why I think that miibus(4)
> isn't the right vehicle to support all these kinds of switches even
> if they have an MII interface. If the idea is to only support those
> via miibus(4) that actually hang off of a MAC and act like a IEEE
> 802.3 PHY I'm fine with that though.

The reason I'm even looking at miibus is to avoid code duplication.  I agree that miibus is not the right driver for switches that do not implement the .3 PHY register set.  *However*, the switch chips that we're looking at (all part of shipping consumer products that I would love to be able to run FreeBSD on) implement PHYs with the proper register set.  These PHYs can successfully be driven by ukphy.  The hard part: on some switch models, the MDIO these PHYs are on are not the MDIO the MII is on.  I've drawn three diagrams (http://wiki.freebsd.org/StefanBethke/EtherSwitch) to illustrate two existing hardware setups that cannot be supported by miibus with either changes to miibus (AFAIKT).

If you feel that changing miibus to allow this split between MDIO and MII is not advisable, I can create workarounds, but I'd much rather avoid writing workarounds.

>> However, the current code assumes a simple model where the ethernet controller has one MAC and an MDIO master, and the PHYs are attached to these two busses.  In addition, the code assumes that all attached child drivers of an miibus will always be PHY drivers (using custom dispatch table, specific ivars, etc.)
>
> I'd say that description is to strict. Currently the only real
> "limiting" factor is that miibus(4) attaches and adds ifmedia and
> while that only partly makes sense for a switch when it's connected
> to a MAC it completely doesn't if there's no MAC. But as far as
> miibus(4) goes its parent doesn't necessarily need to be a MAC
> driver and also while it's children need to have a mii_softc or
> at least a softc that begins with a struct mii_softc for the
> most part you could also just ignore that miibus(4) assigns instance
> variables to it and a child also doesn't necessarily need to do
> anything in the mii_phy_funcs that are part of the mii_softc.
> A child of the miibus(4) could also just sit there and twiddle some
> registers of something that isn't a PHY but then the question is
> why you'd want to handle the whole thing via miibus(4) in the first
> place …

Wouldn't that be rather brittle?  miibus has a defined interface (and with your explanations, I believe I now understand it), so poking around in the innards and forcing parts into the bus that don't really belong there feels wrong.

>> The current miibus code assumes that it is attached to the ethernet driver, and will call MIIBUS_STATCHG on its parent to inform it of PHY link changes.
>
> That's not correct. It's true that miibus(4) calls the statchg method
> of its parent but that doesn't necessarily need to be an Ethernet
> driver. It could as well be mdiobus(4) which then bubbles up the
> request to the Ethernet driver (if there is one). Actually that's
> one of the benefits of newbus. In the past there was a requirement
> that the parent had the ifnet pointer at the beginning of it's
> softc but I fixed that with the introduction of mii_attach() so
> you now can supply a ifnet pointer from anywhere higher in the
> hierarchy you want.

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.
>
> Again I see no technical reason for such a change. While it would
> be nice to only need to pass one pointer around instead of two this
> IMO doesn't outweight the churn throughout all MAC drivers and the
> ABI breakage this would cause, which means that such a change can't
> be MFC'ed, needs #ifdefs on drivers that are maintained as multi-
> release versions etc. It could very well be that there actually is
> the technical necessity to change the API of mii_attach() in order
> to support switch PHYs but so far you failed to make clear what
> that would be.

See above.

[ suggested cleanup of methods and callbacks and history lesson removed ]

>> Despite this long description, I believe that the code changes are relatively minor.  The major issue is the proposed ABI change for the callback functions, which probably will involve updating all drivers calling mii_attach().  It might be possible to have the existing function provide a compatibility wrapper around the new attachment code.
>
> 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.


Thanks,
Stefan

--
Stefan Bethke <[hidden email]>   Fon [phone]



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Stefan Bethke-2]

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.)

A second patch will implement a separate MDIO bus driver, but I haven't finished that yet.  It s completely independent of the above change.


Stefan

--
Stefan Bethke <[hidden email]>   Fon [phone]

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Stefan Bethke-2]

(Now with actual patch attached. Thanks ray!)

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.)

A second patch will implement a separate MDIO bus driver, but I haven't finished that yet.  It s completely independent of the above change.


Stefan

--
Stefan Bethke <[hidden email]>   Fon [phone]


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[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. 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. For the following scenario:
fooeth0
   |
mdiobus0
   |    \
miibus0 (ethswitch0 or whatever)
   |
foophy0

In mdiobus(4) you'd simply do:
        DEVMETHOD(miibus_statchg, mdiobus_statchg),
<...>
static void
mdiobus_statchg(device_t dev)
{

        parent = device_get_parent(dev);
        MIIBUS_STATCHG(device_get_parent(dev));
}

in order to bubble up the miibus_statchg-method call from miibus0 to
fooeth0. Likewise for the miibus_{linkchg,mediainit,readreg,writereg}.
This isn't a work-around but how newbus works, just see the various
bus drivers in the tree.
I agree that if you'd want to do something like the following in
order to "solve" the problem with arge(4):
     nexus0
     /    \
  arge0  arge1
           |
       mdiobus0
         /   \
    miibus0  miibus1
        |      |
    foophy0  foophy1

or even:
     nexus0
    /   |  \
arge0 arge1 mdio0
            /   \  
        miibus0 miibus1
            |     |
       foophy0  foophy1

then newbus is inconvenient here as it's just not how newbus is
designed. But then calling the miibus_statchg-method etc on the
Ethernet driver device also isn't your only problem as there's
no newbus way to connect miibus0 with arge0 in the upper or
arge0/arge1 with mdio0 in the lower diagram. Such architectures
are just one big hack in the newbus point of view as you'd need
to sidestep newbus with something like your patch.
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

Then you once again can bubble up things just fine. Basically
look at scc(4) how to implement this, i.e. miimux(4) (or
whatever you'd like to call it) would have a core, various
bus-frontends (for nexus(4), pci(4) etc) and MAC-specific
device parts for AR71xx etc. Then the probe routine of the
nexus-frontend of miimux(4) would need claim the devices
for arge0/1 in this setup (you'd probably need to provide a
way to easily hard-code or specify this via hints as I
can't imagine a way to auto-detect that) by returning a
higheR probe value than arge(4) does. Apart from that
it just needs to pass-through the bus resources to arge(4)
and implement miibus_{readreg,writereg}-methods for the
shared AR71xx MDIO master. In turn arge(4) would have two
bus-frontends, one for nexus(4) (for the "normal" case)
and one for miimux(4). In case it attaches to miimux(4)
it then would just bubble up miibus_{readreg,writereg}-
calls but terminate miibus_{linkchg,mediainit,statchg)-
calls locally. Besides doing whatever it needs to do to
configure the switch, ethswitch(4) would also just always
bubble up the miibus_if.m methods. Besides being the
clean way to do this from the newbus point of view this
architecture also needs zero changes to miibus(4).

Marius

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Stefan Bethke-2]

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.

I would like to find a solution that allows us to plug together an ethernet driver, a driver that makes that MDIO bus available, and the miibus/phy combo with minimal effort.  Writing a driver framework that can be interposed between arbitrary drivers in the system to pass one message from the PHY to the ethernet driver seems rather convoluted to me.  (Yes, for the concrete case we can always hack something up, but I'm trying to find something better than that.)


Stefan

--
Stefan Bethke <[hidden email]>   Fon [phone]



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[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?

Marius

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Stefan Bethke-2]

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 <[hidden email]>   Fon [phone]



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Marius Strobl]

On Fri, Jan 06, 2012 at 10:53:14PM +0100, Stefan Bethke wrote:

>
> 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.
>

Okay, this is the kind of information I was looking for as coupling
devices with newbus that have no close relation in the hierarchy is
tedious. However, when not using newbus the question arises how do
you intend to associate the device_t of say arge0 with the mdiobus0
hanging off somewhere beneath iicbus0?

Marius

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Stefan Bethke-2]

Am 08.01.2012 um 14:00 schrieb Marius Strobl:

> Okay, this is the kind of information I was looking for as coupling
> devices with newbus that have no close relation in the hierarchy is
> tedious. However, when not using newbus the question arises how do
> you intend to associate the device_t of say arge0 with the mdiobus0
> hanging off somewhere beneath iicbus0?

In my experimental tree, I've hacked together a small function that parses a string for a devclass name and unit number, and looks that up.

I'm also trying a number of other approaches; mainly I'm trying to understand how newbus works, and what kind of driver I want at the various points, ideally auto-attached, or configured by hints, instead of by custom code.  I think I'll need another couple of days to get a good enough understanding of drivers, devclasses and their tree, and the device tree.


Stefan

--
Stefan Bethke <[hidden email]>   Fon [phone]



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Adrian Chadd-2]

On 8 January 2012 14:27, Stefan Bethke <[hidden email]> wrote:

>> Okay, this is the kind of information I was looking for as coupling
>> devices with newbus that have no close relation in the hierarchy is
>> tedious. However, when not using newbus the question arises how do
>> you intend to associate the device_t of say arge0 with the mdiobus0
>> hanging off somewhere beneath iicbus0?
>
> In my experimental tree, I've hacked together a small function that parses a string for a devclass name and unit number, and looks that up.
>
> I'm also trying a number of other approaches; mainly I'm trying to understand how newbus works, and what kind of driver I want at the various points, ideally auto-attached, or configured by hints, instead of by custom code.  I think I'll need another couple of days to get a good enough understanding of drivers, devclasses and their tree, and the device tree.

Hi guys,

Has there been any further traction on this? I'd like to try and
figure out a way to get all this switchphy stuff into -HEAD as soon as
possible.

Thanks,


Adrian
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Marius Strobl]

On Sun, Jan 08, 2012 at 11:27:25PM +0100, Stefan Bethke wrote:

> Am 08.01.2012 um 14:00 schrieb Marius Strobl:
>
> > Okay, this is the kind of information I was looking for as coupling
> > devices with newbus that have no close relation in the hierarchy is
> > tedious. However, when not using newbus the question arises how do
> > you intend to associate the device_t of say arge0 with the mdiobus0
> > hanging off somewhere beneath iicbus0?
>
> In my experimental tree, I've hacked together a small function that parses a string for a devclass name and unit number, and looks that up.
>
> I'm also trying a number of other approaches; mainly I'm trying to understand how newbus works, and what kind of driver I want at the various points, ideally auto-attached, or configured by hints, instead of by custom code.  I think I'll need another couple of days to get a good enough understanding of drivers, devclasses and their tree, and the device tree.
>

Okay, I suggest to postpone this discussion until then. For the
scenario when mdiobus is the parent of miibus I see no technical
need to change miibus to support what you want to do, just implement
the miibus_if in mdiobus and redirect it to the device_t of the
MAC there. Moreover, that way the hack to sidestep newbus is contained
in the layer that actually needs it and not scattered over multiple
frameworks.

Marius

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Adrian Chadd-2]

Hi Marius, etc;

Does the miibus code actually obey newbus at the moment? Or is it also
cutting corners somehow?


Adrian
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Warner Losh]

On Jan 14, 2012, at 9:16 PM, Adrian Chadd wrote:
> Does the miibus code actually obey newbus at the moment? Or is it also
> cutting corners somehow?

It actually mostly obeys newbus at the moment.  Any places that may seem to be cutting corners are actually interfacing to lower-layers that don't participate in newbus (like if_media).  dcphy is also a little weird because it isn't really a PHY connected via a MII bus at all.  There may also be a few allowances made since it has been ported (and reported) to and from NetBSD and BSD/os a few times.

Warner

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Stefan Bethke-2]

Am 11.01.2012 um 20:37 schrieb Marius Strobl:

> Okay, I suggest to postpone this discussion until then. For the
> scenario when mdiobus is the parent of miibus I see no technical
> need to change miibus to support what you want to do, just implement
> the miibus_if in mdiobus and redirect it to the device_t of the
> MAC there. Moreover, that way the hack to sidestep newbus is contained
> in the layer that actually needs it and not scattered over multiple
> frameworks.

I've posted to -net a patch that implements a workaround along those lines.  It solves two issues: talking to two upstream devices, and providing a proper attachment for miibus.

There's a number of things that made this harder than I would have liked:
- miibus has a funny way of attaching to it's parent.  Making the parent a bus that automatically attaches matching children does not lead to good results.
- miibus uses it's parents ivars.  To clarify: device_get_ivars get's a devices ivars, but those are owned by the parent; the bus uses device_[gs]et_ivars(9) to manipulate it's own private per-child data storage.  The device must not manipulate them.  I believe those variables can be moved to mii_data.
- miibus makes assumptions about it's children, namely that they have specific softc's and that they provide callbacks outside of the newbus method mechanism
- miibus assumes that all devices attached to that mdio have certain registers that have certain bits set or cleared
- miibus calls it's parent methods and two explicit callbacks, plus various calls into the interface management code.

The second problem is that there's currently no way to express a dependency between two devices other than a parent-child relationship.   I would be interested to learn why this appears to be so uncommon that I could not find any discussion of such a feature.  Has it really never before come up?

Leaving aside the miibus issue, the newbus problem is that the ethernet driver (which is attached to some bus) needs to associate with some other driver that might not be in it's vincinity, in particular neither it's parent nor one of it's children.  Compounding the problem is that there is no way to express an attachment ordering constraint so that the ethernet driver is only attached once the required mdio driver has attached.


Stefan

--
Stefan Bethke <[hidden email]>   Fon [phone]



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Warner Losh]

On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote:
> The second problem is that there's currently no way to express a dependency between two devices other than a parent-child relationship.   I would be interested to learn why this appears to be so uncommon that I could not find any discussion of such a feature.  Has it really never before come up?

Sure there is: you can do it by name.  I wrote a driver that attached to the ISA bus, but also needed to talk to the ppbus that was attached to the printer.  My solution was to have a post-attach name-lookup so that it could then call methods on the other driver's device_t.  I wonder why we can't do that here?

Warner

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Oleksandr Tymoshenko-2]

On 20/01/2012 5:43 PM, Warner Losh wrote:
>
> On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote:
>> The second problem is that there's currently no way to express a dependency between two devices other than a parent-child relationship.   I would be interested to learn why this appears to be so uncommon that I could not find any discussion of such a feature.  Has it really never before come up?
>
> Sure there is: you can do it by name.  I wrote a driver that attached to the ISA bus, but also needed to talk to the ppbus that was attached to the printer.  My solution was to have a post-attach name-lookup so that it could then call methods on the other driver's device_t.  I wonder why we can't do that here?

     I've been thinking about it recently in regard to GPIO subsystem.
And the same issue appeared during OMAP code import: there are at least
two subsystems that are used by the rest of the drivers. Ben's suggested
following solution: define kobj interface if_SUBSYTEM.m and then
provide API call in form:

     int omap_prcm_clk_enable(clk_ident_t clk)
     {
         device_t prcm_dev;

         prcm_dev = devclass_get_device(devclass_find("omap_prcm"), 0);
         if (prcm_dev == NULL) {
             printf("Error: failed to get the PRCM device\n");
             return (EINVAL);
         }

         return OMAP_PRCM_CLK_ENABLE(prcm_dev, clk);
     }

So it might make sense to create some kind of upper-level API for
defining this kind of subsystems' APIs since every implementation
would duplicate a lot of code: look for instance of specific
devclass, check if it exists. Not sure how to do it at the moment
though.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

[Stefan Bethke-2]

Am 21.01.2012 um 02:43 schrieb Warner Losh:

>
> On Jan 20, 2012, at 5:08 PM, Stefan Bethke wrote:
>> The second problem is that there's currently no way to express a dependency between two devices other than a parent-child relationship.   I would be interested to learn why this appears to be so uncommon that I could not find any discussion of such a feature.  Has it really never before come up?
>
> Sure there is: you can do it by name.  I wrote a driver that attached to the ISA bus, but also needed to talk to the ppbus that was attached to the printer.  My solution was to have a post-attach name-lookup so that it could then call methods on the other driver's device_t.  I wonder why we can't do that here?


That was my first approach, but the attachment sequence foiled it: arge0 is probed and attached before the device that provides the MDIO bus arge0 needs to attach the miibus and phy.  As far as I can tell, there is no way to express (via code or hints or otherwise) that a device should be attached only after some other device has been attached.

The solution for me was to write miiproxy which contains code that waits for both devices to attach, and then calls a callback on arge0 to complete the interface attachment (attaches miibus, makes the interface available).

From a driver writers point of view, it would be desirable to be able to say "attach this only after 'foo0' has been attached", so the attach method can still be a single, linear piece of code.


Stefan

--
Stefan Bethke <[hidden email]>   Fon [phone]



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"