[lkml]   [2017]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH] net: phy: Don't miss phy_suspend() on PHY_HALTED for PHYs with interrupts
On 03/15/2017 08:00 AM, Roger Quadros wrote:
> Andrew,
> On 15/03/17 16:08, Andrew Lunn wrote:
>> On Wed, Mar 15, 2017 at 03:51:27PM +0200, Roger Quadros wrote:
>>> Since commit 3c293f4e08b5 ("net: phy: Trigger state machine on state change and not polling.")
>>> phy_suspend() doesn't get called as part of phy_stop() for PHYs using
>>> interrupts because the phy state machine is never triggered after a phy_stop().
>>> Explicitly trigger the PHY state machine so that it can
>>> see the new PHY state (HALTED) and suspend the PHY.
>>> Signed-off-by: Roger Quadros <>
>> Hi Roger
>> This seems sensible. It mirrors what phy_start() does.
>> Reviewed-by: Andrew Lunn <>
> The reason for this being an RFC was the following comment just before
> where I add the phy_trigger_machine()
> /* Cannot call flush_scheduled_work() here as desired because
> * of rtnl_lock(), but PHY_HALTED shall guarantee phy_change()
> * will not reenable interrupts.
> */
> Is this comment still applicable? If yes, is it OK to call
> phy_trigger_machine() there?

I think the comment is still applicable, most PHYLIB consumers will call
this with rtnl_lock() held from ndo_close() for instance.

>> It does however lead to a follow up question. Are there other places
>> phydev->state is changed and it is missing a phy_trigger_machine()?
> One other place I think we should add phy_trigger_machine() is phy_start_aneg().
> Since commit 3c293f4e08b5 I was not getting my ethernet link to come up if
> ethernet cable was plugged before the ethernet interface was brought up.
> The PHY seems to be stuck from RUNNING to AN state with no new interrupts from the
> PHY.
> I could workaround it on my board by doing either of the following:
> 1) explicitly halt the PHY at ethernet driver probe time. Then when
> network interface is brought up it resumes the PHY and we see the
> Link/ANEG done interrupt.
> 2) force BMCR_ANRESTART every time from .config_aneg in the PHY driver.
> I will still keep approach 1 as it is desirable to put the PHY in low power mode
> for us but I need a second opinion if we should call phy_trigger_machine()
> from phy_start_aneg() or not.


 \ /
  Last update: 2017-03-20 17:49    [W:0.064 / U:2.728 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site