All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH] sh_eth: ensure pm_runtime cannot suspend the device during init
Date: Tue, 18 Mar 2014 20:45:09 +0000	[thread overview]
Message-ID: <2957787.oOtLstBUZL@avalon> (raw)
In-Reply-To: <1394823605-31883-1-git-send-email-ben.dooks@codethink.co.uk>

Hi Ben and Sergei,

On Wednesday 19 March 2014 00:17:43 Sergei Shtylyov wrote:
> On 03/17/2014 05:01 PM, Ben Dooks wrote:
> >>>>> I have yet to ascertain how this ends up happening with device probe,
> >>>>> it seems to be very dependant on the code.
> >>>> 
> >>>> Adding a WARN() in cpg_mstp_clock_endisable():
> [...]
> 
> >>> this explains it, the call to stats causes a get_sync/put_sync which
> >>> puts the device into a state where it /could/ be suspended and thus
> >>> does get suspended in this case from the pm code.
> >>> 
> >>> I'm not /sure/ why the pm_runtime code is not protecting against
> >>> running this when a device probe is in progress, but it seems the
> >>> best thing is to ensure that we always do a get/put sync in the
> >>> driver to ensure we have a reference during probe.
> >> 
> >> Wouldn't it be better to register the MDIO bus before registering the
> >> network device ? It looks like the current order is prone to race
> >> conditions.
> >
> > Not sure, requires input?
> 
> People say that the driver should be ready to receive the ndo_open() method
> call even before register_netdev() returns. I have prepared the patch to
> probe MDIO before calling register_netdev() now, need to sanity test it.

Thank you.

> >> Another potential issue, does the network layer guarantee that the device
> >> will always be opened by an .ndo_open() call before performing any MDIO
> >> operation ? sh_mmd_ctrl, sh_set_mdio and sh_get_mdio access sh-eth
> >> registers, could we be missing runtime PM calls in those call paths ?
> > 
> > I'm not sure if there is any guarantee, I don't think the PHY driver
> > does any sort of open on probe. I do have a patch to ensure that the
> > MDIO operations are wrapped with pm_runtime_{get,put}_sync() calls as
> > the probe of the PHY often fails without it.
> 
> Respin this patch please (addressing my comments), so that DaveM could take
> it.

Before wrapping MDIO operations in runtime PM calls, could we check whether 
that's really needed ? Moving PHY registration before network device 
registration will fix PHY probe problems, we might not need any other change.

-- 
Regards,

Laurent Pinchart


  parent reply	other threads:[~2014-03-18 20:45 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-14 19:00 [PATCH] sh_eth: ensure pm_runtime cannot suspend the device during init Ben Dooks
2014-03-14 19:01 ` Ben Dooks
2014-03-14 19:06 ` Sergei Shtylyov
2014-03-14 19:19 ` Ben Dooks
2014-03-14 21:13 ` Sergei Shtylyov
2014-03-15 11:19 ` Laurent Pinchart
2014-03-17  9:22 ` Geert Uytterhoeven
2014-03-17  9:41 ` Ben Dooks
2014-03-17 11:20 ` Ben Dooks
2014-03-17 11:35 ` Laurent Pinchart
2014-03-17 11:37 ` Ben Dooks
2014-03-17 11:37   ` Ben Dooks
2014-03-17 13:01   ` Sergei Shtylyov
2014-03-17 13:01     ` Sergei Shtylyov
2014-03-17 13:07     ` Ben Dooks
2014-03-17 20:23   ` Laurent Pinchart
2014-03-17 20:23     ` Laurent Pinchart
2014-03-17 21:30     ` Sergei Shtylyov
2014-03-17 22:30       ` Sergei Shtylyov
2014-03-17 21:34       ` Laurent Pinchart
2014-03-17 21:34         ` Laurent Pinchart
2014-03-17 22:09         ` Sergei Shtylyov
2014-03-17 23:09           ` Sergei Shtylyov
2014-03-17 11:40 ` Ben Dooks
2014-03-17 11:53 ` Laurent Pinchart
2014-03-17 12:56 ` Ben Dooks
2014-03-17 13:27 ` Laurent Pinchart
2014-03-17 13:36 ` Ben Dooks
2014-03-17 13:38 ` Geert Uytterhoeven
2014-03-17 13:41 ` Laurent Pinchart
2014-03-17 13:43 ` Geert Uytterhoeven
2014-03-17 13:44 ` Ben Dooks
2014-03-17 13:54 ` Laurent Pinchart
2014-03-17 14:01 ` Ben Dooks
2014-03-17 14:02 ` Geert Uytterhoeven
2014-03-17 14:15 ` Sergei Shtylyov
2014-03-18 20:17 ` Sergei Shtylyov
2014-03-18 20:45 ` Laurent Pinchart [this message]
2014-03-18 21:48 ` Sergei Shtylyov
2014-03-19  8:19 ` Ben Dooks
2014-03-19 10:17 ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2957787.oOtLstBUZL@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=linux-sh@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.