2) Call your mdio bus initialization function from your USB probe
function.
If I have multiple devices, should I wind up having a separate MDIO
bus
for each? If so, this would make sense for handling the registration.
My theory is one bus per master (mostly). As I understand it, each
of your ethernet devices has one PHY, and one means of accessing that
PHY. So each of those are separate busses. My guess is that all of
them have the same PHY address. So this would be required in order
to route the reads and writes through the correct register set.
3) The loop that searches for all the PHYs only registers devices
when it finds them. If there is no device found, the entry at that
address will be left blank. It would be fairly simple to, ah a later
time, call get_phy_device() for that address, and then insert it into
the mdio bus structure at the appropriate address, and register it.
At that time, it would bind to any available drivers. I'd hope this
would be a last resort, since it's fairly ugly, and if it's a common
solution, then the PHY Layer's mdio bus code probably needs to be
rewritten.
This part goes back to what I mentioned a week or so ago. My device
seems to have an ugly habit of returning the last value read if there
isn't a 'new' value. On one of my devices, the PHY is at address 16.
So 0-15 return somewhat random values and 17-31 return the PHYAD2 that
was read from address 16. If there is some way to add a mask for
potential PHY addressess or something, that might provide a decent
workaround instead of having 32 PHY addresses, only one of which is
actually valid.
I've been thinking about this, and unless this is a common problem,
the fix should be implemented within the bus driver, itself. When
the bus comes up, it needs to know that transactions with addresses
other than 16 are invalid, and then return 0xffff for all reads from,
and ignore all writes to those addresses.
Then, when the mdio code scans your bus, it will only find one valid
PHY, and allocate only one PHY device.
I think the best practice is for you to call your bus's init function
from your probe code, assuming there is a one-to-one relationship
between ethernet controllers and mdio busses in your device. If you
might have the same driver operate a USB device with multiple
ethernet controllers on it, and only one PHY bus, shared by all of
them, then this system wouldn't work without some messing around to
make sure that it only got called once per bus.
Andy
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
