[PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER

[PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER

[Andreas Kemnade]

I got this in the kernel log:
[    0.756042] omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
[    0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22

the probe function has to wait until omap_dm_timer_probe() in
clocksource/timer-ti-dm.c has initialized pdata, so defer probing

Fixes: b7290cf6ff78 (pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops)
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
 drivers/pwm/pwm-omap-dmtimer.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
index 665da3c8fbce..808835179c2e 100644
--- a/drivers/pwm/pwm-omap-dmtimer.c
+++ b/drivers/pwm/pwm-omap-dmtimer.c
@@ -264,8 +264,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
 
 	timer_pdata = dev_get_platdata(&timer_pdev->dev);
 	if (!timer_pdata) {
-		dev_err(&pdev->dev, "dmtimer pdata structure NULL\n");
-		ret = -EINVAL;
+		ret = -EPROBE_DEFER;
 		goto put;
 	}
 
-- 
2.11.0

Re: [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER

[Ladislav Michl]

Hi Andreas,

On Sat, Jul 28, 2018 at 06:59:14PM +0200, Andreas Kemnade wrote:
> I got this in the kernel log:
> [    0.756042] omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
> [    0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
> 
> the probe function has to wait until omap_dm_timer_probe() in
> clocksource/timer-ti-dm.c has initialized pdata, so defer probing

There already is a patch by David Rivshin addressing the same issue...

> Fixes: b7290cf6ff78 (pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops)
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
>  drivers/pwm/pwm-omap-dmtimer.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
> index 665da3c8fbce..808835179c2e 100644
> --- a/drivers/pwm/pwm-omap-dmtimer.c
> +++ b/drivers/pwm/pwm-omap-dmtimer.c
> @@ -264,8 +264,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
>  
>  	timer_pdata = dev_get_platdata(&timer_pdev->dev);
>  	if (!timer_pdata) {
> -		dev_err(&pdev->dev, "dmtimer pdata structure NULL\n");
> -		ret = -EINVAL;
> +		ret = -EPROBE_DEFER;
>  		goto put;
>  	}
>  
> -- 
> 2.11.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER

[H. Nikolaus Schaller]

Hi,

> Am 28.07.2018 um 22:35 schrieb Ladislav Michl <ladis@linux-mips.org>:
> 
> Hi Andreas,
> 
> On Sat, Jul 28, 2018 at 06:59:14PM +0200, Andreas Kemnade wrote:
>> I got this in the kernel log:
>> [    0.756042] omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
>> [    0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
>> 
>> the probe function has to wait until omap_dm_timer_probe() in
>> clocksource/timer-ti-dm.c has initialized pdata, so defer probing
> 
> There already is a patch by David Rivshin addressing the same issue...

Here it is:

https://patchwork.ozlabs.org/patch/943148/

but hasn't arrived in linux-next.

But it is questionable if a driver should dev_info() about doing deferred probing.
IMHO, it should just do it which is how Andreas' patch works.

> 
>> Fixes: b7290cf6ff78 (pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops)
>> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
>> ---
>> drivers/pwm/pwm-omap-dmtimer.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>> 
>> diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
>> index 665da3c8fbce..808835179c2e 100644
>> --- a/drivers/pwm/pwm-omap-dmtimer.c
>> +++ b/drivers/pwm/pwm-omap-dmtimer.c
>> @@ -264,8 +264,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
>> 
>> 	timer_pdata = dev_get_platdata(&timer_pdev->dev);
>> 	if (!timer_pdata) {
>> -		dev_err(&pdev->dev, "dmtimer pdata structure NULL\n");
>> -		ret = -EINVAL;
>> +		ret = -EPROBE_DEFER;
>> 		goto put;
>> 	}
>> 
>> -- 
>> 2.11.0
>> 

BR,
Nikolaus

Re: [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER

[Ladislav Michl]

On Sun, Jul 29, 2018 at 08:32:41AM +0200, H. Nikolaus Schaller wrote:
> Hi,
> 
> > Am 28.07.2018 um 22:35 schrieb Ladislav Michl <ladis@linux-mips.org>:
> > 
> > Hi Andreas,
> > 
> > On Sat, Jul 28, 2018 at 06:59:14PM +0200, Andreas Kemnade wrote:
> >> I got this in the kernel log:
> >> [    0.756042] omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
> >> [    0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
> >> 
> >> the probe function has to wait until omap_dm_timer_probe() in
> >> clocksource/timer-ti-dm.c has initialized pdata, so defer probing
> > 
> > There already is a patch by David Rivshin addressing the same issue...
> 
> Here it is:
> 
> https://patchwork.ozlabs.org/patch/943148/
> 
> but hasn't arrived in linux-next.

That's because there'll be v3.

> But it is questionable if a driver should dev_info() about doing deferred probing.
> IMHO, it should just do it which is how Andreas' patch works.

See here: https://patchwork.ozlabs.org/patch/949659/

> >> Fixes: b7290cf6ff78 (pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops)
> >> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> >> ---
> >> drivers/pwm/pwm-omap-dmtimer.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >> 
> >> diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
> >> index 665da3c8fbce..808835179c2e 100644
> >> --- a/drivers/pwm/pwm-omap-dmtimer.c
> >> +++ b/drivers/pwm/pwm-omap-dmtimer.c
> >> @@ -264,8 +264,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device *pdev)
> >> 
> >> 	timer_pdata = dev_get_platdata(&timer_pdev->dev);
> >> 	if (!timer_pdata) {
> >> -		dev_err(&pdev->dev, "dmtimer pdata structure NULL\n");
> >> -		ret = -EINVAL;
> >> +		ret = -EPROBE_DEFER;
> >> 		goto put;
> >> 	}
> >> 
> >> -- 
> >> 2.11.0
> >> 
> 
> BR,
> Nikolaus
> 

Re: [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER

[H. Nikolaus Schaller]

Hi,

> Am 29.07.2018 um 20:08 schrieb Ladislav Michl <ladis@linux-mips.org>:
> 
> On Sun, Jul 29, 2018 at 08:32:41AM +0200, H. Nikolaus Schaller wrote:
>> Hi,
>> 
>>> Am 28.07.2018 um 22:35 schrieb Ladislav Michl <ladis@linux-mips.org>:
>>> 
>>> Hi Andreas,
>>> 
>>> On Sat, Jul 28, 2018 at 06:59:14PM +0200, Andreas Kemnade wrote:
>>>> I got this in the kernel log:
>>>> [    0.756042] omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
>>>> [    0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
>>>> 
>>>> the probe function has to wait until omap_dm_timer_probe() in
>>>> clocksource/timer-ti-dm.c has initialized pdata, so defer probing
>>> 
>>> There already is a patch by David Rivshin addressing the same issue...
>> 
>> Here it is:
>> 
>> https://patchwork.ozlabs.org/patch/943148/
>> 
>> but hasn't arrived in linux-next.
> 
> That's because there'll be v3.
> 
>> But it is questionable if a driver should dev_info() about doing deferred probing.
>> IMHO, it should just do it which is how Andreas' patch works.
> 
> See here: https://patchwork.ozlabs.org/patch/949659/

Ah, I see (neither Andreas nor me did follow the original discussions
and therefore came up independently with the same thoughts).

So we will wait for the v3.

BR and thanks,
Nikolaus

Re: [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER

[David Rivshin]

On Sun, 29 Jul 2018 20:19:08 +0200
"H. Nikolaus Schaller" <hns@goldelico.com> wrote:

> Hi,
> 
> > Am 29.07.2018 um 20:08 schrieb Ladislav Michl <ladis@linux-mips.org>:
> > 
> > On Sun, Jul 29, 2018 at 08:32:41AM +0200, H. Nikolaus Schaller wrote:  
> >> Hi,
> >>   
> >>> Am 28.07.2018 um 22:35 schrieb Ladislav Michl <ladis@linux-mips.org>:
> >>> 
> >>> Hi Andreas,
> >>> 
> >>> On Sat, Jul 28, 2018 at 06:59:14PM +0200, Andreas Kemnade wrote:  
> >>>> I got this in the kernel log:
> >>>> [    0.756042] omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
> >>>> [    0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
> >>>> 
> >>>> the probe function has to wait until omap_dm_timer_probe() in
> >>>> clocksource/timer-ti-dm.c has initialized pdata, so defer probing  
> >>> 
> >>> There already is a patch by David Rivshin addressing the same issue...  
> >> 
> >> Here it is:
> >> 
> >> https://patchwork.ozlabs.org/patch/943148/
> >> 
> >> but hasn't arrived in linux-next.  
> > 
> > That's because there'll be v3.
> >   
> >> But it is questionable if a driver should dev_info() about doing deferred probing.
> >> IMHO, it should just do it which is how Andreas' patch works.  
> > 
> > See here: https://patchwork.ozlabs.org/patch/949659/  
> 
> Ah, I see (neither Andreas nor me did follow the original discussions
> and therefore came up independently with the same thoughts).

Seems a lot of us have tripped over this problem at roughly the same 
time. I'm hoping Thierry picks it up in time for the 4.19 merge window.

> So we will wait for the v3.

FYI, v3 has been posted: https://patchwork.ozlabs.org/patch/951299/
Let me know if you feel strongly enough about having no message
(vs dev_dbg) for me to spin a quick v4. Seems like each additional 
pair of eyes leans in that direction.

Ladislav, I realized just after I sent that I forgot to add your ack
to the commit message. Sorry for the oversight.

> 
> BR and thanks,
> Nikolaus
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pwm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER

[H. Nikolaus Schaller]

> Am 31.07.2018 um 00:56 schrieb David Rivshin <drivshin@awxrd.com>:
> 
> On Sun, 29 Jul 2018 20:19:08 +0200
> "H. Nikolaus Schaller" <hns@goldelico.com> wrote:
> 
>> Hi,
>> 
>>> Am 29.07.2018 um 20:08 schrieb Ladislav Michl <ladis@linux-mips.org>:
>>> 
>>> On Sun, Jul 29, 2018 at 08:32:41AM +0200, H. Nikolaus Schaller wrote:  
>>>> Hi,
>>>> 
>>>>> Am 28.07.2018 um 22:35 schrieb Ladislav Michl <ladis@linux-mips.org>:
>>>>> 
>>>>> Hi Andreas,
>>>>> 
>>>>> On Sat, Jul 28, 2018 at 06:59:14PM +0200, Andreas Kemnade wrote:  
>>>>>> I got this in the kernel log:
>>>>>> [    0.756042] omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
>>>>>> [    0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
>>>>>> 
>>>>>> the probe function has to wait until omap_dm_timer_probe() in
>>>>>> clocksource/timer-ti-dm.c has initialized pdata, so defer probing  
>>>>> 
>>>>> There already is a patch by David Rivshin addressing the same issue...  
>>>> 
>>>> Here it is:
>>>> 
>>>> https://patchwork.ozlabs.org/patch/943148/
>>>> 
>>>> but hasn't arrived in linux-next.  
>>> 
>>> That's because there'll be v3.
>>> 
>>>> But it is questionable if a driver should dev_info() about doing deferred probing.
>>>> IMHO, it should just do it which is how Andreas' patch works.  
>>> 
>>> See here: https://patchwork.ozlabs.org/patch/949659/  
>> 
>> Ah, I see (neither Andreas nor me did follow the original discussions
>> and therefore came up independently with the same thoughts).
> 
> Seems a lot of us have tripped over this problem at roughly the same 
> time. I'm hoping Thierry picks it up in time for the 4.19 merge window.

Well, if possible it should be backported to 4.18 and 4.17.

> 
>> So we will wait for the v3.
> 
> FYI, v3 has been posted: https://patchwork.ozlabs.org/patch/951299/
> Let me know if you feel strongly enough about having no message
> (vs dev_dbg) for me to spin a quick v4.

I am fine with dev_dbg.

> Seems like each additional 
> pair of eyes leans in that direction.
> 
> Ladislav, I realized just after I sent that I forgot to add your ack
> to the commit message. Sorry for the oversight.
> 

BR and thanks,
Nikolaus

Re: [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER

[David Rivshin]

On Tue, 31 Jul 2018 08:35:26 +0200
"H. Nikolaus Schaller" <hns@goldelico.com> wrote:

> > Am 31.07.2018 um 00:56 schrieb David Rivshin <drivshin@awxrd.com>:
> > 
> > On Sun, 29 Jul 2018 20:19:08 +0200
> > "H. Nikolaus Schaller" <hns@goldelico.com> wrote:
> >   
> >> Hi,
> >>   
> >>> Am 29.07.2018 um 20:08 schrieb Ladislav Michl <ladis@linux-mips.org>:
> >>> 
> >>> On Sun, Jul 29, 2018 at 08:32:41AM +0200, H. Nikolaus Schaller wrote:    
> >>>> Hi,
> >>>>   
> >>>>> Am 28.07.2018 um 22:35 schrieb Ladislav Michl <ladis@linux-mips.org>:
> >>>>> 
> >>>>> Hi Andreas,
> >>>>> 
> >>>>> On Sat, Jul 28, 2018 at 06:59:14PM +0200, Andreas Kemnade wrote:    
> >>>>>> I got this in the kernel log:
> >>>>>> [    0.756042] omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
> >>>>>> [    0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
> >>>>>> 
> >>>>>> the probe function has to wait until omap_dm_timer_probe() in
> >>>>>> clocksource/timer-ti-dm.c has initialized pdata, so defer probing    
> >>>>> 
> >>>>> There already is a patch by David Rivshin addressing the same issue...    
> >>>> 
> >>>> Here it is:
> >>>> 
> >>>> https://patchwork.ozlabs.org/patch/943148/
> >>>> 
> >>>> but hasn't arrived in linux-next.    
> >>> 
> >>> That's because there'll be v3.
> >>>   
> >>>> But it is questionable if a driver should dev_info() about doing deferred probing.
> >>>> IMHO, it should just do it which is how Andreas' patch works.    
> >>> 
> >>> See here: https://patchwork.ozlabs.org/patch/949659/    
> >> 
> >> Ah, I see (neither Andreas nor me did follow the original discussions
> >> and therefore came up independently with the same thoughts).  
> > 
> > Seems a lot of us have tripped over this problem at roughly the same 
> > time. I'm hoping Thierry picks it up in time for the 4.19 merge window.  
> 
> Well, if possible it should be backported to 4.18 and 4.17.

Agreed. I have a Fixes: and CC:stable in the commit message, so it should
get backported shortly after getting merged to mainline. I assume it's too 
late for 4.18-rcX since it's not in linux-next yet, which is why I said 
hopefully 4.19-rc1.

> 
> >   
> >> So we will wait for the v3.  
> > 
> > FYI, v3 has been posted: https://patchwork.ozlabs.org/patch/951299/
> > Let me know if you feel strongly enough about having no message
> > (vs dev_dbg) for me to spin a quick v4.  
> 
> I am fine with dev_dbg.
> 
> > Seems like each additional 
> > pair of eyes leans in that direction.
> > 
> > Ladislav, I realized just after I sent that I forgot to add your ack
> > to the commit message. Sorry for the oversight.
> >   
> 
> BR and thanks,
> Nikolaus
>