[U-Boot] Handling different ethernhet phys on the same system.

[Ben Warren]

Hi Vadim,

vb wrote:
> Hello Ben,
>
> I am trying to port u-boot on a system which deploys two different
> types of ethernet PHYs, and don't see a good way of doing it with the
> current sw structure.
>
> There are concurrent implementations for supporting different PHYs,
> and it looks like quite often bringing in a new etherent controller
> brings in a duplicate PHY driver code. OTOH it is always presumed that
> the same kind of phy is used on all ports.
>
> I want to modify this scheme, but I don't want to go too far on a
> tangent, as we here plan to integrate our changes back into the master
> repository one of those days.
>
> Here is what I suggest doing:
>
> we introduce a concept of 'phy bus' - an MDIO bus for instance, and
> 'phy interface' which is the phy driver.
>
> For illustration purpose, the phy bus could look like this:
> struct phy_bus {
>     int (*write)(u8 addr, u16 reg, u16 value);
>     int (*read)(u8 addr, u16 reg, u16 *value);
> }
>
> and the driver would provide methods like
>
> struct phy_driver {
>    int (*reset)(struct phy_bus*, u8 addr))
>    int (*init)(struct phy_bus*, u8 addr)
> ...
> }
>
> the set of methods could be fine tuned at any time obviously, the
> important thing is that each method would receive the pointer to the
> phy bus to be used to communicate with the device.
>
> Then, in the ethernet device structure we would add two pointers: to
> the bus serving the port and to the driver serving the port.
>
> This would allow any new ethernet controller provide its own mdio bus
> implementation and then use existing phy driver the same way any other
> controller uses it. This would also allow to attach different phy
> devices to different ethernet ports. And of course the multiple PHY
> implementations won't be needed anymore, just one instance will serve
> any ethernet device.
>
> What do you think?
>
> TIA,
> Vadim
>   
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.

Good conversation - let's keep it going.  It would be great if you could 
work on this.

regards,
Ben