Re: [PATCH 4.4 093/113] pinctrl: msm: Really mask level interrupts to prevent latching

[Sasha Levin]

On Wed, Oct 10, 2018 at 02:45:09PM +0200, Greg KH wrote:
> On Wed, Oct 10, 2018 at 02:12:01PM +0200, Linus Walleij wrote:
> > On Wed, Oct 10, 2018 at 9:53 AM Nathan Chancellor
> > <natechancellor@xxxxxxxxx> wrote:
> > > On Wed, Oct 10, 2018 at 09:12:58AM +0200, Linus Walleij wrote:
> > > > On Tue, Oct 9, 2018 at 8:33 AM Nathan Chancellor
> > > > <natechancellor@xxxxxxxxx> wrote:
> > > >
> > > > > Sigh, sorry, I caught this after I sent my initial all good email but
> > > > > this commit breaks NFC on my Pixel 2 XL (toggle becomes greyed out and
> > > > > apps that want to use it ask to enable it). I can't say why, I'm more
> > > > > than happy to debug but I'm assuming it's some voodoo that Qualcomm has
> > > > > done out of tree. I'll leave it up to you how to proceed given that I
> > > > > can't run mainline :(
> > > >
> > > > Which NFC driver is this?
> > > > Just want to make sure it looks sane.
> > > >
> > > > Yours,
> > > > Linus Walleij
> > >
> > > Hi Linus and Bjorn,
> > >
> > > These two files should be it I believe:
> > > https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.22/drivers/nfc/nq-nci.c
> > > https://android.googlesource.com/kernel/msm/+/android-9.0.0_r0.22/drivers/nfc/ese/pn81a.c
> > >
> > > Sorry I didn't get around to digging into this further today, I will try
> > > to get to it in the morning.
> >
> > I'm confused. These are not in the mainline kernel and presumably
> > not in the stable kernel either.
> >
> > So when you say "this commit breaks NFC on my Pixel 2 XL" you
> > mean that when you apply this commit to the android msm kernel,
> > which has a few other stable fixes backported, it breaks?
>
> If these drivers are obviously broken, I have no objection to merging
> patches like this and telling qcom to fix their code.  But if the issue
> is more subtle, like change in behavior that is unanticipated, then I am
> a bit more reluctant to take patches that break working systems.

I think that this is a dangerous precedent where we won't take a patch
that actually fixes in-tree code because it breaks out-of-tree code.

I understand your concern: it's possible that this patch is actually
broken, and we only see the breakage, by chance, with out-of-tree code.
We also don't want to subtly break out-of-tree users for no good reason.

Maybe a better solution is to give a courtesy heads-up to Qualcomm and
queue this patch to the next release (or maybe the one after the next).
If they can show that the patch is broken we can go ahead and revert/fix
it, but if it's not - it won't be indefinitely stuck out of the stable
tree while we try debugging Qualcomm's out-of-tree code.


--
Thanks,
Sasha