[U-Boot] Handling different ethernhet phys on the same system.
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
On Thu, Sep 25, 2008 at 11:09 PM, Ben Warren biggerbadderben@gmail.com wrote:
Wolfgang Denk wrote:
Dear Ben,
I just ran over this piece of code in NetLoop() [see "net/net.c"]:
286 int 287 NetLoop(proto_t protocol) 288 { ... 322 eth_halt(); 323 #ifdef CONFIG_NET_MULTI 324 eth_set_current(); 325 #endif 326 if (eth_init(bd) < 0) { 327 eth_halt(); 328 return(-1); 329 }
Am I reading this correctly that we eth_halt() and eth_init() the network interface for each and every call to NetLoop?
Yes, it looks that way. Ripe for gutting.
This looks terribly inefficient to me - is there any rationale behind this?
Probably, but it escapes me. It most certainly predates my involvement in this project.
Also, the eth_set_current() checking should IMHO be done just once, before we start a network transfer, or when we actually switch interfaces, but not for each and every call to NetLoop() ?
Maybe, but eth_set_current() is pretty lightweight. NetLoop is only called when we start a network transfer, so this doesn't seem too egregious. It could definitely stand to be refactored.
Best regards,
Wolfgang Denk
regards, Ben _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[cc] On Fri, Sep 26, 2008 at 8:42 AM, Anton Vorontsov avorontsov@ru.mvista.com wrote:
On Fri, Sep 26, 2008 at 08:36:28AM -0700, vb wrote: [...]
What do you think?
Something like linux/drivers/net/phy/? Sounds great, but somebody need to port it. ;-)
Yes, this is a popular scheme, I don't claim to be its inventor. :-) Obviously Linux model is not applicable as is, but the idea is very similar, you are right,
cheers, /vb
-- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2
On Fri, Sep 26, 2008 at 08:52:33AM -0700, vb wrote:
[cc] On Fri, Sep 26, 2008 at 8:42 AM, Anton Vorontsov avorontsov@ru.mvista.com wrote:
On Fri, Sep 26, 2008 at 08:36:28AM -0700, vb wrote: [...]
What do you think?
Something like linux/drivers/net/phy/? Sounds great, but somebody need to port it. ;-)
Yes, this is a popular scheme, I don't claim to be its inventor. :-) Obviously Linux model is not applicable as is, but the idea is very similar, you are right,
Well, what I'm trying to say, is that it would be great to have a model that is close to the Linux' one, as close as possible. Think of code sharing, and future code integration...
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
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
participants (3)
-
Anton Vorontsov -
Ben Warren -
vb