[PATCH] sh_eth: ensure pm_runtime cannot suspend the device during init

[PATCH] sh_eth: ensure pm_runtime cannot suspend the device during init

[Ben Dooks]

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);
 
 	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;
-- 
1.9.0

Re: [PATCH] sh_eth: ensure pm_runtime cannot suspend the device during init

[Sergei Shtylyov]

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

Re: [PATCH] sh_eth: ensure pm_runtime cannot suspend the device during init

[Ben Dooks]

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.



-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

Re: [PATCH] sh_eth: ensure pm_runtime cannot suspend the device during init

[Laurent Pinchart]

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;

-- 
Regards,

Laurent Pinchart

Re: [PATCH] sh_eth: ensure pm_runtime cannot suspend the device during init

[Sergei Shtylyov]

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

Re: [PATCH] sh_eth: ensure pm_runtime cannot suspend the device during init

[Laurent Pinchart]

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

-- 
Regards,

Laurent Pinchart

Re: [PATCH] sh_eth: ensure pm_runtime cannot suspend the device during init

[Sergei Shtylyov]

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