Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1601512

Re: [RFC PATCH] net: phy: Don't miss phy_suspend() on PHY_HALTED for PHYs with interrupts

Show all headers | View raw

On Wed, Mar 15, 2017 at 05:00:08PM +0200, 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 <rogerq@ti.com>
> > 
> > Hi Roger
> > 
> > This seems sensible. It mirrors what phy_start() does.
> > 
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> 
> 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?

Humm, good question.

My _guess_ would be, calling it with sync=True could
deadlock. sync=False is probably safe. But lets see what Florian says.

> 
> > 
> > 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().

Humm, that might get us into a tight loop.

phy_start_aneg() kicks the phy driver to start autoneg and sets
phydev->state = PHY_AN.

phy_trigger_machine() triggers the state machine immediately. 

In state PHY_AN, we check if aneg is done. If not, it sets needs_aneg
= true. At the end of the state machine, this then calls
phy_start_aneg(), and it all starts again.

We are missing the 1s delay we have with polling. So for
phy_start_aneg(), we might need a phy_delayed_trigger_machine(), which
waits a second before doing anything?

      Andrew

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH] net: phy: Don't miss phy_suspend() on PHY_HALTED for PHYs with interrupts Roger Quadros <rogerq@ti.com> - 2017-03-15 15:00 +0100
  Re: [RFC PATCH] net: phy: Don't miss phy_suspend() on PHY_HALTED for  PHYs with interrupts Andrew Lunn <andrew@lunn.ch> - 2017-03-15 15:20 +0100
    Re: [RFC PATCH] net: phy: Don't miss phy_suspend() on PHY_HALTED for  PHYs with interrupts Roger Quadros <rogerq@ti.com> - 2017-03-15 16:10 +0100
      Re: [RFC PATCH] net: phy: Don't miss phy_suspend() on PHY_HALTED for  PHYs with interrupts Andrew Lunn <andrew@lunn.ch> - 2017-03-15 17:00 +0100
        Re: [RFC PATCH] net: phy: Don't miss phy_suspend() on PHY_HALTED for  PHYs with interrupts Roger Quadros <rogerq@ti.com> - 2017-03-16 11:30 +0100
          Re: [RFC PATCH] net: phy: Don't miss phy_suspend() on PHY_HALTED for  PHYs with interrupts Florian Fainelli <f.fainelli@gmail.com> - 2017-03-20 17:50 +0100
            Re: [RFC PATCH] net: phy: Don't miss phy_suspend() on PHY_HALTED for  PHYs with interrupts Roger Quadros <rogerq@ti.com> - 2017-03-21 11:20 +0100
              Re: [RFC PATCH] net: phy: Don't miss phy_suspend() on PHY_HALTED for  PHYs with interrupts Florian Fainelli <f.fainelli@gmail.com> - 2017-03-21 17:20 +0100
      Re: [RFC PATCH] net: phy: Don't miss phy_suspend() on PHY_HALTED for  PHYs with interrupts Florian Fainelli <f.fainelli@gmail.com> - 2017-03-20 17:50 +0100

csiph-web