Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros

[Bjorn Andersson]

On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote:

> On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski <steev@xxxxxxxx> wrote:
> >
> >
> > On 8/5/20 4:16 PM, Steev Klimaszewski wrote:
> > > On 8/5/20 3:19 PM, Saravana Kannan wrote:
> > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@xxxxxxxxxx> wrote:
> > >>> <sigh>
> > >>> So this is where I bashfully admit I didn't get a chance to try this
> > >>> patch series out, as I had success with a much older version of
> > >>> Saravana's macro magic.
> > >>>
> > >>> But unfortunately, now that this has landed in mainline, I'm seeing
> > >>> boot regressions on db845c. :( This is in the non-modular case,
> > >>> building the driver in.
> > >> Does that mean the modular version is working? Or you haven't tried
> > >> that yet? I'll wait for your reply before I try to fix it. I don't
> > >> have the hardware, but it should be easy to guess this issue looking
> > >> at the code delta.
> > > For what it's worth, I saw this too on the Lenovo C630 (started on -next
> > > around 20200727, but I didn't track it down as, well, there's less way
> > > to get debug output on the C630.
> > >
> > > In my testing, module or built-in doesn't matter, but reverting does
> > > allow me to boot again.
> > >
> > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted
> > boots, however, module (on the c630 at least) doesn't boot whether it's
> > a module or built-in.
> 
> You may need to set deferred_probe_timeout=30 to give things a bit
> more grace time to load.

With the risk of me reading more into this than what you're saying,
please don't upstream anything that depend this parameter to be
increased.

Compiling any of these drivers as module should not require the user to
pass additional kernel command line parameters in order to get their
device to boot.

Regards,
Bjorn

> (I've mostly recently used qcom-pdc as a module with the android tree,
> so the fw_devlink bits help there, but I need to re-check the state of
> that upstream.)
> 
> I'll dbl check this and dig more on the issue with the patch in
> question once I can get back in my office later today.
> 
> thanks
> -john