Linux on ARM based TI OMAP SoCs
 help / color / mirror / Atom feed
From: David Rivshin <drivshin@awxrd.com>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Ladislav Michl <ladis@linux-mips.org>,
	David Rivshin <drivshin@allworx.com>,
	Andreas Kemnade <andreas@kemnade.info>,
	linux-pwm@vger.kernel.org,
	linux-omap <linux-omap@vger.kernel.org>,
	Tony Lindgren <tony@atomide.com>, Keerthy <j-keerthy@ti.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Discussions about the Letux Kernel <letux-kernel@openphoenux.org>
Subject: Re: [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER
Date: Tue, 31 Jul 2018 10:35:25 -0400	[thread overview]
Message-ID: <20180731103525.7d4c5b47.drivshin@awxrd.com> (raw)
In-Reply-To: <BC0B4EAD-6DC1-4338-9185-FA319F998D41@goldelico.com>

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
> 

      reply	other threads:[~2018-07-31 14:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-28 16:59 [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER Andreas Kemnade
2018-07-28 20:35 ` Ladislav Michl
2018-07-29  6:32   ` H. Nikolaus Schaller
2018-07-29 18:08     ` Ladislav Michl
2018-07-29 18:19       ` H. Nikolaus Schaller
2018-07-30 22:56         ` David Rivshin
2018-07-31  6:35           ` H. Nikolaus Schaller
2018-07-31 14:35             ` David Rivshin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180731103525.7d4c5b47.drivshin@awxrd.com \
    --to=drivshin@awxrd.com \
    --cc=andreas@kemnade.info \
    --cc=drivshin@allworx.com \
    --cc=hns@goldelico.com \
    --cc=j-keerthy@ti.com \
    --cc=ladis@linux-mips.org \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox