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>