Date: Tue, 13 Dec 2011 11:40:00 +0100 From: Stefan Bethke <stb@lassitu.de> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-embedded@freebsd.org Subject: Re: TL-WR1043: switch Message-ID: <5375D2AF-C886-4DB0-A331-39363562D2B4@lassitu.de> In-Reply-To: <CAJ-VmomHqhM57v=1trBp5sC2e8=U04nLQNTp%2BkXeJt468Ei0gw@mail.gmail.com> References: <68ABED76-CB1F-405A-8036-EC254F7511FA@lassitu.de> <3B3DB17D-BF87-40EE-B1C1-445F178E8844@lassitu.de> <86030CEE-6839-4B96-ACDC-2BA9AC1E4AE4@lassitu.de> <2D625CC9-A0E3-47AA-A504-CE8FB2F90245@lassitu.de> <203BF1C8-D528-40C9-8611-9C7AC7E43BAB@lassitu.de> <3C0E9CA3-E130-4E9A-ABCC-1782E28999D1@lassitu.de> <CAJ-VmomWsGy9wMb0zA-WjTRP6Qh%2BO2u_Pe-rgkerFFpi04iKnw@mail.gmail.com> <6387ABA5-AC55-49DD-9058-E45CC0A3E0A0@lassitu.de> <CAJ-VmonM91s-kbbEqVDy9PvtH-gxLWYmusGiqzqCWMtfMdoo2A@mail.gmail.com> <EA0807C1-6FEE-4743-8DCA-1AC873664005@lassitu.de> <74E4AF57-3D22-415E-B913-176753B09B16@lassitu.de> <710E2C7A-E9AC-4103-8C61-0EDC4A3AF9DE@lassitu.de> <C2885254-F02C-401B-B56D-39F62933F3CC@lassitu.de> <CAJ-Vmon%2B-kWGURJ8ktpdztrgHkM5ffdfX4ddFMjYhY9ur_GL1Q@mail.gmail.com> <E46FD75C-6DF3-4FD0-B384-48C5D8E2AB87@lassitu.de> <CAJ-Vmon4LF3LP1v-M=N7eH-3JuQgtHtBsjTho7JNJZjRz4Mo_w@mail.gmail.com> <E62014AC-472A-4F86-A085-6489D6B784D7@lassitu.de> <CAJ-VmomHqhM57v=1trBp5sC2e8=U04nLQNTp%2BkXeJt468Ei0gw @mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 13.12.2011 um 11:06 schrieb Adrian Chadd:
> The trouble ray is having at the moment is where the switch PHY hangs
> off of arge1, rather than arge0. This means that arge0 gets probed and
> has no PHY; then arge1 gets probed and has the switch PHY. I'd rather
> (for now) just have arge0 be "hard" coded up to something and use the
> switch API to configure the switch ports themselves. If that works
> (well enough for now) then we can just get the switch code + drivers
> into -HEAD and get it all polished.
I think it's time for some ASCII art :-)
If I understand correctly how ray@s device is connected, it looks like =
this:
Switch arge
+------+ MII +------+
| PHY4 |-------------------------| MAC1 |
+------+ +------+
+------+ +------+---+------+ +------+
| PHY3 |---| MAC3 | | MAC4 |---| MAC0 |
+------+ +------+ +------+ +------+
+------+ +------+ |
| PHY2 |---| MAC2 | |
+------+ +------+ Switch |
+------+ +------+ core | MDC/MDIO
| PHY1 |---| MAC2 | |-----------
+------+ +------+ |
+------+ +------+ |
| PHY0 |---| MAC0 | |
+------+ +------+----------+
(The actual unit numbers might be different.)
PHY4 is directly attache to arg1, so we can use the standard miibus =
attachment for that.
However, the same MDC/MDIO bus is also used to configure the switch and =
PHYs 0 to 3, so clearly arge1 should not look at those PHYs and their =
registers.
In my RTL8366RB driver, I've added an additional miibus for each of the =
PHYs attached to the switch core, and a struct ifnet to match. I =
believe that is the correct answer here as well, since arge0 has no PHY =
when communicating with MAC4 of the switch, and likely will be hardwired =
for the maximum speed the switch port supports.
I think the question is: how can we hang a switch controller off arge0's =
miibus when it does not represent any actual PHY that arge0 could =
manipulate for it's own MAC and MII interface?
For arge1 and PHY4, we can attach ukphy or one of the standard phy =
drivers. For the switch, the switch driver should present itself as a =
phy, but with only the hardwired media selection available, i. e. not =
actually talking to PHY0 to PHY3. Through the switch management =
interface, it can then expose those PHYs.
Stefan
--=20
Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5375D2AF-C886-4DB0-A331-39363562D2B4>