On Thu, 2005-08-25 at 15:51 -0500, Andy Fleming wrote: > On Aug 25, 2005, at 15:04, David Hollis wrote: > > > > > > Question for you, I'm trying to setup my mdio_bus driver and I don't > > know how I can get it registered at the appropriate time. I can't > > read > > the PHY IDs until after I've diddled some bits on the device which > > happens in my USB probe function. If I register the mdio_bus on > > module > > load, the loop that tries to read the valid PHYs is not going to work. > > Do you think it might be possible to have an alternate > > mdio_bus_register() that doesn't try to detect the phys that are > > present? Maybe there would be either a function I could call later to > > do the auto-detect or to manually add a phy address to the bus? > > > This is definitely one of the more difficult issues of MDIO bus > initialization, since they tend to be so closely coupled with the > ethernet controller. Some possible recommendations: > > 1) Twiddle those bits in the mdio bus initialization function. This > makes sense if those bits can be considered a logical part of the > mdio bus. >
The bit-twiddling is more setting up the device itself for proper communication. Really isn't MDIO specific unfortunately. > 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. > 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. > 4) Call mdio_bus_register at some other time, perhaps from your USB > probe code. This solution breaks abstraction layers, though perhaps > more preferable than #3, since it's much simpler. > Since the MDIO bus is a 'sub-component' of the USB device itself, it does seem to make sense to have it here. In this case, would I need to register the mdio_bus driver itself in my USB probe, or just handle the mdio_register at that point? > 5) write your own version of mdio_bus_register that is specific to > your driver, and make sure it does everything mdio_bus_register does > already, plus whatever else you need done. I hope this isn't > necessary, since it's a lot like #3, in that it means that the > current mdio bus code probably needs serious work. > I'm hoping to avoid this, though being able to avoid the auto-PHY detection unless I can figure a better workaround for my not-so-smart device. One option might be to pull out the specific address check/add portion into it's own function, and have a flag to mdio_register to enable/disable auto-detect and be able to call the specific address check function later. In the case of my device, I am able to make a call to find out what PHY address is used. -- David Hollis <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
