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,