| Message ID | 1395056275-5005-1-git-send-email-ben.dooks@codethink.co.uk (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Headers | show |
Hello. On 17-03-2014 15:37, Ben Dooks wrote: > The pm_rumtime work queue is causing the device to be suspended during > initialisation, thus the initialisation may not be able to access registers > properly. As the code is called from a work queue, it is possible that this > is not seen from certain configurations/builds due to the asynchronos > nature of the code. > Use pm_runtime_get_sync() and pm_runtime_put_sync() to ensure that the > pm system does not suspend it during the probe() call and remove the > now unnecessary pm_runtime_resume() call. > This fixes the external abort that can cause /sbin/init or other such > init processed to die. > Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> > Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> > --- > drivers/net/ethernet/renesas/sh_eth.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c > index 4f76b5e..f1cfd64 100644 > --- a/drivers/net/ethernet/renesas/sh_eth.c > +++ b/drivers/net/ethernet/renesas/sh_eth.c [...] > @@ -2961,6 +2961,7 @@ static int sh_eth_drv_probe(struct platform_device *pdev) > pr_info("Base address at 0x%x, %pM, IRQ %d.\n", > (u32)ndev->base_addr, ndev->dev_addr, ndev->irq); > > + pm_runtime_put_sync(&pdev->dev); I think you forgot to also do that on error cleanup path. > platform_set_drvdata(pdev, ndev); > > return ret; WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 17/03/14 13:01, Sergei Shtylyov wrote: > Hello. > > On 17-03-2014 15:37, Ben Dooks wrote: > >> The pm_rumtime work queue is causing the device to be suspended during >> initialisation, thus the initialisation may not be able to access >> registers >> properly. As the code is called from a work queue, it is possible that >> this >> is not seen from certain configurations/builds due to the asynchronos >> nature of the code. > >> Use pm_runtime_get_sync() and pm_runtime_put_sync() to ensure that the >> pm system does not suspend it during the probe() call and remove the >> now unnecessary pm_runtime_resume() call. > >> This fixes the external abort that can cause /sbin/init or other such >> init processed to die. > >> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> >> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> >> --- >> drivers/net/ethernet/renesas/sh_eth.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> diff --git a/drivers/net/ethernet/renesas/sh_eth.c >> b/drivers/net/ethernet/renesas/sh_eth.c >> index 4f76b5e..f1cfd64 100644 >> --- a/drivers/net/ethernet/renesas/sh_eth.c >> +++ b/drivers/net/ethernet/renesas/sh_eth.c > [...] >> @@ -2961,6 +2961,7 @@ static int sh_eth_drv_probe(struct >> platform_device *pdev) >> pr_info("Base address at 0x%x, %pM, IRQ %d.\n", >> (u32)ndev->base_addr, ndev->dev_addr, ndev->irq); >> >> + pm_runtime_put_sync(&pdev->dev); > > I think you forgot to also do that on error cleanup path. > >> platform_set_drvdata(pdev, ndev); >> >> return ret; > > WBR, Sergei Thanks, will check this.
Hi Ben, Thank you for the patch. On Monday 17 March 2014 11:37:55 Ben Dooks wrote: > The pm_rumtime work queue is causing the device to be suspended during > initialisation, thus the initialisation may not be able to access registers > properly. As the code is called from a work queue, it is possible that this > is not seen from certain configurations/builds due to the asynchronos > nature of the code. > > Use pm_runtime_get_sync() and pm_runtime_put_sync() to ensure that the > pm system does not suspend it during the probe() call and remove the > now unnecessary pm_runtime_resume() call. > > This fixes the external abort that can cause /sbin/init or other such > init processed to die. > > Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> > Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> > --- > drivers/net/ethernet/renesas/sh_eth.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/renesas/sh_eth.c > b/drivers/net/ethernet/renesas/sh_eth.c index 4f76b5e..f1cfd64 100644 > --- a/drivers/net/ethernet/renesas/sh_eth.c > +++ b/drivers/net/ethernet/renesas/sh_eth.c > @@ -2869,7 +2869,7 @@ static int sh_eth_drv_probe(struct platform_device > *pdev) spin_lock_init(&mdp->lock); > mdp->pdev = pdev; > pm_runtime_enable(&pdev->dev); > - pm_runtime_resume(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); Now that we've found out that the problem is caused by registering the network device before registering the mdio bus, shouldn't the proper solution be to register the network device last in the probe function ? > > if (pdev->dev.of_node) > pd = sh_eth_parse_dt(&pdev->dev); > @@ -2961,6 +2961,7 @@ static int sh_eth_drv_probe(struct platform_device > *pdev) pr_info("Base address at 0x%x, %pM, IRQ %d.\n", > (u32)ndev->base_addr, ndev->dev_addr, ndev->irq); > > + pm_runtime_put_sync(&pdev->dev); > platform_set_drvdata(pdev, ndev); > > return ret;
Hi Sergei, On Tuesday 18 March 2014 01:30:26 Sergei Shtylyov wrote: > On 03/17/2014 11:23 PM, Laurent Pinchart wrote: > >> The pm_rumtime work queue is causing the device to be suspended during > >> initialisation, thus the initialisation may not be able to access > >> registers properly. As the code is called from a work queue, it is > >> possible that this is not seen from certain configurations/builds due to > >> the asynchronos nature of the code. > >> > >> Use pm_runtime_get_sync() and pm_runtime_put_sync() to ensure that the > >> pm system does not suspend it during the probe() call and remove the > >> now unnecessary pm_runtime_resume() call. > >> > >> This fixes the external abort that can cause /sbin/init or other such > >> init processed to die. > >> > >> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> > >> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> > >> --- > >> > >> drivers/net/ethernet/renesas/sh_eth.c | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/net/ethernet/renesas/sh_eth.c > >> b/drivers/net/ethernet/renesas/sh_eth.c index 4f76b5e..f1cfd64 100644 > >> --- a/drivers/net/ethernet/renesas/sh_eth.c > >> +++ b/drivers/net/ethernet/renesas/sh_eth.c > >> @@ -2869,7 +2869,7 @@ static int sh_eth_drv_probe(struct platform_device > >> *pdev) spin_lock_init(&mdp->lock); > >> > >> mdp->pdev = pdev; > >> pm_runtime_enable(&pdev->dev); > >> > >> - pm_runtime_resume(&pdev->dev); > >> + pm_runtime_get_sync(&pdev->dev); > > > > Now that we've found out that the problem is caused by registering the > > network device before registering the mdio bus, shouldn't the proper > > solution be to register the network device last in the probe function ? > > Unfortunately, it's not easy to do, as sh_mdio_init() uses net_device::dev. > Probably could get rid of that use by partly reverting my managed device API > patch since the only user seems to be devm_kzalloc() in that function, at > least I hope so... still looking into this. What about using pdev->dev instead ? > BTW, quite many drivers have the same problem, doing different things after > register_netdev() call, many of them probing MDIO as well. Great, that means more opportunities to fix bugs :-D
Hello. On 03/17/2014 11:23 PM, Laurent Pinchart wrote: >> The pm_rumtime work queue is causing the device to be suspended during >> initialisation, thus the initialisation may not be able to access registers >> properly. As the code is called from a work queue, it is possible that this >> is not seen from certain configurations/builds due to the asynchronos >> nature of the code. >> Use pm_runtime_get_sync() and pm_runtime_put_sync() to ensure that the >> pm system does not suspend it during the probe() call and remove the >> now unnecessary pm_runtime_resume() call. >> This fixes the external abort that can cause /sbin/init or other such >> init processed to die. >> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> >> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> >> --- >> drivers/net/ethernet/renesas/sh_eth.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> diff --git a/drivers/net/ethernet/renesas/sh_eth.c >> b/drivers/net/ethernet/renesas/sh_eth.c index 4f76b5e..f1cfd64 100644 >> --- a/drivers/net/ethernet/renesas/sh_eth.c >> +++ b/drivers/net/ethernet/renesas/sh_eth.c >> @@ -2869,7 +2869,7 @@ static int sh_eth_drv_probe(struct platform_device >> *pdev) spin_lock_init(&mdp->lock); >> mdp->pdev = pdev; >> pm_runtime_enable(&pdev->dev); >> - pm_runtime_resume(&pdev->dev); >> + pm_runtime_get_sync(&pdev->dev); > Now that we've found out that the problem is caused by registering the network > device before registering the mdio bus, shouldn't the proper solution be to > register the network device last in the probe function ? Unfortunately, it's not easy to do, as sh_mdio_init() uses net_device::dev. Probably could get rid of that use by partly reverting my managed device API patch since the only user seems to be devm_kzalloc() in that function, at least I hope so... still looking into this. BTW, quite many drivers have the same problem, doing different things after register_netdev() call, many of them probing MDIO as well. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. On 03/18/2014 12:34 AM, Laurent Pinchart wrote: >>>> The pm_rumtime work queue is causing the device to be suspended during >>>> initialisation, thus the initialisation may not be able to access >>>> registers properly. As the code is called from a work queue, it is >>>> possible that this is not seen from certain configurations/builds due to >>>> the asynchronos nature of the code. >>>> Use pm_runtime_get_sync() and pm_runtime_put_sync() to ensure that the >>>> pm system does not suspend it during the probe() call and remove the >>>> now unnecessary pm_runtime_resume() call. >>>> This fixes the external abort that can cause /sbin/init or other such >>>> init processed to die. >>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> >>>> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> >>>> --- >>>> drivers/net/ethernet/renesas/sh_eth.c | 3 ++- >>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>> diff --git a/drivers/net/ethernet/renesas/sh_eth.c >>>> b/drivers/net/ethernet/renesas/sh_eth.c index 4f76b5e..f1cfd64 100644 >>>> --- a/drivers/net/ethernet/renesas/sh_eth.c >>>> +++ b/drivers/net/ethernet/renesas/sh_eth.c >>>> @@ -2869,7 +2869,7 @@ static int sh_eth_drv_probe(struct platform_device >>>> *pdev) spin_lock_init(&mdp->lock); >>>> >>>> mdp->pdev = pdev; >>>> pm_runtime_enable(&pdev->dev); >>>> >>>> - pm_runtime_resume(&pdev->dev); >>>> + pm_runtime_get_sync(&pdev->dev); >>> Now that we've found out that the problem is caused by registering the >>> network device before registering the mdio bus, shouldn't the proper >>> solution be to register the network device last in the probe function ? >> Unfortunately, it's not easy to do, as sh_mdio_init() uses net_device::dev. >> Probably could get rid of that use by partly reverting my managed device API >> patch since the only user seems to be devm_kzalloc() in that function, at >> least I hope so... still looking into this. > What about using pdev->dev instead ? Well, that seems possible too. >> BTW, quite many drivers have the same problem, doing different things after >> register_netdev() call, many of them probing MDIO as well. > Great, that means more opportunities to fix bugs :-D For somebody else, maybe. My manager tells me not to spend time even on the 'sh_eth' driver... sigh. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c index 4f76b5e..f1cfd64 100644 --- a/drivers/net/ethernet/renesas/sh_eth.c +++ b/drivers/net/ethernet/renesas/sh_eth.c @@ -2869,7 +2869,7 @@ static int sh_eth_drv_probe(struct platform_device *pdev) spin_lock_init(&mdp->lock); mdp->pdev = pdev; pm_runtime_enable(&pdev->dev); - pm_runtime_resume(&pdev->dev); + pm_runtime_get_sync(&pdev->dev); if (pdev->dev.of_node) pd = sh_eth_parse_dt(&pdev->dev); @@ -2961,6 +2961,7 @@ static int sh_eth_drv_probe(struct platform_device *pdev) pr_info("Base address at 0x%x, %pM, IRQ %d.\n", (u32)ndev->base_addr, ndev->dev_addr, ndev->irq); + pm_runtime_put_sync(&pdev->dev); platform_set_drvdata(pdev, ndev); return ret;