[U-Boot] [RFC] CONFIG_RESET_PHY_R feature is broken
Hello Ben, Everybody,
some boards used to have their PHY quirks in board-specific reset_phy() function. This used to work because of reset_phy() being called later than Ethernet drivers initialization during startup. But nowadays some drivers (in particular I faced this problem using mpc5xxx_fec driver) use 'on demand' PHY initialization, and board-specific quirks don't have effect any more... Actually, CONFIG_RESET_PHY_R is broken even without 'on demand' PHY initialization: at least mpc5xxx_fec driver can decide to reinit PHY during normal operation and board-specific reset_phy() function won't be called in this case too... Another design flaw of the CONFIG_RESET_PHY_R feature is that boards with more than one Ethernet controller are pretty common today and usually we want to initialize only the PHY connected to the controller we are trying to use at the moment and there is no way to tell the reset_phy() function which PHY we want to reset...
Ben, do you have any ideas how we could fix this?
I believe on of possible solutions here would be to introduce generic PHY layer in U-Boot but unfortunately this would be too much efforts for us in this project... Maybe somebody is aware of such work being done so we can join?
Regards, Ilya.
Le 18/08/2010 01:16, Ilya Yanok a écrit :
Hello Ben, Everybody,
some boards used to have their PHY quirks in board-specific reset_phy() function. This used to work because of reset_phy() being called later than Ethernet drivers initialization during startup. But nowadays some drivers (in particular I faced this problem using mpc5xxx_fec driver) use 'on demand' PHY initialization, and board-specific quirks don't have effect any more... Actually, CONFIG_RESET_PHY_R is broken even without 'on demand' PHY initialization: at least mpc5xxx_fec driver can decide to reinit PHY during normal operation and board-specific reset_phy() function won't be called in this case too... Another design flaw of the CONFIG_RESET_PHY_R feature is that boards with more than one Ethernet controller are pretty common today and usually we want to initialize only the PHY connected to the controller we are trying to use at the moment and there is no way to tell the reset_phy() function which PHY we want to reset...
Ben, do you have any ideas how we could fix this?
I believe on of possible solutions here would be to introduce generic PHY layer in U-Boot but unfortunately this would be too much efforts for us in this project... Maybe somebody is aware of such work being done so we can join?
Regards, Ilya.
Hi Ilya,
At the moment your problem is not being able to reset the PHY at times other than boot, i.e. the 'PHY API' would be limited to reset_phy() which is pretty much board-specific anyway. What prevents simply adding calls to reset_phy() to the driver? It needs them anyway, so it will never be compiled without a reset_phy() to call, right?
Amicalement,
Dear Albert ARIBAUD,
In message 4C6B858F.9060201@free.fr you wrote:
At the moment your problem is not being able to reset the PHY at times other than boot, i.e. the 'PHY API' would be limited to reset_phy() which is pretty much board-specific anyway. What prevents simply adding calls to reset_phy() to the driver? It needs them anyway, so it will never be compiled without a reset_phy() to call, right?
It may be desirable (at least as an option) to always perform the PHY reset (just the reset, i. e. the hardware initialization) without waiting for a link to come up. Link negotiation could then happen "in background", while other parts of U-Boot initialization are running. When U-Boot actually performs a network command, it ill not have to wait as long as in the case when we start resetting the PHY here.
I am well aware that this is not in line with the principle of initializing the hardware only if needed, but short boot times are a common requirement, so one might consider such an option. [I would not recommend (or accept) this as the default case.]
Best regards,
Wolfgang Denk
Hello Albert,
Albert ARIBAUD <albert.aribaud <at> free.fr> writes:
At the moment your problem is not being able to reset the PHY at times other than boot, i.e. the 'PHY API' would be limited to reset_phy() which is pretty much board-specific anyway.
The problem is the PHY being reseted by the driver and going to unworking state. We need the board-specific quirk to bring PHY back to life and driver knows nothing about this quirk.
What prevents simply adding calls to reset_phy() to the driver?
Yes, we can just add calls to reset_phy() to the driver and we actually have this solution as a simplest one in our options list. But this solution seems to be imperfect: there are more drivers using 'on demand' PHY init, we need to add calls to reset_phy() to each of them. Furthermore, if somebody will want to switch some driver from early PHY initialization to on demand intialization he will have to remember about adding reset_phy() call. So it is error prone.
So we'd like to discuss if there are cleaner solutions.
Regards, Ilya.
PS could use please reply not only to the ML but to me also? Thanks!
Le 18/08/2010 10:47, Ilya Yanok a écrit :
Hello Albert,
Albert ARIBAUD<albert.aribaud<at> free.fr> writes:
At the moment your problem is not being able to reset the PHY at times other than boot, i.e. the 'PHY API' would be limited to reset_phy() which is pretty much board-specific anyway.
The problem is the PHY being reseted by the driver and going to unworking state. We need the board-specific quirk to bring PHY back to life and driver knows nothing about this quirk.
What prevents simply adding calls to reset_phy() to the driver?
Yes, we can just add calls to reset_phy() to the driver and we actually have this solution as a simplest one in our options list. But this solution seems to be imperfect: there are more drivers using 'on demand' PHY init, we need to add calls to reset_phy() to each of them. Furthermore, if somebody will want to switch some driver from early PHY initialization to on demand intialization he will have to remember about adding reset_phy() call. So it is error prone.
So we'd like to discuss if there are cleaner solutions.
Seems to me the user may want to choose at compile time, not boot time -- through a configuration option like CONFIG_NET_ONDEMAND_PHY_INIT; then drivers can conditionally compile code for support of on-demand or early init (or both; I'm not sure why on-demand phy int would prohibit doing an early init the first time and as wolfgang points out, early init makes sense for background link negociation while u-boot starts).
Regards, Ilya.
PS could use please reply not only to the ML but to me also? Thanks!
Done this time. However I suggest you keep an eye on the list for all messages, at least all subjects, just to see if something of interest to you is happening that you would not know of otherwise.
Amicalement,
participants (3)
-
Albert ARIBAUD -
Ilya Yanok -
Wolfgang Denk