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@xxxxxxxxxxxxx> wrote:

> > Am 31.07.2018 um 00:56 schrieb David Rivshin <drivshin@xxxxxxxxx>:
> > 
> > On Sun, 29 Jul 2018 20:19:08 +0200
> > "H. Nikolaus Schaller" <hns@xxxxxxxxxxxxx> wrote:
> >   
> >> Hi,
> >>   
> >>> Am 29.07.2018 um 20:08 schrieb Ladislav Michl <ladis@xxxxxxxxxxxxxx>:
> >>> 
> >>> 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@xxxxxxxxxxxxxx>:
> >>>>> 
> >>>>> 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
>