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

[Saravana Kannan]

On Thu, Aug 6, 2020 at 8:09 PM John Stultz <john.stultz@xxxxxxxxxx> wrote:
>
> On Thu, Aug 6, 2020 at 8:02 PM Saravana Kannan <saravanak@xxxxxxxxxx> wrote:
> > On Thu, Aug 6, 2020 at 7:49 PM John Stultz <john.stultz@xxxxxxxxxx> wrote:
> > > On Thu, Aug 6, 2020 at 6:42 PM Bjorn Andersson
> > > <bjorn.andersson@xxxxxxxxxx> wrote:
> > > > With all due respect, that's your downstream kernel, the upstream kernel
> > > > should not rely on luck, out-of-tree patches or kernel parameters.
> > >
> > > I agree that would be preferred. But kernel parameters are often there
> > > for these sorts of cases where we can't always do the right thing.  As
> > > for out-of-tree patches, broken things don't get fixed until
> > > out-of-tree patches are developed and upstreamed, and I know Saravana
> > > is doing exactly that, and I hope his fw_devlink work helps fix it so
> > > the module loading is not just a matter of luck.
> >
> > Btw, the only downstream fw_devlink change is setting itto =on (vs
> > =permissive in upstream).
>
> I thought there was the clk_sync_state stuff as well?

That's not needed to solve the module load ordering issues and
deferred probe issues. That's only needed to keep clocks on till some
of the modules are loaded and it depends on fw_devlink, but not really
a part of fw_devlink IMHO. And yes, that's on my list of things to
upstream.

> > > Also I think Thierry's comments in the other thread today are also
> > > good ideas for ways to better handle the optional dt link handling
> > > (rather than using a timeout).
> >
> > Could you please give me a lore link to this thread? Just curious.
>
> Sure: https://lore.kernel.org/lkml/20200806135251.GB3351349@ulmo/

Thanks.

-Saravana