On Fri, Sep 26, 2008 at 10:03 AM, Ben Warren biggerbadderben@gmail.com wrote:
This is a topic that has been brought up many times before. I actually started porting the Linux PHY stuff, but quickly realized that my limited CPU cycles would be better spent cleaning up the overall Ethernet driver architecture, with the PHY stuff to come later.
I like your ideas. In addition to the inflexibility that you've mentioned, there's a lot of code duplication (see, for example the number of PHYs that are listed in the TSEC driver). One of the things that's difficult to balance, and I don't know too many other peoples opinions, is how much board C code is acceptable, versus how much information should be specified by CONFIG_x definitions. If everybody suddenly has to define an elaborate array of structs in board code rather than a few CONFIGs, usability goes down. I don't really care, since IMHO you should know what you're doing when you port a bootloader, but maybe others feel differently.
Another thing to keep in mind is that we don't need to strongly bind a PHY type to an interface, really just a bus/ address (assuming we're using MDIO), since the devices are mostly probe-able.
Ben, great to hear that we think the same :-)
You are right that the PHYs can be probed, so there is no need to attach any particular driver ahead of time, the only thing required from the developer would the MDIO address defined in CONFIG_PHYSx_ADDR as it is already done today.
Also, we can provide a 'catch all' driver relying on the standard PHY register definition to fall back to if probing finds a PHY for which a driver is not available.
Good conversation - let's keep it going. It would be great if you could work on this.
Absolutely, I'll look into implementing something along these lines, it is interesting to see what others think,
cheers, Vadim
regards, Ben