From patchwork Tue Apr 7 10:22:00 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228161 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9DCB5C2BB55 for ; Tue, 7 Apr 2020 10:27:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 68A612074B for ; Tue, 7 Apr 2020 10:27:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255261; bh=+9/waoq6urivDfNZvIaeIMosuJ6pHCmjRRVUUlB8Uig=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=1T0tyCkR+VEi7uZby4st/Hl6gXKaWI9GLGA4HHGZJ/MeQs/W0iWHiIjIx0aLoqUTY 95ZeLs6IfOSWLk/GaYJL1eUsdFr2TJgnXgvjvSHSqxrreDE+JNpYjTjGERe3Ez6Bz5 SEnH6jhTGgKI9EFWK4f1myztCXKJ8VFyT+IdmQ0I= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729220AbgDGK0q (ORCPT ); Tue, 7 Apr 2020 06:26:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:38932 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729215AbgDGK0p (ORCPT ); Tue, 7 Apr 2020 06:26:45 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 D10932074B; Tue, 7 Apr 2020 10:26:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255205; bh=+9/waoq6urivDfNZvIaeIMosuJ6pHCmjRRVUUlB8Uig=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kwm7mD3zf05JacqVEYGv2jqg4UYgSEvmLrueTcmnWj+y20uiyXwJ579D/oka7qWqq FILF+eNA/VtO8RFKkilCzt8tiN9BApvtVxk1PLCHv1m2jCzw2ljehJr4xgMoLoUfgD oOog3GpG4aKQghkWjtjL09WIPFAeeTDr9ehlk7FQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, William Dauchy , Nicolas Dichtel , "David S. Miller" Subject: [PATCH 5.6 03/29] net, ip_tunnel: fix interface lookup with no key Date: Tue, 7 Apr 2020 12:22:00 +0200 Message-Id: <20200407101452.411878897@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101452.046058399@linuxfoundation.org> References: <20200407101452.046058399@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: William Dauchy [ Upstream commit 25629fdaff2ff509dd0b3f5ff93d70a75e79e0a1 ] when creating a new ipip interface with no local/remote configuration, the lookup is done with TUNNEL_NO_KEY flag, making it impossible to match the new interface (only possible match being fallback or metada case interface); e.g: `ip link add tunl1 type ipip dev eth0` To fix this case, adding a flag check before the key comparison so we permit to match an interface with no local/remote config; it also avoids breaking possible userland tools relying on TUNNEL_NO_KEY flag and uninitialised key. context being on my side, I'm creating an extra ipip interface attached to the physical one, and moving it to a dedicated namespace. Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.") Signed-off-by: William Dauchy Signed-off-by: Nicolas Dichtel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/ipv4/ip_tunnel.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) --- a/net/ipv4/ip_tunnel.c +++ b/net/ipv4/ip_tunnel.c @@ -142,11 +142,8 @@ struct ip_tunnel *ip_tunnel_lookup(struc cand = t; } - if (flags & TUNNEL_NO_KEY) - goto skip_key_lookup; - hlist_for_each_entry_rcu(t, head, hash_node) { - if (t->parms.i_key != key || + if ((!(flags & TUNNEL_NO_KEY) && t->parms.i_key != key) || t->parms.iph.saddr != 0 || t->parms.iph.daddr != 0 || !(t->dev->flags & IFF_UP)) @@ -158,7 +155,6 @@ struct ip_tunnel *ip_tunnel_lookup(struc cand = t; } -skip_key_lookup: if (cand) return cand; From patchwork Tue Apr 7 10:22:05 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228162 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35515C2BB55 for ; Tue, 7 Apr 2020 10:27:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 065C22074B for ; Tue, 7 Apr 2020 10:27:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255258; bh=9yKfdel+qAZDrZmCqU4IVFOFzurKYm2wYy167EUh1lI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=yA0khIT2Z187WgtNWJZLTVyZmPB/SaFYpAzvQMM6FNta/OQ6RiCCkDWIA/GlyyWEb r11N9js7PEpTFW02+p8jxYtlFp3hVlnflZUaogIrZmQn0N5IX1kQ7mCEUPqaUZBHER cXN4Roeu7DJixmiMdPJrsOVhGbci1et9jbU2/zWo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728375AbgDGK1e (ORCPT ); Tue, 7 Apr 2020 06:27:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:39248 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728706AbgDGK06 (ORCPT ); Tue, 7 Apr 2020 06:26:58 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 EFA9B2074F; Tue, 7 Apr 2020 10:26:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255217; bh=9yKfdel+qAZDrZmCqU4IVFOFzurKYm2wYy167EUh1lI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dvagsU0RA+O2WTJKe6f45AL/hrdSLvY7+LbwOgUZ/M0DuA/NSPaLZ8Lzsz7NEE0rb 92OgLxpNVh1Y31tc1sp+TMmJ6bQikfmRtkiS+aSdUVRHuKBgGRKs5OnwVnlmaSl5w0 mcmMhJOXTB+V+1rvnzajaB+aUOvblsiK2LoeXAd4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xin Long , Steffen Klassert , "David S. Miller" Subject: [PATCH 5.6 08/29] udp: initialize is_flist with 0 in udp_gro_receive Date: Tue, 7 Apr 2020 12:22:05 +0200 Message-Id: <20200407101453.015096017@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101452.046058399@linuxfoundation.org> References: <20200407101452.046058399@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Xin Long [ Upstream commit bde1b56f898ca8112912d7b36e55e1543b3be0cf ] Without NAPI_GRO_CB(skb)->is_flist initialized, when the dev doesn't support NETIF_F_GRO_FRAGLIST, is_flist can still be set and fraglist will be used in udp_gro_receive(). So fix it by initializing is_flist with 0 in udp_gro_receive. Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.") Signed-off-by: Xin Long Acked-by: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/ipv4/udp_offload.c | 1 + 1 file changed, 1 insertion(+) --- a/net/ipv4/udp_offload.c +++ b/net/ipv4/udp_offload.c @@ -453,6 +453,7 @@ struct sk_buff *udp_gro_receive(struct l unsigned int off = skb_gro_offset(skb); int flush = 1; + NAPI_GRO_CB(skb)->is_flist = 0; if (skb->dev->features & NETIF_F_GRO_FRAGLIST) NAPI_GRO_CB(skb)->is_flist = sk ? !udp_sk(sk)->gro_enabled: 1; From patchwork Tue Apr 7 10:22:06 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228163 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48046C2BB54 for ; Tue, 7 Apr 2020 10:27:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1BD222078A for ; Tue, 7 Apr 2020 10:27:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255252; bh=P7iouULCpIAHpWLOd6Wjrgm7dXrqA8tQoL3jEOu3ql4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=WbnY5AX4hXwnvNzViCQeZOGkbXRIf+MFEfhU6OzwZLgbNVykkWrn04Um594CefZze KratxfJoJqZ2kbPXtIYM0yw74LSRtAKX9fbTCctiV/IQGHpOb3iHk3J7N3V3Hmz+a+ Kkd9WwIoEpPcMRj1TiIXU5DajLAzAB1Mi9H4Uluw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728709AbgDGK1B (ORCPT ); Tue, 7 Apr 2020 06:27:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:39302 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729256AbgDGK1B (ORCPT ); Tue, 7 Apr 2020 06:27:01 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 6C53E20644; Tue, 7 Apr 2020 10:26:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255219; bh=P7iouULCpIAHpWLOd6Wjrgm7dXrqA8tQoL3jEOu3ql4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JIh2c307cG7sLRuJmaQVWfsXuS9mdJripg8tX7hDuqujFtYenes7bG8DsM7MQuiKW wS9++TRMhr/niLKy/vbpwDcAlWc2MdcW6dqXW9qQ4yyLaEFP0aga7zjVpUU2KkAiPj 6tK176Tzw7hWdBnJgVG9CH0hUs3uobRPTHYUroVU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Geert Uytterhoeven , Daniel Jordan , Herbert Xu , Steffen Klassert , linux-crypto@vger.kernel.org, Sasha Levin Subject: [PATCH 5.6 09/29] padata: fix uninitialized return value in padata_replace() Date: Tue, 7 Apr 2020 12:22:06 +0200 Message-Id: <20200407101453.138259293@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101452.046058399@linuxfoundation.org> References: <20200407101452.046058399@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Daniel Jordan [ Upstream commit 41ccdbfd5427bbbf3ed58b16750113b38fad1780 ] According to Geert's report[0], kernel/padata.c: warning: 'err' may be used uninitialized in this function [-Wuninitialized]: => 539:2 Warning is seen only with older compilers on certain archs. The runtime effect is potentially returning garbage down the stack when padata's cpumasks are modified before any pcrypt requests have run. Simplest fix is to initialize err to the success value. [0] http://lkml.kernel.org/r/20200210135506.11536-1-geert@linux-m68k.org Reported-by: Geert Uytterhoeven Fixes: bbefa1dd6a6d ("crypto: pcrypt - Avoid deadlock by using per-instance padata queues") Signed-off-by: Daniel Jordan Cc: Herbert Xu Cc: Steffen Klassert Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin --- kernel/padata.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/padata.c b/kernel/padata.c index 72777c10bb9cb..62082597d4a2a 100644 --- a/kernel/padata.c +++ b/kernel/padata.c @@ -512,7 +512,7 @@ static int padata_replace_one(struct padata_shell *ps) static int padata_replace(struct padata_instance *pinst) { struct padata_shell *ps; - int err; + int err = 0; pinst->flags |= PADATA_RESET; From patchwork Tue Apr 7 10:22:08 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228168 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4F73C2BB55 for ; Tue, 7 Apr 2020 10:26:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9020E20644 for ; Tue, 7 Apr 2020 10:26:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255174; bh=amCQ2S+k05Zy4Vn910YGXUE1vYiFDagnqxSn0kCFoi0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=k/gv5jLWRbJMapt+e0pmoUg8llH+GORurPcfvp+B7y1yafCt8byCOL27GtSQMBreF eOhA0MasNK6blYZ517x2gAcET0HZWm2LG5emclIfsi2BU6BOQq4fXcqvGNItQ2WgMU 87QvxHI4Oom2IJYAf1wMWHEuossMf80fHV8isH8s= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728744AbgDGK0N (ORCPT ); Tue, 7 Apr 2020 06:26:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:37246 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729101AbgDGK0K (ORCPT ); Tue, 7 Apr 2020 06:26:10 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 AB4D02074F; Tue, 7 Apr 2020 10:26:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255169; bh=amCQ2S+k05Zy4Vn910YGXUE1vYiFDagnqxSn0kCFoi0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PpH0AZnnpM+okQxHzNxmv39qK0GmTLcgM8sMpVZ4CswiDHtW4ucT3IODNCjDYrC67 vJ/wJD9pM1RN7aLFHDJGz2F7dVdtIQLEogIEdlexsEHJEXYos9USphjCKhuzs2TOME tyggtiySc6eEQyx6OoG+hQcmk799BkW81WaM4llo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jann Horn , Daniel Borkmann , Alexei Starovoitov , Sasha Levin Subject: [PATCH 5.6 11/29] bpf: Fix tnum constraints for 32-bit comparisons Date: Tue, 7 Apr 2020 12:22:08 +0200 Message-Id: <20200407101453.370611188@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101452.046058399@linuxfoundation.org> References: <20200407101452.046058399@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Jann Horn [ Upstream commit 604dca5e3af1db98bd123b7bfc02b017af99e3a0 ] The BPF verifier tried to track values based on 32-bit comparisons by (ab)using the tnum state via 581738a681b6 ("bpf: Provide better register bounds after jmp32 instructions"). The idea is that after a check like this: if ((u32)r0 > 3) exit We can't meaningfully constrain the arithmetic-range-based tracking, but we can update the tnum state to (value=0,mask=0xffff'ffff'0000'0003). However, the implementation from 581738a681b6 didn't compute the tnum constraint based on the fixed operand, but instead derives it from the arithmetic-range-based tracking. This means that after the following sequence of operations: if (r0 >= 0x1'0000'0001) exit if ((u32)r0 > 7) exit The verifier assumed that the lower half of r0 is in the range (0, 0) and apply the tnum constraint (value=0,mask=0xffff'ffff'0000'0000) thus causing the overall tnum to be (value=0,mask=0x1'0000'0000), which was incorrect. Provide a fixed implementation. Fixes: 581738a681b6 ("bpf: Provide better register bounds after jmp32 instructions") Signed-off-by: Jann Horn Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200330160324.15259-3-daniel@iogearbox.net Signed-off-by: Sasha Levin --- kernel/bpf/verifier.c | 108 ++++++++++++++++++++++++++++-------------- 1 file changed, 72 insertions(+), 36 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 5080469094afe..595b39eee6422 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -5590,6 +5590,70 @@ static bool cmp_val_with_extended_s64(s64 sval, struct bpf_reg_state *reg) reg->smax_value <= 0 && reg->smin_value >= S32_MIN); } +/* Constrain the possible values of @reg with unsigned upper bound @bound. + * If @is_exclusive, @bound is an exclusive limit, otherwise it is inclusive. + * If @is_jmp32, @bound is a 32-bit value that only constrains the low 32 bits + * of @reg. + */ +static void set_upper_bound(struct bpf_reg_state *reg, u64 bound, bool is_jmp32, + bool is_exclusive) +{ + if (is_exclusive) { + /* There are no values for `reg` that make `reg<0` true. */ + if (bound == 0) + return; + bound--; + } + if (is_jmp32) { + /* Constrain the register's value in the tnum representation. + * For 64-bit comparisons this happens later in + * __reg_bound_offset(), but for 32-bit comparisons, we can be + * more precise than what can be derived from the updated + * numeric bounds. + */ + struct tnum t = tnum_range(0, bound); + + t.mask |= ~0xffffffffULL; /* upper half is unknown */ + reg->var_off = tnum_intersect(reg->var_off, t); + + /* Compute the 64-bit bound from the 32-bit bound. */ + bound += gen_hi_max(reg->var_off); + } + reg->umax_value = min(reg->umax_value, bound); +} + +/* Constrain the possible values of @reg with unsigned lower bound @bound. + * If @is_exclusive, @bound is an exclusive limit, otherwise it is inclusive. + * If @is_jmp32, @bound is a 32-bit value that only constrains the low 32 bits + * of @reg. + */ +static void set_lower_bound(struct bpf_reg_state *reg, u64 bound, bool is_jmp32, + bool is_exclusive) +{ + if (is_exclusive) { + /* There are no values for `reg` that make `reg>MAX` true. */ + if (bound == (is_jmp32 ? U32_MAX : U64_MAX)) + return; + bound++; + } + if (is_jmp32) { + /* Constrain the register's value in the tnum representation. + * For 64-bit comparisons this happens later in + * __reg_bound_offset(), but for 32-bit comparisons, we can be + * more precise than what can be derived from the updated + * numeric bounds. + */ + struct tnum t = tnum_range(bound, U32_MAX); + + t.mask |= ~0xffffffffULL; /* upper half is unknown */ + reg->var_off = tnum_intersect(reg->var_off, t); + + /* Compute the 64-bit bound from the 32-bit bound. */ + bound += gen_hi_min(reg->var_off); + } + reg->umin_value = max(reg->umin_value, bound); +} + /* Adjusts the register min/max values in the case that the dst_reg is the * variable register that we are working on, and src_reg is a constant or we're * simply doing a BPF_K check. @@ -5645,15 +5709,8 @@ static void reg_set_min_max(struct bpf_reg_state *true_reg, case BPF_JGE: case BPF_JGT: { - u64 false_umax = opcode == BPF_JGT ? val : val - 1; - u64 true_umin = opcode == BPF_JGT ? val + 1 : val; - - if (is_jmp32) { - false_umax += gen_hi_max(false_reg->var_off); - true_umin += gen_hi_min(true_reg->var_off); - } - false_reg->umax_value = min(false_reg->umax_value, false_umax); - true_reg->umin_value = max(true_reg->umin_value, true_umin); + set_upper_bound(false_reg, val, is_jmp32, opcode == BPF_JGE); + set_lower_bound(true_reg, val, is_jmp32, opcode == BPF_JGT); break; } case BPF_JSGE: @@ -5674,15 +5731,8 @@ static void reg_set_min_max(struct bpf_reg_state *true_reg, case BPF_JLE: case BPF_JLT: { - u64 false_umin = opcode == BPF_JLT ? val : val + 1; - u64 true_umax = opcode == BPF_JLT ? val - 1 : val; - - if (is_jmp32) { - false_umin += gen_hi_min(false_reg->var_off); - true_umax += gen_hi_max(true_reg->var_off); - } - false_reg->umin_value = max(false_reg->umin_value, false_umin); - true_reg->umax_value = min(true_reg->umax_value, true_umax); + set_lower_bound(false_reg, val, is_jmp32, opcode == BPF_JLE); + set_upper_bound(true_reg, val, is_jmp32, opcode == BPF_JLT); break; } case BPF_JSLE: @@ -5757,15 +5807,8 @@ static void reg_set_min_max_inv(struct bpf_reg_state *true_reg, case BPF_JGE: case BPF_JGT: { - u64 false_umin = opcode == BPF_JGT ? val : val + 1; - u64 true_umax = opcode == BPF_JGT ? val - 1 : val; - - if (is_jmp32) { - false_umin += gen_hi_min(false_reg->var_off); - true_umax += gen_hi_max(true_reg->var_off); - } - false_reg->umin_value = max(false_reg->umin_value, false_umin); - true_reg->umax_value = min(true_reg->umax_value, true_umax); + set_lower_bound(false_reg, val, is_jmp32, opcode == BPF_JGE); + set_upper_bound(true_reg, val, is_jmp32, opcode == BPF_JGT); break; } case BPF_JSGE: @@ -5783,15 +5826,8 @@ static void reg_set_min_max_inv(struct bpf_reg_state *true_reg, case BPF_JLE: case BPF_JLT: { - u64 false_umax = opcode == BPF_JLT ? val : val - 1; - u64 true_umin = opcode == BPF_JLT ? val + 1 : val; - - if (is_jmp32) { - false_umax += gen_hi_max(false_reg->var_off); - true_umin += gen_hi_min(true_reg->var_off); - } - false_reg->umax_value = min(false_reg->umax_value, false_umax); - true_reg->umin_value = max(true_reg->umin_value, true_umin); + set_upper_bound(false_reg, val, is_jmp32, opcode == BPF_JLE); + set_lower_bound(true_reg, val, is_jmp32, opcode == BPF_JLT); break; } case BPF_JSLE: From patchwork Tue Apr 7 10:22:11 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228134 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4444C2BB1D for ; Tue, 7 Apr 2020 10:32:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 91DD0206F7 for ; Tue, 7 Apr 2020 10:32:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255561; bh=EaD1Kn8VYLmOGXzmva1zo3k7Zh6m00qrt36XnH0ewDc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=ErikXTJqeNqvMrFAygGpDQFpTJxKChGmbCLH8sPIfRUndClFylmuhHelGRQovFvQl 1waEJMy/oJzpqEGllHrRkvc8n6TwOEhW093tFcmungwT2WjFC5X5yHhQunHSSR2blW izJ8zQv6kpLyYz6i9yQqW2OOKrtLu9Zp6TXBs51Y= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728023AbgDGKcl (ORCPT ); Tue, 7 Apr 2020 06:32:41 -0400 Received: from mail.kernel.org ([198.145.29.99]:42826 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727994AbgDGKcl (ORCPT ); Tue, 7 Apr 2020 06:32:41 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 BE64120644; Tue, 7 Apr 2020 10:32:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255560; bh=EaD1Kn8VYLmOGXzmva1zo3k7Zh6m00qrt36XnH0ewDc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vA99e8UPNHYo3pYUYHDTE7eQ97fLq0UkdmEul5qO+W+/A5dsd3rL+D5x3dml2XvM5 pOEkwFVqEosxXA2U928ZlzIgu7rh9utz8EOLNwmOkJqQUyQkQQG1Xi8aijN1Vctnsp Zmk/gPepk5R6DwBQpraJ3diS2Wh7OK5Ml4yvQEUc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?utf-8?q?Ville_Syrj=C3=A4?= , Maarten Lankhorst , Kai Vehmanen , "Souza, Jose" , Uma Shankar , SweeAun Khor , Rodrigo Vivi , Giacomo Comes Subject: [PATCH 5.6 14/29] drm/i915/display: Fix mode private_flags comparison at atomic_check Date: Tue, 7 Apr 2020 12:22:11 +0200 Message-Id: <20200407101453.730127410@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101452.046058399@linuxfoundation.org> References: <20200407101452.046058399@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Uma Shankar commit 2bdd4c28baff29163808677a70942de2b45f17dc upstream. This patch fixes the private_flags of mode to be checked and compared against uapi.mode and not from hw.mode. This helps properly trigger modeset at boot if desired by driver. It helps resolve audio_codec initialization issues if display is connected at boot. Initial discussion on this issue has happened on below thread: https://patchwork.freedesktop.org/series/74828/ v2: No functional change. Fixed the Closes tag and added Maarten's RB. v3: Added Fixes tag. Cc: Ville Syrjä Cc: Maarten Lankhorst Cc: Kai Vehmanen Cc: Souza, Jose Fixes: 58d124ea2739 ("drm/i915: Complete crtc hw/uapi split, v6.") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1363 Suggested-by: Ville Syrjä Signed-off-by: Uma Shankar Signed-off-by: SweeAun Khor Reviewed-by: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/20200326125111.11081-1-uma.shankar@intel.com (cherry picked from commit d5e56705927e00f703b2eb5a98299dd6622d16e5) Signed-off-by: Rodrigo Vivi Cc: Giacomo Comes Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/i915/display/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -14582,8 +14582,8 @@ static int intel_atomic_check(struct drm /* Catch I915_MODE_FLAG_INHERITED */ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) { - if (new_crtc_state->hw.mode.private_flags != - old_crtc_state->hw.mode.private_flags) + if (new_crtc_state->uapi.mode.private_flags != + old_crtc_state->uapi.mode.private_flags) new_crtc_state->uapi.mode_changed = true; } From patchwork Tue Apr 7 10:22:13 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228167 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49043C2BB55 for ; Tue, 7 Apr 2020 10:26:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0DA8B2080C for ; Tue, 7 Apr 2020 10:26:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255183; bh=khVOaY2ujlcX/REye0ztyWAGD+5eMAaXklsRDjNbiUc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=KauEu3TySWRPgW6aSd3DLkZHxtc+To2H74OuCH5iP4h3WqW2QRT/G5RqL5YBg1ElV JZ+VGh0P5IjnMFf7zkMXECYRYOFFogSfajhW772a7TuGP4Rh1ayGQ4SpsXUJxjEZAJ Ym/hqUzpTn0IDhUuOD2sKLEsgDi8sFNwK92fGgzE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729128AbgDGK0W (ORCPT ); Tue, 7 Apr 2020 06:26:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:38120 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728774AbgDGK0V (ORCPT ); Tue, 7 Apr 2020 06:26:21 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 44D1F2074F; Tue, 7 Apr 2020 10:26:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255180; bh=khVOaY2ujlcX/REye0ztyWAGD+5eMAaXklsRDjNbiUc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XBj3AjEee1fSUyWTTYrXgtV+Dm0vunFUmwZoaYqilnImlZb4DYjmhYRWgN7Al8dnp nCop/yf8CMaND/vKBwjin4Ok9qoKH1AIc5Dbn9stem01qpBsxZDvhlb7CCl84wsK99 s+Z14Ane/YfnHwdazdzE4RCwNMvfptGeddH4QynE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kishon Vijay Abraham I , Lorenzo Pieralisi Subject: [PATCH 5.6 16/29] misc: pci_endpoint_test: Fix to support > 10 pci-endpoint-test devices Date: Tue, 7 Apr 2020 12:22:13 +0200 Message-Id: <20200407101453.968495514@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101452.046058399@linuxfoundation.org> References: <20200407101452.046058399@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Kishon Vijay Abraham I commit 6b443e5c80b67a7b8a85b33d052d655ef9064e90 upstream. Adding more than 10 pci-endpoint-test devices results in "kobject_add_internal failed for pci-endpoint-test.1 with -EEXIST, don't try to register things with the same name in the same directory". This is because commit 2c156ac71c6b ("misc: Add host side PCI driver for PCI test function device") limited the length of the "name" to 20 characters. Change the length of the name to 24 in order to support upto 10000 pci-endpoint-test devices. Fixes: 2c156ac71c6b ("misc: Add host side PCI driver for PCI test function device") Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Greg Kroah-Hartman --- drivers/misc/pci_endpoint_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/misc/pci_endpoint_test.c +++ b/drivers/misc/pci_endpoint_test.c @@ -633,7 +633,7 @@ static int pci_endpoint_test_probe(struc { int err; int id; - char name[20]; + char name[24]; enum pci_barno bar; void __iomem *base; struct device *dev = &pdev->dev; From patchwork Tue Apr 7 10:22:14 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228157 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0900C2BB54 for ; Tue, 7 Apr 2020 10:27:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7707B2074B for ; Tue, 7 Apr 2020 10:27:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255274; bh=hFSSaaFZs7iS34JeOV/LO3xxtt/qCl6SQ6F3A3HPIlg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=jbEvqUSj8BkMO89/MTIhVc1MyWAONxR4OYg2m/DMhJxWoaEoFM04BtihBeZIJW/M7 THAeWLirQvk3jNjDaJuv9GpC8hWL0xDnaebkp3gIW/RTdN9s8gyI1luxC5MJSyjCn6 ZvDHwQCYk7S6aLpkoC2ugoiVlcXjBmDwYsFVXSps= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729142AbgDGK0Z (ORCPT ); Tue, 7 Apr 2020 06:26:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:38276 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729136AbgDGK0Y (ORCPT ); Tue, 7 Apr 2020 06:26:24 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 BBEA52078A; Tue, 7 Apr 2020 10:26:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255183; bh=hFSSaaFZs7iS34JeOV/LO3xxtt/qCl6SQ6F3A3HPIlg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RvoAJUc/L6kQRRBss0puNyIgYpdBiONBnUy/oTu1ealy1KsmOmuZMc1HGqGrxEVgw yw0l6yXOcRQeVvUoJniPwwaeF896W4affoWZsriff8YS118iXqaL2C+tZ9GY7uqg00 ADbJWH6hnf2BxazsyRuPZrSVYu75y7OqOab/qn2Q= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kishon Vijay Abraham I , Lorenzo Pieralisi Subject: [PATCH 5.6 17/29] misc: pci_endpoint_test: Avoid using module parameter to determine irqtype Date: Tue, 7 Apr 2020 12:22:14 +0200 Message-Id: <20200407101454.099021243@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101452.046058399@linuxfoundation.org> References: <20200407101452.046058399@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Kishon Vijay Abraham I commit b2ba9225e0313b1de631a44b7b48c109032bffec upstream. commit e03327122e2c ("pci_endpoint_test: Add 2 ioctl commands") uses module parameter 'irqtype' in pci_endpoint_test_set_irq() to check if IRQ vectors of a particular type (MSI or MSI-X or LEGACY) is already allocated. However with multi-function devices, 'irqtype' will not correctly reflect the IRQ type of the PCI device. Fix it here by adding 'irqtype' for each PCI device to show the IRQ type of a particular PCI device. Fixes: e03327122e2c ("pci_endpoint_test: Add 2 ioctl commands") Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Greg Kroah-Hartman --- drivers/misc/pci_endpoint_test.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) --- a/drivers/misc/pci_endpoint_test.c +++ b/drivers/misc/pci_endpoint_test.c @@ -98,6 +98,7 @@ struct pci_endpoint_test { struct completion irq_raised; int last_irq; int num_irqs; + int irq_type; /* mutex to protect the ioctls */ struct mutex mutex; struct miscdevice miscdev; @@ -157,6 +158,7 @@ static void pci_endpoint_test_free_irq_v struct pci_dev *pdev = test->pdev; pci_free_irq_vectors(pdev); + test->irq_type = IRQ_TYPE_UNDEFINED; } static bool pci_endpoint_test_alloc_irq_vectors(struct pci_endpoint_test *test, @@ -191,6 +193,8 @@ static bool pci_endpoint_test_alloc_irq_ irq = 0; res = false; } + + test->irq_type = type; test->num_irqs = irq; return res; @@ -330,6 +334,7 @@ static bool pci_endpoint_test_copy(struc dma_addr_t orig_dst_phys_addr; size_t offset; size_t alignment = test->alignment; + int irq_type = test->irq_type; u32 src_crc32; u32 dst_crc32; @@ -426,6 +431,7 @@ static bool pci_endpoint_test_write(stru dma_addr_t orig_phys_addr; size_t offset; size_t alignment = test->alignment; + int irq_type = test->irq_type; u32 crc32; if (size > SIZE_MAX - alignment) @@ -494,6 +500,7 @@ static bool pci_endpoint_test_read(struc dma_addr_t orig_phys_addr; size_t offset; size_t alignment = test->alignment; + int irq_type = test->irq_type; u32 crc32; if (size > SIZE_MAX - alignment) @@ -555,7 +562,7 @@ static bool pci_endpoint_test_set_irq(st return false; } - if (irq_type == req_irq_type) + if (test->irq_type == req_irq_type) return true; pci_endpoint_test_release_irq(test); @@ -567,12 +574,10 @@ static bool pci_endpoint_test_set_irq(st if (!pci_endpoint_test_request_irq(test)) goto err; - irq_type = req_irq_type; return true; err: pci_endpoint_test_free_irq_vectors(test); - irq_type = IRQ_TYPE_UNDEFINED; return false; } @@ -652,6 +657,7 @@ static int pci_endpoint_test_probe(struc test->test_reg_bar = 0; test->alignment = 0; test->pdev = pdev; + test->irq_type = IRQ_TYPE_UNDEFINED; if (no_msi) irq_type = IRQ_TYPE_LEGACY; From patchwork Tue Apr 7 10:22:16 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228166 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C635C2BB54 for ; Tue, 7 Apr 2020 10:26:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1397620644 for ; Tue, 7 Apr 2020 10:26:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255193; bh=AOAvaLVkDHeMRUUOp5dsa0b0RO3eEiCYm6DzGZdjcBU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=0KIHlmhOANuFFkR1bp3LH2BhYBgqEMQe6rhMVbj1jIccTB6IPeeYpnqykjWYz1MUv 92X8LgsAMz8iS7s5FH+PYggGOfBFhLX6uqaA5j/zXurAm/88BqrFnF1UHoxNYWVN+O Lnmv+9h9UnRjPK5ZfxgIebORQFdSqFH4uOsFWe8g= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729159AbgDGK0b (ORCPT ); Tue, 7 Apr 2020 06:26:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:38568 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729157AbgDGK02 (ORCPT ); Tue, 7 Apr 2020 06:26:28 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 9A23D2074F; Tue, 7 Apr 2020 10:26:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255188; bh=AOAvaLVkDHeMRUUOp5dsa0b0RO3eEiCYm6DzGZdjcBU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Lj8GvnwLySwRQOjI36y6ONlUAFAp1kZnxeBe10GLTI7rL5TuQwC7RVhnNLKntL+wv ODcHklJz3ICuzY4goPB75tvVGrqMwbLbqlpNjlEsQSzc4rKPr7KHPzr7VT4xe67XYE DaSIpoSjmywz7y/enLe4xA9NTem79pNgZzxRRfgc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eugene Syromiatnikov , Mathieu Poirier Subject: [PATCH 5.6 19/29] coresight: do not use the BIT() macro in the UAPI header Date: Tue, 7 Apr 2020 12:22:16 +0200 Message-Id: <20200407101454.349819058@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101452.046058399@linuxfoundation.org> References: <20200407101452.046058399@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Eugene Syromiatnikov commit 9b6eaaf3db5e5888df7bca7fed7752a90f7fd871 upstream. The BIT() macro definition is not available for the UAPI headers (moreover, it can be defined differently in the user space); replace its usage with the _BITUL() macro that is defined in . Fixes: 237483aa5cf4 ("coresight: stm: adding driver for CoreSight STM component") Signed-off-by: Eugene Syromiatnikov Cc: stable Reviewed-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200324042213.GA10452@asgard.redhat.com Signed-off-by: Greg Kroah-Hartman --- include/uapi/linux/coresight-stm.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/include/uapi/linux/coresight-stm.h +++ b/include/uapi/linux/coresight-stm.h @@ -2,8 +2,10 @@ #ifndef __UAPI_CORESIGHT_STM_H_ #define __UAPI_CORESIGHT_STM_H_ -#define STM_FLAG_TIMESTAMPED BIT(3) -#define STM_FLAG_GUARANTEED BIT(7) +#include + +#define STM_FLAG_TIMESTAMPED _BITUL(3) +#define STM_FLAG_GUARANTEED _BITUL(7) /* * The CoreSight STM supports guaranteed and invariant timing From patchwork Tue Apr 7 10:22:17 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228158 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 009EAC2BB85 for ; Tue, 7 Apr 2020 10:27:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C2AF22074B for ; Tue, 7 Apr 2020 10:27:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255268; bh=TcTIBYPO0IsFQBu/ex/IOcdF3ZlY9TxybumNre7+ifU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=0yXjH3M0Yl/Lq0rCHuHr4Ua+fvpeRV3Rllsmo7OqF8pq4eilO001UJhxbpsp1OP9a r0kdxAZ5JnnTTlKhEsyFFVQ0N8OaqYDRXLt3QZ0UoagP3NrREn0S8/fnt2pKsBxKA7 PDKy1lWOc+YS+GVxCvZEmv6RfA6QqJdufo41wjA8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729174AbgDGK0e (ORCPT ); Tue, 7 Apr 2020 06:26:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:38686 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729173AbgDGK0d (ORCPT ); Tue, 7 Apr 2020 06:26:33 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 8460F2074B; Tue, 7 Apr 2020 10:26:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255193; bh=TcTIBYPO0IsFQBu/ex/IOcdF3ZlY9TxybumNre7+ifU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uIHLE0t6VNwkNaVlmvJg9G3N85y5TYY2oZlMxNhwyuLaBPqB/M6D2eJcDYc0LawjA Ks2XYE8qoEZ7NSOROrmCpvnjqhOsiLuSMmhnpbIeY8DG6cY65TKA5rhlOsrusp1k19 Q0KndsAw+v6tX9SPYbIgbVn+GCO7Ewi7unm49E/w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alexander Usyskin , Tomas Winkler Subject: [PATCH 5.6 20/29] mei: me: add cedar fork device ids Date: Tue, 7 Apr 2020 12:22:17 +0200 Message-Id: <20200407101454.505697498@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101452.046058399@linuxfoundation.org> References: <20200407101452.046058399@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Alexander Usyskin commit 99397d33b763dc554d118aaa38cc5abc6ce985de upstream. Add Cedar Fork (CDF) device ids, those belongs to the cannon point family. Cc: Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20200324210730.17672-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman --- drivers/misc/mei/hw-me-regs.h | 2 ++ drivers/misc/mei/pci-me.c | 2 ++ 2 files changed, 4 insertions(+) --- a/drivers/misc/mei/hw-me-regs.h +++ b/drivers/misc/mei/hw-me-regs.h @@ -87,6 +87,8 @@ #define MEI_DEV_ID_CMP_H 0x06e0 /* Comet Lake H */ #define MEI_DEV_ID_CMP_H_3 0x06e4 /* Comet Lake H 3 (iTouch) */ +#define MEI_DEV_ID_CDF 0x18D3 /* Cedar Fork */ + #define MEI_DEV_ID_ICP_LP 0x34E0 /* Ice Lake Point LP */ #define MEI_DEV_ID_JSP_N 0x4DE0 /* Jasper Lake Point N */ --- a/drivers/misc/mei/pci-me.c +++ b/drivers/misc/mei/pci-me.c @@ -111,6 +111,8 @@ static const struct pci_device_id mei_me {MEI_PCI_DEVICE(MEI_DEV_ID_MCC, MEI_ME_PCH15_CFG)}, {MEI_PCI_DEVICE(MEI_DEV_ID_MCC_4, MEI_ME_PCH8_CFG)}, + {MEI_PCI_DEVICE(MEI_DEV_ID_CDF, MEI_ME_PCH8_CFG)}, + /* required last entry */ {0, } }; From patchwork Tue Apr 7 10:22:19 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228159 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E817C2BB1D for ; Tue, 7 Apr 2020 10:27:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2B61A2074B for ; Tue, 7 Apr 2020 10:27:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255267; bh=TorpH4uEST+U3yxKOkCZL/m53n9xz2lDBNqCEdKUsyA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=mx6NcCTDcadMS+l42ISIRhJoFy+ww/sGzSZmPOuKsW3sGvBazfXrgPgVVcFrxUHEK IlpTBc39LwEQzfTEPpyLt10Qg8VU5VQFjeceiNNGXsIxcN2D+Vg4k9IZnn6hKAuuyr UXgMs/WZu7pp2Zo7LEPswD+DUNodePPC+wWtmvxw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729190AbgDGK0k (ORCPT ); Tue, 7 Apr 2020 06:26:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:38828 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729187AbgDGK0i (ORCPT ); Tue, 7 Apr 2020 06:26:38 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 6B79F2074F; Tue, 7 Apr 2020 10:26:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255197; bh=TorpH4uEST+U3yxKOkCZL/m53n9xz2lDBNqCEdKUsyA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1jiPTpMzHDbG7C2TyPedRaBPxNc+MC9WjyHr1Q8mb3UC/FTp48MaFHFeG55FobEV9 PnmLpGdHZZKbIhA95b27iOCm5eHQXo+j1873zCvB7hTiLntcgvyVtH/NCZeieD7lta PSxLkwjWRyoQhbpshT46QFA/UY/v0F7J9xbMOq/w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicholas Johnson , Srinivas Kandagatla Subject: [PATCH 5.6 22/29] nvmem: check for NULL reg_read and reg_write before dereferencing Date: Tue, 7 Apr 2020 12:22:19 +0200 Message-Id: <20200407101454.761010846@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101452.046058399@linuxfoundation.org> References: <20200407101452.046058399@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Nicholas Johnson commit 3c91ef69a3e94f78546b246225ed573fbf1735b4 upstream. Return -EPERM if reg_read is NULL in bin_attr_nvmem_read() or if reg_write is NULL in bin_attr_nvmem_write(). This prevents NULL dereferences such as the one described in 03cd45d2e219 ("thunderbolt: Prevent crash if non-active NVMem file is read") Signed-off-by: Nicholas Johnson Cc: stable Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200310132257.23358-10-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman --- drivers/nvmem/nvmem-sysfs.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/nvmem/nvmem-sysfs.c +++ b/drivers/nvmem/nvmem-sysfs.c @@ -56,6 +56,9 @@ static ssize_t bin_attr_nvmem_read(struc count = round_down(count, nvmem->word_size); + if (!nvmem->reg_read) + return -EPERM; + rc = nvmem->reg_read(nvmem->priv, pos, buf, count); if (rc) @@ -90,6 +93,9 @@ static ssize_t bin_attr_nvmem_write(stru count = round_down(count, nvmem->word_size); + if (!nvmem->reg_write) + return -EPERM; + rc = nvmem->reg_write(nvmem->priv, pos, buf, count); if (rc) From patchwork Tue Apr 7 10:22:21 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228160 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2CDCCC2BB85 for ; Tue, 7 Apr 2020 10:27:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 037732080C for ; Tue, 7 Apr 2020 10:27:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255263; bh=h2kS5Qz/xwausVLpxQPYmK+Zqwh3u5tCcA85lqQVuNo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=KoqzGX5FsIznZqXhw7K9yA1lvOVqiuN7lE0eAsadEzzKi0YgvzNuMx/offGbZGX8u SEQu6KgMwB8vtYDn+10mLLukA+6Df6AqNakQ72KUc2jpv3oIajpLeJ/D9ZT3fL1ZyS DZox0iBdW4M4tLHrZea9CXAq22XrJbfTv6miULjM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728301AbgDGK0o (ORCPT ); Tue, 7 Apr 2020 06:26:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:38910 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728645AbgDGK0n (ORCPT ); Tue, 7 Apr 2020 06:26:43 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 5A1F420644; Tue, 7 Apr 2020 10:26:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255202; bh=h2kS5Qz/xwausVLpxQPYmK+Zqwh3u5tCcA85lqQVuNo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XSJMjtvfpKJKFP9Glmi4p5PCHp39F8W0g/paXkIaWBR+9CnqDnLmArXlayRuR5Ogj YF9k5WGdg/CRqU0CojUYg7ILmZCAx46yEFfgnOL6FZZGbOq543eb6ZcKLrQyIejVlb hixBCufh8y7hNN3gdW/RtZfYpN2C4Orlp+UIKW3M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hans de Goede , Chanwoo Choi Subject: [PATCH 5.6 24/29] extcon: axp288: Add wakeup support Date: Tue, 7 Apr 2020 12:22:21 +0200 Message-Id: <20200407101455.026177621@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101452.046058399@linuxfoundation.org> References: <20200407101452.046058399@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Hans de Goede commit 9c94553099efb2ba873cbdddfd416a8a09d0e5f1 upstream. On devices with an AXP288, we need to wakeup from suspend when a charger is plugged in, so that we can do charger-type detection and so that the axp288-charger driver, which listens for our extcon events, can configure the input-current-limit accordingly. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman --- drivers/extcon/extcon-axp288.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) --- a/drivers/extcon/extcon-axp288.c +++ b/drivers/extcon/extcon-axp288.c @@ -443,9 +443,40 @@ static int axp288_extcon_probe(struct pl /* Start charger cable type detection */ axp288_extcon_enable(info); + device_init_wakeup(dev, true); + platform_set_drvdata(pdev, info); + + return 0; +} + +static int __maybe_unused axp288_extcon_suspend(struct device *dev) +{ + struct axp288_extcon_info *info = dev_get_drvdata(dev); + + if (device_may_wakeup(dev)) + enable_irq_wake(info->irq[VBUS_RISING_IRQ]); + return 0; } +static int __maybe_unused axp288_extcon_resume(struct device *dev) +{ + struct axp288_extcon_info *info = dev_get_drvdata(dev); + + /* + * Wakeup when a charger is connected to do charger-type + * connection and generate an extcon event which makes the + * axp288 charger driver set the input current limit. + */ + if (device_may_wakeup(dev)) + disable_irq_wake(info->irq[VBUS_RISING_IRQ]); + + return 0; +} + +static SIMPLE_DEV_PM_OPS(axp288_extcon_pm_ops, axp288_extcon_suspend, + axp288_extcon_resume); + static const struct platform_device_id axp288_extcon_table[] = { { .name = "axp288_extcon" }, {}, @@ -457,6 +488,7 @@ static struct platform_driver axp288_ext .id_table = axp288_extcon_table, .driver = { .name = "axp288_extcon", + .pm = &axp288_extcon_pm_ops, }, }; From patchwork Tue Apr 7 10:22:22 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228165 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A59F7C2BB55 for ; Tue, 7 Apr 2020 10:27:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 74AF52074B for ; Tue, 7 Apr 2020 10:27:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255241; bh=4pHLwaftfoue1jLFWgtZnNla0KEbD+Y0nes/UYDUXW8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=2aLdQFXgmdZg3p/SJZHCiKhVJL2H6ZPRex0um2Nwt85YOxcU9rSU47LaTK2EFAdn6 CpbbY2VPLrYnSvdDeNO2nxoUu8YbGsnt47fPUaNX1a6ih5ZJX2XoZw5CLGhuci/A9B dgAv6d7Q4Ayt32bmDNVZVMirVcXZ2JoBVoPsNS1Y= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728812AbgDGK1Q (ORCPT ); Tue, 7 Apr 2020 06:27:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:39624 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729279AbgDGK1P (ORCPT ); Tue, 7 Apr 2020 06:27:15 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 1CBC520771; Tue, 7 Apr 2020 10:27:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255234; bh=4pHLwaftfoue1jLFWgtZnNla0KEbD+Y0nes/UYDUXW8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LoOMLdHMy7kpkggzVxoOdHsCXVQGfQy2itM1swt1nR1pWuHsn4c6C/oz26ymI++au 9RWeWAF4p0xKY4hvyykSxgWAdYBbVGHto5kwp/d5YY6dl5lrWQBOlarKDIUJxeh4HT zQDgAf45tO1c9LBfkOjp4KFJLcS2kDgWWsqlwFmA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hans de Goede , Sebastian Reichel Subject: [PATCH 5.6 25/29] power: supply: axp288_charger: Add special handling for HP Pavilion x2 10 Date: Tue, 7 Apr 2020 12:22:22 +0200 Message-Id: <20200407101455.145574924@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101452.046058399@linuxfoundation.org> References: <20200407101452.046058399@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Hans de Goede commit 9c80662a74cd2a5d1113f5c69d027face963a556 upstream. Some HP Pavilion x2 10 models use an AXP288 for charging and fuel-gauge. We use a native power_supply / PMIC driver in this case, because on most models with an AXP288 the ACPI AC / Battery code is either completely missing or relies on custom / proprietary ACPI OpRegions which Linux does not implement. The native drivers mostly work fine, but there are 2 problems: 1. These model uses a Type-C connector for charging which the AXP288 does not support. As long as a Type-A charger (which uses the USB data pins for charger type detection) is used everything is fine. But if a Type-C charger is used (such as the charger shipped with the device) then the charger is not recognized. So we end up slowly discharging the device even though a charger is connected, because we are limiting the current from the charger to 500mA. To make things worse this happens with the device's official charger. Looking at the ACPI tables HP has "solved" the problem of the AXP288 not being able to recognize Type-C chargers by simply always programming the input-current-limit at 3000mA and relying on a Vhold setting of 4.7V (normally 4.4V) to limit the current intake if the charger cannot handle this. 2. If no charger is connected when the machine boots then it boots with the vbus-path disabled. On other devices this is done when a 5V boost converter is active to avoid the PMIC trying to charge from the 5V boost output. This is done when an OTG host cable is inserted and the ID pin on the micro-B receptacle is pulled low, the ID pin has an ACPI event handler associated with it which re-enables the vbus-path when the ID pin is pulled high when the OTG cable is removed. The Type-C connector has no ID pin, there is no ID pin handler and there appears to be no 5V boost converter, so we end up not charging because the vbus-path is disabled, until we unplug the charger which automatically clears the vbus-path disable bit and then on the second plug-in of the adapter we start charging. The HP Pavilion x2 10 models with an AXP288 do have mostly working ACPI AC / Battery code which does not rely on custom / proprietary ACPI OpRegions. So one possible solution would be to blacklist the AXP288 native power_supply drivers and add the HP Pavilion x2 10 with AXP288 DMI ids to the list of devices which should use the ACPI AC / Battery code even though they have an AXP288 PMIC. This would require changes to 4 files: drivers/acpi/ac.c, drivers/power/supply/axp288_charger.c, drivers/acpi/battery.c and drivers/power/supply/axp288_fuel_gauge.c. Beside needing adding the same DMI matches to 4 different files, this approach also triggers problem 2. from above, but then when suspended, during suspend the machine will not wakeup because the vbus path is disabled by the AML code when not charging, so the Vbus low-to-high IRQ is not triggered, the CPU never wakes up and the device does not charge even though the user likely things it is charging, esp. since the charge status LED is directly coupled to an adapter being plugged in and does not reflect actual charging. This could be worked by enabling vbus-path explicitly from say the axp288_charger driver's suspend handler. So neither situation is ideal, in both cased we need to explicitly enable the vbus-path to work around different variants of problem 2 above, this requires a quirk in the axp288_charger code. If we go the route of using the ACPI AC / Battery drivers then we need modifications to 3 other drivers; and we need to partially disable the axp288_charger code, while at the same time keeping it around to enable vbus-path on suspend. OTOH we can copy the hardcoding of 3A input-current-limit (we never touch Vhold, so that would stay at 4.7V) to the axp288_charger code, which needs changes regardless, then we concentrate all special handling of this interesting device model in the axp288_charger code. That is what this commit does. Cc: stable@vger.kernel.org BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1791098 Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman --- drivers/power/supply/axp288_charger.c | 57 +++++++++++++++++++++++++++++++++- 1 file changed, 56 insertions(+), 1 deletion(-) --- a/drivers/power/supply/axp288_charger.c +++ b/drivers/power/supply/axp288_charger.c @@ -21,6 +21,7 @@ #include #include #include +#include #define PS_STAT_VBUS_TRIGGER BIT(0) #define PS_STAT_BAT_CHRG_DIR BIT(2) @@ -545,6 +546,49 @@ out: return IRQ_HANDLED; } +/* + * The HP Pavilion x2 10 series comes in a number of variants: + * Bay Trail SoC + AXP288 PMIC, DMI_BOARD_NAME: "815D" + * Cherry Trail SoC + AXP288 PMIC, DMI_BOARD_NAME: "813E" + * Cherry Trail SoC + TI PMIC, DMI_BOARD_NAME: "827C" or "82F4" + * + * The variants with the AXP288 PMIC are all kinds of special: + * + * 1. All variants use a Type-C connector which the AXP288 does not support, so + * when using a Type-C charger it is not recognized. Unlike most AXP288 devices, + * this model actually has mostly working ACPI AC / Battery code, the ACPI code + * "solves" this by simply setting the input_current_limit to 3A. + * There are still some issues with the ACPI code, so we use this native driver, + * and to solve the charging not working (500mA is not enough) issue we hardcode + * the 3A input_current_limit like the ACPI code does. + * + * 2. If no charger is connected the machine boots with the vbus-path disabled. + * Normally this is done when a 5V boost converter is active to avoid the PMIC + * trying to charge from the 5V boost converter's output. This is done when + * an OTG host cable is inserted and the ID pin on the micro-B receptacle is + * pulled low and the ID pin has an ACPI event handler associated with it + * which re-enables the vbus-path when the ID pin is pulled high when the + * OTG host cable is removed. The Type-C connector has no ID pin, there is + * no ID pin handler and there appears to be no 5V boost converter, so we + * end up not charging because the vbus-path is disabled, until we unplug + * the charger which automatically clears the vbus-path disable bit and then + * on the second plug-in of the adapter we start charging. To solve the not + * charging on first charger plugin we unconditionally enable the vbus-path at + * probe on this model, which is safe since there is no 5V boost converter. + */ +static const struct dmi_system_id axp288_hp_x2_dmi_ids[] = { + { + /* + * Bay Trail model has "Hewlett-Packard" as sys_vendor, Cherry + * Trail model has "HP", so we only match on product_name. + */ + .matches = { + DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion x2 Detachable"), + }, + }, + {} /* Terminating entry */ +}; + static void axp288_charger_extcon_evt_worker(struct work_struct *work) { struct axp288_chrg_info *info = @@ -568,7 +612,11 @@ static void axp288_charger_extcon_evt_wo } /* Determine cable/charger type */ - if (extcon_get_state(edev, EXTCON_CHG_USB_SDP) > 0) { + if (dmi_check_system(axp288_hp_x2_dmi_ids)) { + /* See comment above axp288_hp_x2_dmi_ids declaration */ + dev_dbg(&info->pdev->dev, "HP X2 with Type-C, setting inlmt to 3A\n"); + current_limit = 3000000; + } else if (extcon_get_state(edev, EXTCON_CHG_USB_SDP) > 0) { dev_dbg(&info->pdev->dev, "USB SDP charger is connected\n"); current_limit = 500000; } else if (extcon_get_state(edev, EXTCON_CHG_USB_CDP) > 0) { @@ -685,6 +733,13 @@ static int charger_init_hw_regs(struct a return ret; } + if (dmi_check_system(axp288_hp_x2_dmi_ids)) { + /* See comment above axp288_hp_x2_dmi_ids declaration */ + ret = axp288_charger_vbus_path_select(info, true); + if (ret < 0) + return ret; + } + /* Read current charge voltage and current limit */ ret = regmap_read(info->regmap, AXP20X_CHRG_CTRL1, &val); if (ret < 0) { From patchwork Tue Apr 7 10:22:23 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "gregkh@linuxfoundation.org" X-Patchwork-Id: 228164 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49C2BC2BB1D for ; Tue, 7 Apr 2020 10:27:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 14E1E2074B for ; Tue, 7 Apr 2020 10:27:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255247; bh=7d/wJqUuz5hIfd5ZLbF0o2zPbMj1oDOeQJTFbf3ygB8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=hLVxBmdmROdOpHk62D5uQUJXX20gibmQMbPvid5Gtom4XQGYwKYHQ/3jogzt4EcV0 cXO0w0qCwiNo9HMZVFKIvCW3rHBpSLfH1X+J/uPA4gF1jCkysRL2o16tNUje6XflzX y3N6YaMLNaugpq6beKA95/N+N52fud/DoBXWZayw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728378AbgDGK1I (ORCPT ); Tue, 7 Apr 2020 06:27:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:39432 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729279AbgDGK1F (ORCPT ); Tue, 7 Apr 2020 06:27:05 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 5CF772078A; Tue, 7 Apr 2020 10:27:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586255224; bh=7d/wJqUuz5hIfd5ZLbF0o2zPbMj1oDOeQJTFbf3ygB8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vbGfCIqEdCD9oLndXrXQGpjWMO1fh626n1j86oBsTDsG3IXbHK3qJ7PiG2ySvY8JJ GN7G4hnirqOW324nWv71ZEE7rVwR7/aRsiuPOGwRY0HIc10WjL1X4pxMtFxIvONtNJ yrw+vvzTYn1nkxLm5mUxj/0RoT+Nh8OtrrSCSs8I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Dmitry V. Levin" , Takashi Iwai Subject: [PATCH 5.6 26/29] Revert "ALSA: uapi: Drop asound.h inclusion from asoc.h" Date: Tue, 7 Apr 2020 12:22:23 +0200 Message-Id: <20200407101455.292977095@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200407101452.046058399@linuxfoundation.org> References: <20200407101452.046058399@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Takashi Iwai commit b6f69c795547f59ddf1db17cddbd2b9a15c656ed upstream. This reverts commit 645c08f17f477915f6d900b767e789852f150054 which was reported to break the build a program using this header. The original issue was addressed in the alsa-lib side recently, so we can make the header more self-contained again. Reported-by: Dmitry V. Levin Fixes: 645c08f17f47 ("ALSA: uapi: Drop asound.h inclusion from asoc.h") Cc: Link: https://lore.kernel.org/r/20200331090023.8112-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- include/uapi/sound/asoc.h | 1 + 1 file changed, 1 insertion(+) --- a/include/uapi/sound/asoc.h +++ b/include/uapi/sound/asoc.h @@ -17,6 +17,7 @@ #define __LINUX_UAPI_SND_ASOC_H #include +#include /* * Maximum number of channels topology kcontrol can represent.