Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1001556imm; Wed, 10 Oct 2018 07:41:11 -0700 (PDT) X-Google-Smtp-Source: ACcGV632b2GO8SBqskL4KPN6s+ceyRPuhiwnZwtRoJLEx6cHvbHcmkX98b7AU7utGwTkO4Rggl68 X-Received: by 2002:a17:902:740a:: with SMTP id g10-v6mr119246pll.126.1539182471048; Wed, 10 Oct 2018 07:41:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539182471; cv=none; d=google.com; s=arc-20160816; b=EjJBf8EX5tob6O97MMP5BAJCXMt+sLQL/cBOS8ba+pSBs8G8+q5kPzR7HtctgMa7O6 e9n6kEBFljAJXuUM3ohbqOBhyT3j16yFsqePmE1VjghUgRgBl1z893Iv9CLWfJ660P9Q etinyITFxWSXbmQ8y13okuciB5xN8C3QJNlSAeKeNewOD0F3+1shuJkhst0UNcmjYwu8 b3j6zVoyZt9JobPAARNJz5u+goeyz9bDM/hkxSmMxaO5cRC52jeafmfcSg+/Q/lvmd2X Vv4IyqJyYhMgdBQlzWq+2q0eKSDZfrpD6Tj6HB3kZl0GUn16DHIF0PxkjN/EYFd0fUMb hZ5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=TFKoFv14zUpygtTSqM717XXmgHpxELOO66Bk4pvQhBQ=; b=UQR3su6E4Ua2RQdPy7+6MUBF8q8neSR1w9MfH8QDLiBvLkb7n7xijZwDh4fGwIWrdk /Ex4held+biES5bBuumddDNeLX2uwhBL2Chcn7i5vKgwbszuW6dEwy94uIE9fk7Swt/w CbRT1fz/mzVd60X2J0E3hYXDGmfAa5qyU3JvYuz7JYaQuGxzoMx7v10g4TgrHflHjIdf CxVlnvoDnTlQJ7dR0fk212i+KTw0Y0rUAik6APA2sDWvAy7QQqAPXArlYViAvigW50yK XCaz7+PYTaUaQual0CV8I4acwA9WI0LESMhze1gw9YdqZe4xy692oCMWbnEBbA0b9/XA KLoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=GvZF5m9E; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q137-v6si30567921pfq.178.2018.10.10.07.40.56; Wed, 10 Oct 2018 07:41:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=GvZF5m9E; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727252AbeJJWC3 (ORCPT + 99 others); Wed, 10 Oct 2018 18:02:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:37242 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726700AbeJJWC3 (ORCPT ); Wed, 10 Oct 2018 18:02:29 -0400 Received: from localhost (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 50D002087A; Wed, 10 Oct 2018 14:40:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1539182400; bh=ot0Jt29+prHQwm0YKxMj5B7crTjeWZGIVKesIcpef1k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GvZF5m9E9cBp0GZzDHkdBqskdF4Yk/xzzql57S1mgYQl2lv1zenbkR9vOUAHfmimD AD3YxroC57B7nG/if/3WJikZGGaYMMOvdHnPpskGh3bJepfwLy3EY4Hh7YkuBwpWQM E135d7X6TNa29c7D62ZYf35DBvY0VTyxrODIXxrI= Date: Wed, 10 Oct 2018 10:39:59 -0400 From: Sasha Levin To: Greg KH Cc: Linus Walleij , Nathan Chancellor , "linux-kernel@vger.kernel.org" , stable , Stephen Boyd , Doug Anderson , Bjorn Andersson , Sasha Levin Subject: Re: [PATCH 4.4 093/113] pinctrl: msm: Really mask level interrupts to prevent latching Message-ID: <20181010143959.GG32006@sasha-vm> References: <20181008175530.864641368@linuxfoundation.org> <20181008175536.405502473@linuxfoundation.org> <20181009063338.GA22218@flashbox> <20181010075337.GA13524@localhost> <20181010124509.GA30716@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20181010124509.GA30716@kroah.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> 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 >> > > 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