From owner-freebsd-hackers@FreeBSD.ORG Sun May 8 14:14:58 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CC831065673 for ; Sun, 8 May 2011 14:14:58 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8EF8FC08 for ; Sun, 8 May 2011 14:14:57 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p48EEult023922; Sun, 8 May 2011 16:14:56 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p48EEur3023921; Sun, 8 May 2011 16:14:56 +0200 (CEST) (envelope-from marius) Date: Sun, 8 May 2011 16:14:56 +0200 From: Marius Strobl To: Damjan Marion Message-ID: <20110508141456.GD92688@alchemy.franken.de> References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> <20110508131643.GA23650@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: Embedded switch instead of stadard PHY X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 14:14:58 -0000 On Sun, May 08, 2011 at 03:52:29PM +0200, Damjan Marion wrote: > > On May 8, 2011, at 3:16 PM, Marius Strobl wrote: > > > On Sat, May 07, 2011 at 07:22:23PM +0200, Damjan Marion wrote: > >> > >> Hi, > >> > >> > >> I would like to implement support for embedded switch on WRT350Nv2 router which is based on 88F5181L SoC (ARM). FreeBSD already have support for embedded gigabit card (if_mge) but in case if this router MAC is connected directly to 8-port ethernet chip (88E6131). If I use MII_PHY_ANY scan founds following PHYs on miibus: > >> > >> mge0: mem 0xf1072000-0xf1073fff irq 18,19,20,21,22 on simplebus0 > >> miibus0: on mge0 > >> e1000phy0: PHY 12 on miibus0 > >> e1000phy0: id1=0x0141, id2=0x0c00 > >> e1000phy1: PHY 13 on miibus0 > >> e1000phy1: id1=0x0141, id2=0x0c00 > >> e1000phy2: PHY 14 on miibus0 > >> e1000phy2: id1=0x0141, id2=0x0c00 > >> e1000phy3: PHY 15 on miibus0 > >> e1000phy3: id1=0x0141, id2=0x0c00 > >> ukphy0: PHY 20 on miibus0 > >> ukphy0: > >> ukphy1: PHY 21 on miibus0 > >> ukphy1: > >> ukphy2: PHY 22 on miibus0 > >> ukphy2: > >> ukphy3: PHY 23 on miibus0 > >> > >> if_mge MAC is connected to port 3 of E6131 and port 3 acts in reverse-GMII mode to simulate PHY side. > >> > >> Reason for output above is that E6131 uses non-standard registers on multiple device addresses and on some of them mii_attach fails, and on another it false detects PHY (20-23 above). > > > > Well, if the switch responds on these addresses then from a MII point > > of view there's nothing wrong about this when using MII_PHY_ANY. If > > you want only one of these to attach than use that address instead of > > MII_PHY_ANY. By calling mii_attach() multiple times with different > > addresses you can also attach a subset. > > Yes, my initial idea is to attach manually only to one PHY, but problem > is that either i can attach to PHY12-15 which is reporting wrong ID2 > belonging to different PHY driver or to attach on PHY20-23 where ID1 and ID2 > registers doesn't exist, but luckily some values are at that address and > they are recognized as unknown PHY. > > In both cases it sounds like a workaround more than a proper solution, so > I was wondering if there is some better way to detect PHY, not only by > ID1 and ID2 values. In case of this device there is another register which > contains product identifier, and that is what linux driver probes. Well, if ID1 and ID2 don't exist it's not 802.3 compliant, in which case I'd think it shouldn't be handled by mii(4) but some other layer in the first place :) That that said methods used to deal with broken PHYs reporting invalid values for ID{1,2} is to either additionally take the parent driver into consideration (see f.e. rlphy(4) or to fake these registers in the MAC driver (see f.e. dc(4), which actually fakes a whole MII bus in !DC_PMODE_MII mode). > > > > > >> > >> I would like to hear form more experienced people how to implement this properly, as it is obvious that it cannot be addressed with existing routines. > > > > Depends on what you understand by properly. One idea I particularly > > like is to handle switch ports as pseudo-interfaces hanging off of the > > the MAC driver parent roughly similar to vlan(4). That way you'd have > > per port link status and could configure the media. > > > > What you can do now without changing mii(4) is to just attach the > > the PHY side, i.e. port 3, and configure/handle the ports in a > > special PHY driver, either by hardcoding their configuration like > > rlswitch(4) does or by providing SYSCTLs as Adrian already said. > > If we had a way to access the PHY registers from userland similar > > to what pci(4)/pciconf(8) allows, which is another thing I'd like > > to see in order to provide miitool-like functionality, one could > > also easily handle the port configuration from userland instead > > of putting everything into the kernel. That probably also would > > have its merits as in reality there are probably a lot of quirks > > like unconnected ports etc. > > Agree, I will try to code something and then I will ask wider audience to comment on. > > Marius