2018-07-28 17:02:20

by Andreas Kemnade

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

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 <[email protected]>
---
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



2018-07-28 20:36:58

by Ladislav Michl

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

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 <[email protected]>
> ---
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2018-07-29 06:34:51

by H. Nikolaus Schaller

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

Hi,

> Am 28.07.2018 um 22:35 schrieb Ladislav Michl <[email protected]>:
>
> 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 <[email protected]>
>> ---
>> 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



2018-07-29 18:09:17

by Ladislav Michl

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

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 <[email protected]>:
> >
> > 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 <[email protected]>
> >> ---
> >> 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
>

2018-07-29 18:20:19

by H. Nikolaus Schaller

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

Hi,

> Am 29.07.2018 um 20:08 schrieb Ladislav Michl <[email protected]>:
>
> 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 <[email protected]>:
>>>
>>> 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


2018-07-30 22:58:11

by David Rivshin

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

On Sun, 29 Jul 2018 20:19:08 +0200
"H. Nikolaus Schaller" <[email protected]> wrote:

> Hi,
>
> > Am 29.07.2018 um 20:08 schrieb Ladislav Michl <[email protected]>:
> >
> > 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 <[email protected]>:
> >>>
> >>> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html


2018-07-31 06:37:51

by H. Nikolaus Schaller

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


> Am 31.07.2018 um 00:56 schrieb David Rivshin <[email protected]>:
>
> On Sun, 29 Jul 2018 20:19:08 +0200
> "H. Nikolaus Schaller" <[email protected]> wrote:
>
>> Hi,
>>
>>> Am 29.07.2018 um 20:08 schrieb Ladislav Michl <[email protected]>:
>>>
>>> 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 <[email protected]>:
>>>>>
>>>>> 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


2018-07-31 14:36:37

by David Rivshin

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

On Tue, 31 Jul 2018 08:35:26 +0200
"H. Nikolaus Schaller" <[email protected]> wrote:

> > Am 31.07.2018 um 00:56 schrieb David Rivshin <[email protected]>:
> >
> > On Sun, 29 Jul 2018 20:19:08 +0200
> > "H. Nikolaus Schaller" <[email protected]> wrote:
> >
> >> Hi,
> >>
> >>> Am 29.07.2018 um 20:08 schrieb Ladislav Michl <[email protected]>:
> >>>
> >>> 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 <[email protected]>:
> >>>>>
> >>>>> 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
>