[U-Boot] [RFC] CONFIG_RESET_PHY_R feature is broken

[U-Boot] [RFC] CONFIG_RESET_PHY_R feature is broken

[Ilya Yanok]

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.

[U-Boot] [RFC] CONFIG_RESET_PHY_R feature is broken

[Albert ARIBAUD]

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,
-- 
Albert.

[U-Boot] [RFC] CONFIG_RESET_PHY_R feature is broken

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Men will always be men -- no matter where they are.
	-- Harry Mudd, "Mudd's Women", stardate 1329.8

[U-Boot] [RFC] CONFIG_RESET_PHY_R feature is broken

[Ilya Yanok]

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!

[U-Boot] [RFC] CONFIG_RESET_PHY_R feature is broken

[Albert ARIBAUD]

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,
-- 
Albert.