On Wed, Oct 10, 2018 at 10:39:59AM -0400, Sasha Levin wrote: > 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. Sorry, I don't mean for it to look that way at all. That's not what I was meaning to imply. > 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. I would like to see what the developers here can find out first about the out-of-tree code to see where the fault lies. I have no problem breaking out-of-tree code if it is obviously wrong, but the interaction with the pinctl subsytem and various older drivers is very touchy at times, and we have had to revert things to keep everyone happy. So there is some history here, and I want to make sure who is to blame first. I lay odds on the msm out of tree driver :) thanks, gre k-h
