Date: Sun, 8 May 2011 15:52:29 +0200 From: Damjan Marion <damjan.marion@gmail.com> To: Marius Strobl <marius@alchemy.franken.de> Cc: freebsd-hackers@freebsd.org Subject: Re: Embedded switch instead of stadard PHY Message-ID: <E75586A5-ADD9-462A-A86D-73C112C24F02@gmail.com> In-Reply-To: <20110508131643.GA23650@alchemy.franken.de> References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> <20110508131643.GA23650@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 8, 2011, at 3:16 PM, Marius Strobl wrote: > On Sat, May 07, 2011 at 07:22:23PM +0200, Damjan Marion wrote: >>=20 >> Hi, >>=20 >>=20 >> 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: >>=20 >> mge0: <Marvell Gigabit Ethernet controller> mem 0xf1072000-0xf1073fff = irq 18,19,20,21,22 on simplebus0 >> miibus0: <MII bus> on mge0 >> e1000phy0: <Marvell 88E1000 Gigabit PHY> PHY 12 on miibus0 >> e1000phy0: id1=3D0x0141, id2=3D0x0c00=20 >> e1000phy1: <Marvell 88E1000 Gigabit PHY> PHY 13 on miibus0 >> e1000phy1: id1=3D0x0141, id2=3D0x0c00=20 >> e1000phy2: <Marvell 88E1000 Gigabit PHY> PHY 14 on miibus0 >> e1000phy2: id1=3D0x0141, id2=3D0x0c00=20 >> e1000phy3: <Marvell 88E1000 Gigabit PHY> PHY 15 on miibus0 >> e1000phy3: id1=3D0x0141, id2=3D0x0c00=20 >> ukphy0: <Generic IEEE 802.3u media interface> PHY 20 on miibus0 >> ukphy0: =20 >> ukphy1: <Generic IEEE 802.3u media interface> PHY 21 on miibus0 >> ukphy1: =20 >> ukphy2: <Generic IEEE 802.3u media interface> PHY 22 on miibus0 >> ukphy2: =20 >> ukphy3: <Generic IEEE 802.3u media interface> PHY 23 on miibus0 >>=20 >> if_mge MAC is connected to port 3 of E6131 and port 3 acts in = reverse-GMII mode to simulate PHY side. >>=20 >> 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). >=20 > 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=20= is that either i can attach to PHY12-15 which is reporting wrong ID2=20 belonging to different PHY driver or to attach on PHY20-23 where ID1 and = ID2=20 registers doesn't exist, but luckily some values are at that address and=20= they are recognized as unknown PHY. In both cases it sounds like a workaround more than a proper solution, = so=20 I was wondering if there is some better way to detect PHY, not only by=20= ID1 and ID2 values. In case of this device there is another register = which=20 contains product identifier, and that is what linux driver probes. >=20 >>=20 >> 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. >=20 > 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. >=20 > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E75586A5-ADD9-462A-A86D-73C112C24F02>