From owner-freebsd-embedded@FreeBSD.ORG Tue Dec 13 10:40:02 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 314E51065689; Tue, 13 Dec 2011 10:40:02 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id CB7768FC22; Tue, 13 Dec 2011 10:40:01 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 9682B57AAA; Tue, 13 Dec 2011 11:40:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Tue, 13 Dec 2011 11:40:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5375D2AF-C886-4DB0-A331-39363562D2B4@lassitu.de> 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> <6387ABA5-AC55-49DD-9058-E45CC0A3E0A0@lassitu.de> <74E4AF57-3D22-415E-B913-176753B09B16@lassitu.de> <710E2C7A-E9AC-4103-8C61-0EDC4A3AF9DE@lassitu.de> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) Cc: freebsd-embedded@freebsd.org Subject: Re: TL-WR1043: switch X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 10:40:02 -0000 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 Fon +49 151 14070811