Date: Tue, 10 May 2011 11:01:49 -0600 From: Warner Losh <imp@bsdimp.com> To: Damjan Marion <damjan.marion@gmail.com> Cc: freebsd-hackers@freebsd.org, Marius Strobl <marius@alchemy.franken.de> Subject: Re: Embedded switch instead of stadard PHY Message-ID: <9B3FEB02-B71C-412B-BB7E-31A236021CDD@bsdimp.com> In-Reply-To: <E75586A5-ADD9-462A-A86D-73C112C24F02@gmail.com> References: <34CF3ED0-52BC-4D0E-922A-FE26F624E77F@gmail.com> <20110508131643.GA23650@alchemy.franken.de> <E75586A5-ADD9-462A-A86D-73C112C24F02@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 8, 2011, at 7:52 AM, 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: > 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. There's supposed to be 'wiring' information for the switches/PHYs in the = DTS. Maybe you can key off that to determine which ones to attach to. =20= > 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. Usually detection by ID1/ID2 is the better way. However, some devices, = like this switch, respond on multiply PHY addresses (sometimes bogusly, = sometimes not). >>> 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. >=20 > Agree, I will try to code something and then I will ask wider audience = to comment on. That would be cool. Most switches are on the PHY bus, so you can program their registers. = Many are on the PHY bus multiple times. Once for the real(ish) PHY they = provide and once for the switch registers they expose (for some, "twice" = means up to 4 times). Some are just nuts. It would be nice if there was a way for a device's MII routine to = control enumeration of the PHY bus. This would allow us to convert the = rlswitch device in the tree to one of these. That way, it could = 'filter' out the PHYs addresses that are intended to be like traditional = PHYs from the addresses that are intended to be used for switch = management. We likely should also have a switch interface that one can tweak via = ifconfig. I'd like that to be an explicit goal of this work, even if = others do it. However, that's a big ticket item. I kinda like the 'let us put a few = of these in the tree with kludges then refactor' model, but worry we end = up without the refactoring... Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9B3FEB02-B71C-412B-BB7E-31A236021CDD>