Embedded switch instead of stadard PHY

[Warner Losh]

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 
> 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.

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.  

> 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.

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.
>> 
>> 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.

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