ray at ddteam.net
Sun Feb 12 18:39:27 UTC 2012
On Sat, 11 Feb 2012 21:06:10 -0800
Juli Mallett <jmallett at FreeBSD.org> wrote:
> On Sat, Feb 11, 2012 at 20:59, Warner Losh <imp at bsdimp.com> wrote:
> >> The trouble in this whole mess (where FDT may help) is that phy's
> >> for arge0 may actually sit on arge1. So you can't probe/attach the
> >> miibus on arge0 until you've probe/attached arge1, so the arge1
> >> MII registers can be tickled.
> > The PHYs don't sit on arge1. They sit on another device that the
> > driver bogusly assumes is tightly coupled to arge1, when in fact it
> > isn't.
> YES! Thank you! And even if it were tightly coupled in hardware,
> there's no reason our device tree needs to mirror that, FDT or not.
> Just break out an "arge controller" device, attach arge0 and arge1 to
> it, and let it manage the MDIO bus. No shortcomings, as far as I can
> tell. You can even be extra clever and say that the switch is
> attached to that device, not either of the arge devices, and that one
> of the arge devices happens to be connected to the switch's CPU/host
> port. But that's probably a bit much to ask for.
Correct me if I say something wrong.
We can make something like "arge controller", but:
1. We already have another driver with similar register set, it is if_et
2. Many MACs have external MDIO pins and for embedded world it is ok to
connect MDIO controlled devices to single MDIO bus.
So what we will do with other device? In some case it even can be
different MACs (not yet seen that, but it's possible).
Now in my device list I have devices that use bfe, arge, rt, octe MACs.
IIRC octe0-octe2 for Octeons really single device with 3 paths, rt
(Ralink RT305xF MAC) also can use two paths (not implemented yet). But
arge, bfe and long list other MACs, which can be used in embedded
devices, is really separate MACs (separate cores in SoC) which we must
be able to handle w/o modification of existing driver.
And since we have way to do that, why not to use that way?
Aleksandr Rybalko <ray at ddteam.net>
More information about the freebsd-arch