From patchwork Sat Apr 11 12:08:44 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228002 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.8 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,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 DE0EBC2BA2B for ; Sat, 11 Apr 2020 12:27:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B22E9206A1 for ; Sat, 11 Apr 2020 12:27:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586608022; bh=8b6+SjPVlptKlpHpNs5BryqjkHoJs5ngMdVdKcZM1GY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=2bY7FtQYP65ymYSpqeR9OowBdRmnXwobExqNMZS2MtSCoR89rZrYaPWtB6EOCMQCs 7lOiGGa006t1ydPYZagLKJFTpjmGl/5YUgzWg6QIVhmWdtuFMAbLv4K9q15oWyMCia CguYI9PIa8+5V2naPTTgz5jGnqdutEZE+moqUnHA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727318AbgDKMO4 (ORCPT ); Sat, 11 Apr 2020 08:14:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:48562 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728071AbgDKMO4 (ORCPT ); Sat, 11 Apr 2020 08:14:56 -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 948FB20692; Sat, 11 Apr 2020 12:14:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607296; bh=8b6+SjPVlptKlpHpNs5BryqjkHoJs5ngMdVdKcZM1GY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1BWoeEP1xOygfCK05mERky7PtEt+B3iRqVlmQjcg09/6O5YXajAmLjR+VXF1+Z/3l BM68wl4gb7DeU+pITjnXdMskZ+jNcqqPoPMZl2vnLE0j0WFN4h11+UvB5lWqHUqKTw y0yGQxyjkHoxdJFIqFVN8Lv0eq/UB++o+PjXMpwk= 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 4.19 02/54] net, ip_tunnel: fix interface lookup with no key Date: Sat, 11 Apr 2020 14:08:44 +0200 Message-Id: <20200411115508.488143371@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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 @@ -155,11 +155,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)) @@ -171,7 +168,6 @@ struct ip_tunnel *ip_tunnel_lookup(struc cand = t; } -skip_key_lookup: if (cand) return cand; From patchwork Sat Apr 11 12:08:47 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228003 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.8 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, 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 5AF28C2BA2B for ; Sat, 11 Apr 2020 12:26:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 31B912084D for ; Sat, 11 Apr 2020 12:26:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586608017; bh=JZq8dE2HemhgAxsq2NlZiZMCv5IuL2FpwL7FfIstci0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=NV+k0X6k16IJGCJvw0b9WtWQrdkAIu6qjr6zrXn/wQn+ty98d0FgrqnxdeTvvDEky TSgS3obo0tVMFhcE6v3lxW1UlABj7ihOStAPrwzkvk/eUWfAr8cOpe+2J/gTaX+leN mWTTQijcVNCvP2ReKul8kW8ZUoUYHimy2It+1d/w= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726964AbgDKMPE (ORCPT ); Sat, 11 Apr 2020 08:15:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:48776 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726713AbgDKMPE (ORCPT ); Sat, 11 Apr 2020 08:15:04 -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 CDE1120787; Sat, 11 Apr 2020 12:15:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607303; bh=JZq8dE2HemhgAxsq2NlZiZMCv5IuL2FpwL7FfIstci0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U/FexROFfZiScO1hssSr0+G3nzNDcKbOPwfCuKSHazym7Sj09vpf7yXwC7tWF47xq VLBK1OxUq629t0wB14qOgUY4eWnxJq50jsCYT403B0NI6wPRjbtHhkPrzrgqVV0jOi IcXzPMskIycGItjZ1rOVRLU5qZBOUszUh+ax0YFo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Roland Dreier , Max Gurtovoy , Christoph Hellwig , Prabhath Sajeepa , Keith Busch , Sasha Levin Subject: [PATCH 4.19 05/54] nvme-rdma: Avoid double freeing of async event data Date: Sat, 11 Apr 2020 14:08:47 +0200 Message-Id: <20200411115508.766563409@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Prabhath Sajeepa [ Upstream commit 9134ae2a2546cb96abddcd4469a79c77ee3a4480 ] The timeout of identify cmd, which is invoked as part of admin queue creation, can result in freeing of async event data both in nvme_rdma_timeout handler and error handling path of nvme_rdma_configure_admin queue thus causing NULL pointer reference. Call Trace: ? nvme_rdma_setup_ctrl+0x223/0x800 [nvme_rdma] nvme_rdma_create_ctrl+0x2ba/0x3f7 [nvme_rdma] nvmf_dev_write+0xa54/0xcc6 [nvme_fabrics] __vfs_write+0x1b/0x40 vfs_write+0xb2/0x1b0 ksys_write+0x61/0xd0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x60/0x1e0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reviewed-by: Roland Dreier Reviewed-by: Max Gurtovoy Reviewed-by: Christoph Hellwig Signed-off-by: Prabhath Sajeepa Signed-off-by: Keith Busch Signed-off-by: Sasha Levin --- drivers/nvme/host/rdma.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c index e4f167e35353f..9711bfbdf4316 100644 --- a/drivers/nvme/host/rdma.c +++ b/drivers/nvme/host/rdma.c @@ -815,9 +815,11 @@ out_free_tagset: if (new) nvme_rdma_free_tagset(&ctrl->ctrl, ctrl->ctrl.admin_tagset); out_free_async_qe: - nvme_rdma_free_qe(ctrl->device->dev, &ctrl->async_event_sqe, - sizeof(struct nvme_command), DMA_TO_DEVICE); - ctrl->async_event_sqe.data = NULL; + if (ctrl->async_event_sqe.data) { + nvme_rdma_free_qe(ctrl->device->dev, &ctrl->async_event_sqe, + sizeof(struct nvme_command), DMA_TO_DEVICE); + ctrl->async_event_sqe.data = NULL; + } out_free_queue: nvme_rdma_free_queue(&ctrl->queues[0]); return error; From patchwork Sat Apr 11 12:08:48 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228085 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.8 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,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 33653C2BB85 for ; Sat, 11 Apr 2020 12:15:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 098FF21D7F for ; Sat, 11 Apr 2020 12:15:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607308; bh=64g/FuVY4FkADB9UpvuwvHmWfRLDc5mR7iw725sbOe8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=RQxaL/Pk0v7JTtXz4FoTgKC4S1nBsxHbJaB1Iw/1zfyjLLCnr6IJ6s0jN3ROjq4zM vOHK1V3LHRxuhf5AEPQIj3UbGmNdktqvCX9U+PyK9QNi6WQL7jE4uCEiXq9X+anPGZ j1uQXNka6Fh4QyrimuFpqJR1XSBV0YY52MnDtf+A= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727034AbgDKMPG (ORCPT ); Sat, 11 Apr 2020 08:15:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:48856 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726934AbgDKMPF (ORCPT ); Sat, 11 Apr 2020 08:15: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 46BA620692; Sat, 11 Apr 2020 12:15:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607305; bh=64g/FuVY4FkADB9UpvuwvHmWfRLDc5mR7iw725sbOe8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xEhBmJgBrboQWKRA8HHhCvzQ/m1SwjX47inhuE+6UbDsP9e9pQ/s4ys5NnZB5Eezn 7ZgRBM5JZYEl1JeNCIlgWolvMcIHLChtHFcAD9uoBSbjIrQX5EOpWhzAjBr/R26GC/ ofgQVyKDeOsGO+MW7xAsqyZaXWdYSu6Xd/uCwIig= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mario Kleiner , Alex Deucher , Sasha Levin Subject: [PATCH 4.19 06/54] drm/amd/display: Add link_rate quirk for Apple 15" MBP 2017 Date: Sat, 11 Apr 2020 14:08:48 +0200 Message-Id: <20200411115508.931334215@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Mario Kleiner [ Upstream commit dec9de2ada523b344eb2428abfedf9d6cd0a0029 ] This fixes a problem found on the MacBookPro 2017 Retina panel: The panel reports 10 bpc color depth in its EDID, and the firmware chooses link settings at boot which support enough bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2 aka 0xc), but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps (multiplier value 0xa) as possible, in direct contradiction of what the firmware successfully set up. This restricts the panel to 8 bpc, not providing the full color depth of the panel on Linux <= 5.5. Additionally, commit '4a8ca46bae8a ("drm/amd/display: Default max bpc to 16 for eDP")' introduced into Linux 5.6-rc1 will unclamp panel depth to its full 10 bpc, thereby requiring a eDP bandwidth for all modes that exceeds the bandwidth available and causes all modes to fail validation -> No modes for the laptop panel -> failure to set any mode -> Panel goes dark. This patch adds a quirk specific to the MBP 2017 15" Retina panel to override reported max link rate to the correct maximum of 0xc = LINK_RATE_RBR2 to fix the darkness and reduced display precision. Please apply for Linux 5.6+ to avoid regressing Apple MBP panel support. Signed-off-by: Mario Kleiner Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 122249da03ab7..a4928854a3de5 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -2440,6 +2440,17 @@ static bool retrieve_link_cap(struct dc_link *link) sink_id.ieee_device_id, sizeof(sink_id.ieee_device_id)); + /* Quirk Apple MBP 2017 15" Retina panel: Wrong DP_MAX_LINK_RATE */ + { + uint8_t str_mbp_2017[] = { 101, 68, 21, 101, 98, 97 }; + + if ((link->dpcd_caps.sink_dev_id == 0x0010fa) && + !memcmp(link->dpcd_caps.sink_dev_id_str, str_mbp_2017, + sizeof(str_mbp_2017))) { + link->reported_link_cap.link_rate = 0x0c; + } + } + core_link_read_dpcd( link, DP_SINK_HW_REVISION_START, From patchwork Sat Apr 11 12:08:50 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228004 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.8 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, 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 2AA8FC2BA2B for ; Sat, 11 Apr 2020 12:26:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 049AE20692 for ; Sat, 11 Apr 2020 12:26:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586608001; bh=XMf7QVap6ODLiVJo0XE8+jiJoxTHwXWjdNCTTv0ulBk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=KFJImwjOJHmlFctakVHq21G9+X7rvKIgvVmRB1d9SzmeR+q4hPkvDqbm06tn5iJjq Xej2Yo/6GJzec0i4KNRob/PbIZZqx76LVmMcpbwmlLel0PytcJNQ9NfqE8Bvz8hQsJ 61TNuApk8lnK1RFcDklYHD8uzOc2kfzmTjNgnFJM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727757AbgDKMPL (ORCPT ); Sat, 11 Apr 2020 08:15:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:48944 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727709AbgDKMPL (ORCPT ); Sat, 11 Apr 2020 08:15:11 -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 1877120787; Sat, 11 Apr 2020 12:15:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607310; bh=XMf7QVap6ODLiVJo0XE8+jiJoxTHwXWjdNCTTv0ulBk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PKvLsbRXrHVVQQRyyrZ8qRYubb5cdFXv33M7H8n9Bbx9XkCo68/y8reHpTLCV46IJ o/T9McH4xenGAzlnlJ1huINGfr8txpCT+A5GpqAMKPsumnuIsEsJ0EXqHI+148VVr6 Wwt3nmDQDzruTpTzWmHq17oktt+nD7UvJP0gKwt8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eugeniy Paltsev , Masahiro Yamada , Sasha Levin Subject: [PATCH 4.19 08/54] initramfs: restore default compression behavior Date: Sat, 11 Apr 2020 14:08:50 +0200 Message-Id: <20200411115509.125222779@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Eugeniy Paltsev [ Upstream commit 785d74ec3bbf26ac7f6e92e6e96a259aec0f107a ] Even though INITRAMFS_SOURCE kconfig option isn't set in most of defconfigs it is used (set) extensively by various build systems. Commit f26661e12765 ("initramfs: make initramfs compression choice non-optional") has changed default compression mode. Previously we compress initramfs using available compression algorithm. Now we don't use any compression at all by default. It significantly increases the image size in case of build system chooses embedded initramfs. Initially I faced with this issue while using buildroot. As of today it's not possible to set preferred compression mode in target defconfig as this option depends on INITRAMFS_SOURCE being set. Modification of all build systems either doesn't look like good option. Let's instead rewrite initramfs compression mode choices list the way that "INITRAMFS_COMPRESSION_NONE" will be the last option in the list. In that case it will be chosen only if all other options (which implements any compression) are not available. Signed-off-by: Eugeniy Paltsev Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin --- usr/Kconfig | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/usr/Kconfig b/usr/Kconfig index 43658b8a975e5..8b4826de1189f 100644 --- a/usr/Kconfig +++ b/usr/Kconfig @@ -131,17 +131,6 @@ choice If in doubt, select 'None' -config INITRAMFS_COMPRESSION_NONE - bool "None" - help - Do not compress the built-in initramfs at all. This may sound wasteful - in space, but, you should be aware that the built-in initramfs will be - compressed at a later stage anyways along with the rest of the kernel, - on those architectures that support this. However, not compressing the - initramfs may lead to slightly higher memory consumption during a - short time at boot, while both the cpio image and the unpacked - filesystem image will be present in memory simultaneously - config INITRAMFS_COMPRESSION_GZIP bool "Gzip" depends on RD_GZIP @@ -214,6 +203,17 @@ config INITRAMFS_COMPRESSION_LZ4 If you choose this, keep in mind that most distros don't provide lz4 by default which could cause a build failure. +config INITRAMFS_COMPRESSION_NONE + bool "None" + help + Do not compress the built-in initramfs at all. This may sound wasteful + in space, but, you should be aware that the built-in initramfs will be + compressed at a later stage anyways along with the rest of the kernel, + on those architectures that support this. However, not compressing the + initramfs may lead to slightly higher memory consumption during a + short time at boot, while both the cpio image and the unpacked + filesystem image will be present in memory simultaneously + endchoice config INITRAMFS_COMPRESSION From patchwork Sat Apr 11 12:08:52 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228001 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.8 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, 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 4F8E7C2BA2B for ; Sat, 11 Apr 2020 12:27:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1801B20644 for ; Sat, 11 Apr 2020 12:27:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586608030; bh=wE60NzE6a4XNodsKvRma5brB+q02opg97ymdIJvL9Rg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=Ix03cUbhs0KX6XKAyjqKHhAo8Sk3KQIXyLtheMgssWHk9ze7CI8eKr8TJhqTqH+Og qBKsS6BiVmHXsKAZvYV7zNaEvtGBJsHdQAsvTlZYoaeW5s25wln25fboPRc3WsG7zX PHYaxZjynmxSNKGabpdSYMErH8S4M2ki/4GK+jqE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728024AbgDKMOs (ORCPT ); Sat, 11 Apr 2020 08:14:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:48170 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727998AbgDKMOl (ORCPT ); Sat, 11 Apr 2020 08:14: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 1742220692; Sat, 11 Apr 2020 12:14:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607281; bh=wE60NzE6a4XNodsKvRma5brB+q02opg97ymdIJvL9Rg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WKDowyYA0cAwZ2pbXeZMCLe5WhDmyPdoTFoIKOk7IHHkrQ60zKCr2uH6kRbn3JEha 3hDY49Awh1aD++Svd9zTRRrgFUWrjTH8NGlpPC+koF7Yk27GCcQQ4SUO/zcuOLRTH+ QOZiUT3UQjQygmIdveRJjZrMYn/MbJwfb8XEjs5M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Len Brown , Sasha Levin Subject: [PATCH 4.19 10/54] tools/power turbostat: Fix gcc build warnings Date: Sat, 11 Apr 2020 14:08:52 +0200 Message-Id: <20200411115509.251668935@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Len Brown [ Upstream commit d8d005ba6afa502ca37ced5782f672c4d2fc1515 ] Warning: ‘__builtin_strncpy’ specified bound 20 equals destination size [-Wstringop-truncation] reduce param to strncpy, to guarantee that a null byte is always copied into destination buffer. Signed-off-by: Len Brown Signed-off-by: Sasha Levin --- tools/power/x86/turbostat/turbostat.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c index 02d123871ef95..fb665fdc722a4 100644 --- a/tools/power/x86/turbostat/turbostat.c +++ b/tools/power/x86/turbostat/turbostat.c @@ -5144,9 +5144,9 @@ int add_counter(unsigned int msr_num, char *path, char *name, } msrp->msr_num = msr_num; - strncpy(msrp->name, name, NAME_BYTES); + strncpy(msrp->name, name, NAME_BYTES - 1); if (path) - strncpy(msrp->path, path, PATH_BYTES); + strncpy(msrp->path, path, PATH_BYTES - 1); msrp->width = width; msrp->type = type; msrp->format = format; From patchwork Sat Apr 11 12:08:53 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228087 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.8 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 49978C2BB85 for ; Sat, 11 Apr 2020 12:14:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 206A7214D8 for ; Sat, 11 Apr 2020 12:14:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607286; bh=FIQyZpGeWjGjICZFpF4bFafvr3BU4jUe3KlA1RozA18=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=wMPd/uNO2oT4auMESf9Nzonq8sY5FZX4r2Lg4PCQXmYCIzGdBWwjCWZzxjzitoGvQ 0cR3kPaFOot6kMENIsHawftYzp/xuesshu/KXQlvGkw07U4lw5dfgeYcgGJdNUSlHx /ujcYd4WstEqEaaXibNI6CJ1BJCo57NgBuORT8zs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727980AbgDKMOo (ORCPT ); Sat, 11 Apr 2020 08:14:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:48248 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726953AbgDKMOn (ORCPT ); Sat, 11 Apr 2020 08:14: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 817BD20692; Sat, 11 Apr 2020 12:14:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607284; bh=FIQyZpGeWjGjICZFpF4bFafvr3BU4jUe3KlA1RozA18=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XBjzNiaSdhvyhLSNEyA9y8sFBUW7SOmNm3QZFfiPryKhNOkfydLc4yBZ9+Pp/dy4d 8eYDIXbqujFdcMvH+eoN1m4+QxiJEpbvHPWvVefZntu6Ltd47AuWuChTkDsAn1MWlu q869xzlPZrslEKNtDIUanUvffkBUw1sTVBZVZIE8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Len Brown , Sasha Levin Subject: [PATCH 4.19 11/54] tools/power turbostat: Fix missing SYS_LPI counter on some Chromebooks Date: Sat, 11 Apr 2020 14:08:53 +0200 Message-Id: <20200411115509.374022389@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Len Brown [ Upstream commit 1f81c5efc020314b2db30d77efe228b7e117750d ] Some Chromebook BIOS' do not export an ACPI LPIT, which is how Linux finds the residency counter for CPU and SYSTEM low power states, that is exports in /sys/devices/system/cpu/cpuidle/*residency_us When these sysfs attributes are missing, check the debugfs attrubte from the pmc_core driver, which accesses the same counter value. Signed-off-by: Len Brown Signed-off-by: Sasha Levin --- tools/power/x86/turbostat/turbostat.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) --- a/tools/power/x86/turbostat/turbostat.c +++ b/tools/power/x86/turbostat/turbostat.c @@ -299,6 +299,10 @@ int *irqs_per_cpu; /* indexed by cpu_nu void setup_all_buffers(void); +char *sys_lpi_file; +char *sys_lpi_file_sysfs = "/sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us"; +char *sys_lpi_file_debugfs = "/sys/kernel/debug/pmc_core/slp_s0_residency_usec"; + int cpu_is_not_present(int cpu) { return !CPU_ISSET_S(cpu, cpu_present_setsize, cpu_present_set); @@ -2844,8 +2848,6 @@ int snapshot_gfx_mhz(void) * * record snapshot of * /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us - * - * return 1 if config change requires a restart, else return 0 */ int snapshot_cpu_lpi_us(void) { @@ -2865,17 +2867,14 @@ int snapshot_cpu_lpi_us(void) /* * snapshot_sys_lpi() * - * record snapshot of - * /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us - * - * return 1 if config change requires a restart, else return 0 + * record snapshot of sys_lpi_file */ int snapshot_sys_lpi_us(void) { FILE *fp; int retval; - fp = fopen_or_die("/sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us", "r"); + fp = fopen_or_die(sys_lpi_file, "r"); retval = fscanf(fp, "%lld", &cpuidle_cur_sys_lpi_us); if (retval != 1) @@ -4743,10 +4742,16 @@ void process_cpuid() else BIC_NOT_PRESENT(BIC_CPU_LPI); - if (!access("/sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us", R_OK)) + if (!access(sys_lpi_file_sysfs, R_OK)) { + sys_lpi_file = sys_lpi_file_sysfs; BIC_PRESENT(BIC_SYS_LPI); - else + } else if (!access(sys_lpi_file_debugfs, R_OK)) { + sys_lpi_file = sys_lpi_file_debugfs; + BIC_PRESENT(BIC_SYS_LPI); + } else { + sys_lpi_file_sysfs = NULL; BIC_NOT_PRESENT(BIC_SYS_LPI); + } if (!quiet) decode_misc_feature_control(); From patchwork Sat Apr 11 12:08:56 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228086 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.8 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,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 58C65C2BBC7 for ; Sat, 11 Apr 2020 12:14:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 32F8921556 for ; Sat, 11 Apr 2020 12:14:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607294; bh=59SDtq83stogFrSkBMlUQ9dYbywXYRbprItnSNbUMEk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=aknu2QcWNFi8F9Kvm/Hmx8TCGXMp7tM7Hr5IhENMjgviFLAfQ9+Jz/y3YvMWNgP1C 3B4WB3A0FqfYvFac9JZPgsXz4qyCvU/Ca5syifIprkZKsS0hXyfeb0dR73Q964TWQo d4aEBvGG0fFTMLGoAserG2BviejuhIeBraCv7OWE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726107AbgDKMOw (ORCPT ); Sat, 11 Apr 2020 08:14:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:48444 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728045AbgDKMOv (ORCPT ); Sat, 11 Apr 2020 08:14:51 -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 C33B02137B; Sat, 11 Apr 2020 12:14:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607291; bh=59SDtq83stogFrSkBMlUQ9dYbywXYRbprItnSNbUMEk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RqbmT9potWOeaRhLoqfGNKPC3hCdfqEfcM3dtsut1Om1VIuX5atqw9am/l24kfMPn DG3cXCM/L2DAsbs10Zg3/jFVDSA29USQ3EL2yXXav7xgcpBrThjFjYrc/xUxUGCZJs Nd7wyonvCMqaBkBRKG+B+5rjfg32rZTPfrSdZBIs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, YueHaibing Subject: [PATCH 4.19 14/54] misc: rtsx: set correct pcr_ops for rts522A Date: Sat, 11 Apr 2020 14:08:56 +0200 Message-Id: <20200411115509.662924327@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: YueHaibing commit 10cea23b6aae15e8324f4101d785687f2c514fe5 upstream. rts522a should use rts522a_pcr_ops, which is diffrent with rts5227 in phy/hw init setting. Fixes: ce6a5acc9387 ("mfd: rtsx: Add support for rts522A") Signed-off-by: YueHaibing Cc: stable Link: https://lore.kernel.org/r/20200326032618.20472-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman --- drivers/misc/cardreader/rts5227.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/misc/cardreader/rts5227.c +++ b/drivers/misc/cardreader/rts5227.c @@ -369,6 +369,7 @@ static const struct pcr_ops rts522a_pcr_ void rts522a_init_params(struct rtsx_pcr *pcr) { rts5227_init_params(pcr); + pcr->ops = &rts522a_pcr_ops; pcr->tx_initial_phase = SET_CLOCK_PHASE(20, 20, 11); pcr->reg_pm_ctrl3 = RTS522A_PM_CTRL3; } From patchwork Sat Apr 11 12:08:58 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228079 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.8 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,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 23022C2BBC7 for ; Sat, 11 Apr 2020 12:16:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EBBA420644 for ; Sat, 11 Apr 2020 12:16:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607416; bh=TT64A1W14aMx+C6Ty9ZtW4tzFoenHFEPHktA6n1JgQ0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=y6trlfISzc3O6xIEsETwbDhY+k9qwS67HHrgySrO4GxzVElVJFV6eawRU6LAY9C4U ONp/aBMsT3qz+2T9xvTXQeOht41KteEAW2lcPamasw2t0UtiJSX31b7o7gZzqzU7q9 utCrdFOiTk0VmcIIh0hFZ0HM91RLEKLCPdW6khws= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727117AbgDKMQv (ORCPT ); Sat, 11 Apr 2020 08:16:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:51172 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728119AbgDKMQu (ORCPT ); Sat, 11 Apr 2020 08:16:50 -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 1BF8A21655; Sat, 11 Apr 2020 12:16:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607409; bh=TT64A1W14aMx+C6Ty9ZtW4tzFoenHFEPHktA6n1JgQ0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=c2WNqxr7oMCIsG5THAXNBXVd4MosXPKldZmSV8XHgtEyZPeNS3HKgfj2iBQoFzNc2 LEucWQBYxUNhHI2OWNsvAA7euxvn5IVZxwOnlsp+CRMH5UBglJu4j06P+qzmM7fWbh QtavXNzxsbs63mP8JiGTkpIYx1HErBzXRT2f8ejU= 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 4.19 16/54] misc: pci_endpoint_test: Avoid using module parameter to determine irqtype Date: Sat, 11 Apr 2020 14:08:58 +0200 Message-Id: <20200411115510.027666182@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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 @@ -104,6 +104,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; @@ -163,6 +164,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, @@ -197,6 +199,8 @@ static bool pci_endpoint_test_alloc_irq_ irq = 0; res = false; } + + test->irq_type = type; test->num_irqs = irq; return res; @@ -336,6 +340,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; @@ -432,6 +437,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) @@ -500,6 +506,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) @@ -561,7 +568,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); @@ -573,12 +580,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; } @@ -655,6 +660,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 Sat Apr 11 12:08:59 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228005 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.8 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,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 0D5BBC2BBC7 for ; Sat, 11 Apr 2020 12:26:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CFD6320787 for ; Sat, 11 Apr 2020 12:26:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607995; bh=AOAvaLVkDHeMRUUOp5dsa0b0RO3eEiCYm6DzGZdjcBU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=MuQ+McP1nC8sNspu+kpi5wzVsFvVdMpy6RI5FfTco0/2KsUvKys5+NptFgZLKBRrH qF1rciUqPhXpbeWM1loV5AdSRp7VTU5+ue2HM52qyJZop23YMzcWmsGkfd1k81VNTl yHzgPLMoV5rGARsNabFBXDqal4xvbRkvFXwrRyB8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727872AbgDKMPV (ORCPT ); Sat, 11 Apr 2020 08:15:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:49114 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728086AbgDKMPS (ORCPT ); Sat, 11 Apr 2020 08:15:18 -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 5F81520692; Sat, 11 Apr 2020 12:15:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607317; bh=AOAvaLVkDHeMRUUOp5dsa0b0RO3eEiCYm6DzGZdjcBU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Em0bDT56uhdl0SXCNeuDHFjijs17p4xRv1w61GUm/tQPj4xoFT9amxQRNorhX/3OA /gj98MBj4Kz0ZB93RPe56jetdUceK6Q2Qrk8lUi3FZehndYsH4CiciUd6wiOdWw2wt 5hkC747IPY5aKklpLjb7zDvOmF5sgs6g7TRn4IOQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eugene Syromiatnikov , Mathieu Poirier Subject: [PATCH 4.19 17/54] coresight: do not use the BIT() macro in the UAPI header Date: Sat, 11 Apr 2020 14:08:59 +0200 Message-Id: <20200411115510.152374519@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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 Sat Apr 11 12:09:01 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228082 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.8 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, 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 08C79C2BBC7 for ; Sat, 11 Apr 2020 12:16:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D49B82137B for ; Sat, 11 Apr 2020 12:16:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607373; bh=OXrUAv0/FY58TjlFjtpfH64vsFzsN8sjKqjIdSfBOnw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=K6Hp8yBgUdCNwyOzYiH2s5tYnPkaKogH/aT1so0VMhrIaaZmIwUeJj68hNOstxcnt IQYfkX6eCCAUvG0jVqRSZc0cB/K3QVWWjRlPpzX7D2phylN0Yt4fwTEPzNTou70m0U rAYsc95YY/aX0B/ENqetzA6w8rDrqkCXUlz21/is= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726975AbgDKMQM (ORCPT ); Sat, 11 Apr 2020 08:16:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:50354 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728240AbgDKMQL (ORCPT ); Sat, 11 Apr 2020 08:16:11 -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 77FA420692; Sat, 11 Apr 2020 12:16:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607370; bh=OXrUAv0/FY58TjlFjtpfH64vsFzsN8sjKqjIdSfBOnw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jVsacNOsdtGUJDxl8QPQI4yUAGYa4tbjxSGkPJ9antULGA93XhHnag4aBv4XbJlJT 6U9maXOBqiI1QjA0DgBESzt9BCoVtXpj6FBCOdcoPmOgIOf2CaMhOK+zsb9zVa1Ajo zjqsSRiucNdpp0fmad0xOcS/rrEYFCNJ1yD4Gtnc= 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 4.19 19/54] extcon: axp288: Add wakeup support Date: Sat, 11 Apr 2020 14:09:01 +0200 Message-Id: <20200411115510.401693544@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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 @@ -428,9 +428,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" }, {}, @@ -442,6 +473,7 @@ static struct platform_driver axp288_ext .id_table = axp288_extcon_table, .driver = { .name = "axp288_extcon", + .pm = &axp288_extcon_pm_ops, }, }; From patchwork Sat Apr 11 12:09:02 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228080 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.8 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, 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 6D737C2BB85 for ; Sat, 11 Apr 2020 12:16:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3F585215A4 for ; Sat, 11 Apr 2020 12:16:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607398; bh=Z/eHiKT7CyAUIb68xV6ks0mm2WcJfo7+yQbJgWoiuG8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=jECpLdRxDNe2cGeJCeQvgSWsJ4u4JnAZAI5fclRQCGYRwFGqhmEn8fllC3gV2xXxP gYirDr0ya/wzI7eYNuOgZlPu2cDJk0Rn1BmR1zjPSz7gMdlchdnDQJVwnCVGYLaioi L6jAiJ7b3K/DEar1TBqCeNUMX+o96oJ43a9YHC3Q= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726933AbgDKMQg (ORCPT ); Sat, 11 Apr 2020 08:16:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:50872 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728262AbgDKMQf (ORCPT ); Sat, 11 Apr 2020 08:16:35 -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 9868B20692; Sat, 11 Apr 2020 12:16:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607395; bh=Z/eHiKT7CyAUIb68xV6ks0mm2WcJfo7+yQbJgWoiuG8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LZXSC45SEDhp8L7sJQtb5vMXeo2kWH44UiZOMGPQ413zlab2xl5/0M3EIwrDmLUCM XLhUDFjvb/XTxBtbopHOoBVHAE0+d5LZ4nC36AO7r5nuQnAd1I6XISEsO+E6QHoGYc y0v3tlNJK0PvZ86NmblVuiVMDvs+GZmAakuhFwss= 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 4.19 20/54] power: supply: axp288_charger: Add special handling for HP Pavilion x2 10 Date: Sat, 11 Apr 2020 14:09:02 +0200 Message-Id: <20200411115510.523425293@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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 @@ -28,6 +28,7 @@ #include #include #include +#include #define PS_STAT_VBUS_TRIGGER (1 << 0) #define PS_STAT_BAT_CHRG_DIR (1 << 2) @@ -552,6 +553,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 = @@ -575,7 +619,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) { @@ -692,6 +740,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 Sat Apr 11 12:09:04 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228016 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.8 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,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 E38BEC2BB85 for ; Sat, 11 Apr 2020 12:25:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BD54720692 for ; Sat, 11 Apr 2020 12:25:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607934; bh=WLjTGfAMIh/dxbygmZhyz+9HAKYXuj2WS8AFJSWjkck=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=PPspkR2ljhDbhCxszJ7sS2hgcdzryEcDRNI42t+idjLljp+xmWR+p45HgRLpjL7QB zW/AIcGgKGp2M4Se4eD2Findc5hlG6+msdpyH+gXaxIuX0OWoamWRByaeTBCNM2AYl jz58oyVxhWjoKNWFt7vBonnedIrvcpU/GGCGmBfo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728330AbgDKMZ1 (ORCPT ); Sat, 11 Apr 2020 08:25:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:50974 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727788AbgDKMQj (ORCPT ); Sat, 11 Apr 2020 08:16:39 -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 7085420692; Sat, 11 Apr 2020 12:16:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607399; bh=WLjTGfAMIh/dxbygmZhyz+9HAKYXuj2WS8AFJSWjkck=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=j/CJL9xZErB6US2fSGzXl3U67ugv05eOfR7tEQdCtWN8Jfc9hqI0pGcMptWrveV1v IdKp5S/EBiiMt4YUTGN2yVhgoXybluv+MoUX+mBX7Z5QZkh9+NsZrVYvNxvRCwkkLs AQufKc4ERsCgdQ7dWVqPhUVZnfLIHbE9hZyJDfTw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Howells Subject: [PATCH 4.19 22/54] rxrpc: Fix sendmsg(MSG_WAITALL) handling Date: Sat, 11 Apr 2020 14:09:04 +0200 Message-Id: <20200411115510.720343132@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: David Howells commit 498b577660f08cef5d9e78e0ed6dcd4c0939e98c upstream. Fix the handling of sendmsg() with MSG_WAITALL for userspace to round the timeout for when a signal occurs up to at least two jiffies as a 1 jiffy timeout may end up being effectively 0 if jiffies wraps at the wrong time. Fixes: bc5e3a546d55 ("rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals") Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman --- net/rxrpc/sendmsg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/net/rxrpc/sendmsg.c +++ b/net/rxrpc/sendmsg.c @@ -62,8 +62,8 @@ static int rxrpc_wait_for_tx_window_noni rtt = READ_ONCE(call->peer->rtt); rtt2 = nsecs_to_jiffies64(rtt) * 2; - if (rtt2 < 1) - rtt2 = 1; + if (rtt2 < 2) + rtt2 = 2; timeout = rtt2; tx_start = READ_ONCE(call->tx_hard_ack); From patchwork Sat Apr 11 12:09:06 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228017 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.8 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,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 211C5C2BA2B for ; Sat, 11 Apr 2020 12:25:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EBA382084D for ; Sat, 11 Apr 2020 12:25:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607925; bh=nBp8M//Wwkue4wWaCuCCtoO0nyJNfejoIKWOMt6EWGA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=MrAyeplYFb4QAmeRD0lT1R0SUNt4mxBPJGSoDM3j7p4D6EKrE0mEE21X5WtJ7y6XK F24a6COib8x+2qBTsTSfUPsmwh+NIlcbIk22monlSS6N0rxEG+gcRq2c2DOFnAhbw2 E5UF/NXVmcP8pK2W9ZoHEiVMxUgM51QMV24JjRWg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728284AbgDKMQp (ORCPT ); Sat, 11 Apr 2020 08:16:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:51090 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726899AbgDKMQo (ORCPT ); Sat, 11 Apr 2020 08:16:44 -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 46C2920644; Sat, 11 Apr 2020 12:16:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607404; bh=nBp8M//Wwkue4wWaCuCCtoO0nyJNfejoIKWOMt6EWGA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O7icK7Ib7lVZSe0+Kqjl0FMOa+zXDYCqx4r4nGd3PAf45c25Fi1uFTLWE53BrWoaq N6/TivjyeTzvNPas2IQjP7faREsSVKkcMEysUY0sx9SQUWwzPVoX0ZND/WUYkvRXEK P0Mi54RMTWDc/xiQLEtBm78SLf3URRauGGPx4/M4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Daniel Jordan , Eric Biggers , Herbert Xu , Steffen Klassert , linux-crypto@vger.kernel.org Subject: [PATCH 4.19 24/54] padata: always acquire cpu_hotplug_lock before pinst->lock Date: Sat, 11 Apr 2020 14:09:06 +0200 Message-Id: <20200411115510.950406190@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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 commit 38228e8848cd7dd86ccb90406af32de0cad24be3 upstream. lockdep complains when padata's paths to update cpumasks via CPU hotplug and sysfs are both taken: # echo 0 > /sys/devices/system/cpu/cpu1/online # echo ff > /sys/kernel/pcrypt/pencrypt/parallel_cpumask ====================================================== WARNING: possible circular locking dependency detected 5.4.0-rc8-padata-cpuhp-v3+ #1 Not tainted ------------------------------------------------------ bash/205 is trying to acquire lock: ffffffff8286bcd0 (cpu_hotplug_lock.rw_sem){++++}, at: padata_set_cpumask+0x2b/0x120 but task is already holding lock: ffff8880001abfa0 (&pinst->lock){+.+.}, at: padata_set_cpumask+0x26/0x120 which lock already depends on the new lock. padata doesn't take cpu_hotplug_lock and pinst->lock in a consistent order. Which should be first? CPU hotplug calls into padata with cpu_hotplug_lock already held, so it should have priority. Fixes: 6751fb3c0e0c ("padata: Use get_online_cpus/put_online_cpus") Signed-off-by: Daniel Jordan Cc: Eric Biggers 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: Greg Kroah-Hartman --- kernel/padata.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/kernel/padata.c +++ b/kernel/padata.c @@ -671,8 +671,8 @@ int padata_set_cpumask(struct padata_ins struct cpumask *serial_mask, *parallel_mask; int err = -EINVAL; - mutex_lock(&pinst->lock); get_online_cpus(); + mutex_lock(&pinst->lock); switch (cpumask_type) { case PADATA_CPU_PARALLEL: @@ -690,8 +690,8 @@ int padata_set_cpumask(struct padata_ins err = __padata_set_cpumasks(pinst, parallel_mask, serial_mask); out: - put_online_cpus(); mutex_unlock(&pinst->lock); + put_online_cpus(); return err; } From patchwork Sat Apr 11 12:09:10 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228006 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.8 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,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 AF7DAC2BA2B for ; Sat, 11 Apr 2020 12:26:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 845A720644 for ; Sat, 11 Apr 2020 12:26:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607989; bh=bUKIwhqr/I1zZj3MIfidzAKGc3BlyDNM+bhRPyedYz8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=Qoeva9AaBXoRlzkPv87yccupKpCZH8nusrnQ4uujF41pYtyoXv1Zy5E5nuttoZOn2 gjVnF/FOnDLZ5Y7rjaWLQsdFVwF2rH7/b7ZJa4EqjluliK82hAayJd5qaCPxrK9lqI +/g6uijw2TWVaj90JKmqr8rJPx1/DllI9200DCZw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727045AbgDKMP0 (ORCPT ); Sat, 11 Apr 2020 08:15:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:49316 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727181AbgDKMPZ (ORCPT ); Sat, 11 Apr 2020 08:15:25 -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 9B29C21655; Sat, 11 Apr 2020 12:15:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607325; bh=bUKIwhqr/I1zZj3MIfidzAKGc3BlyDNM+bhRPyedYz8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YjyakbU3x04TquuqK0aPptmvK9v2A++njv3YTnZ+/U9p3X3t5O+3eeTsBv+WSwQGm jiq9YJl75nYCGk74lWztaoh7jlkrQM+vFk/zetlJFgC0CDHAQnJtX/OV1wusP2M0kK typbdsFF6I0fSCJlDsZjo9YtFS5+PrOoQooJBXpc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Moshe Levi , Stephen Hemminger , Marcelo Ricardo Leitner , netdev@vger.kernel.org, Jarod Wilson , "David S. Miller" Subject: [PATCH 4.19 28/54] ipv6: dont auto-add link-local address to lag ports Date: Sat, 11 Apr 2020 14:09:10 +0200 Message-Id: <20200411115511.324846089@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Jarod Wilson [ Upstream commit 744fdc8233f6aa9582ce08a51ca06e59796a3196 ] Bonding slave and team port devices should not have link-local addresses automatically added to them, as it can interfere with openvswitch being able to properly add tc ingress. Basic reproducer, courtesy of Marcelo: $ ip link add name bond0 type bond $ ip link set dev ens2f0np0 master bond0 $ ip link set dev ens2f1np2 master bond0 $ ip link set dev bond0 up $ ip a s 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens2f0np0: mtu 1500 qdisc mq master bond0 state UP group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff 5: ens2f1np2: mtu 1500 qdisc mq master bond0 state DOWN group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff 11: bond0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff inet6 fe80::20f:53ff:fe2f:ea40/64 scope link valid_lft forever preferred_lft forever (above trimmed to relevant entries, obviously) $ sysctl net.ipv6.conf.ens2f0np0.addr_gen_mode=0 net.ipv6.conf.ens2f0np0.addr_gen_mode = 0 $ sysctl net.ipv6.conf.ens2f1np2.addr_gen_mode=0 net.ipv6.conf.ens2f1np2.addr_gen_mode = 0 $ ip a l ens2f0np0 2: ens2f0np0: mtu 1500 qdisc mq master bond0 state UP group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff inet6 fe80::20f:53ff:fe2f:ea40/64 scope link tentative valid_lft forever preferred_lft forever $ ip a l ens2f1np2 5: ens2f1np2: mtu 1500 qdisc mq master bond0 state DOWN group default qlen 1000 link/ether 00:0f:53:2f:ea:40 brd ff:ff:ff:ff:ff:ff inet6 fe80::20f:53ff:fe2f:ea40/64 scope link tentative valid_lft forever preferred_lft forever Looks like addrconf_sysctl_addr_gen_mode() bypasses the original "is this a slave interface?" check added by commit c2edacf80e15, and results in an address getting added, while w/the proposed patch added, no address gets added. This simply adds the same gating check to another code path, and thus should prevent the same devices from erroneously obtaining an ipv6 link-local address. Fixes: d35a00b8e33d ("net/ipv6: allow sysctl to change link-local address generation mode") Reported-by: Moshe Levi CC: Stephen Hemminger CC: Marcelo Ricardo Leitner CC: netdev@vger.kernel.org Signed-off-by: Jarod Wilson Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/ipv6/addrconf.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -3241,6 +3241,10 @@ static void addrconf_addr_gen(struct ine if (netif_is_l3_master(idev->dev)) return; + /* no link local addresses on devices flagged as slaves */ + if (idev->dev->flags & IFF_SLAVE) + return; + ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0); switch (idev->cnf.addr_gen_mode) { From patchwork Sat Apr 11 12:09:13 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228084 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.8 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, 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 4EEFDC2BBC7 for ; Sat, 11 Apr 2020 12:15:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 294A520692 for ; Sat, 11 Apr 2020 12:15:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607335; bh=+E7nHQNtNavTflFgXsFcr/2lLc/xEjcHb705tglUxoY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=IYghFIIrZBmohopgA1ALGiCqhqEVdr8Uolnlb0Mqr2tEizBl2ZqYPQNl/2g3fIsN+ cwY2lc3UlcLklwurXeLC+/IcJMNZYa7g8rb69HAfcpJYV6CTbatOkpznLwKWPL8Fdl rvFkJ125jqpemH/RNq1AMQFvh4N57UfLtGzPo7Ko= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727641AbgDKMPd (ORCPT ); Sat, 11 Apr 2020 08:15:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:49460 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726913AbgDKMPd (ORCPT ); Sat, 11 Apr 2020 08:15: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 D2E6721556; Sat, 11 Apr 2020 12:15:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607332; bh=+E7nHQNtNavTflFgXsFcr/2lLc/xEjcHb705tglUxoY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=04t5qJfME0yLvwhhhiHK5Qqs//CWLKgnrx0JzKyINE+mth5nks9Zj6f65OvVuPZnD EdLv92+lxJbPHSAkDZWQZfVC5C1FSjrQUTjyK32Y9/3xIf7NXeDwMLx1PYN8cxm8Rd Dvz6JPl43+072AS5MXLvBPrmBZktXFILAI2Jaxeg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Oleksij Rempel , Andrew Lunn , Florian Fainelli , "David S. Miller" Subject: [PATCH 4.19 31/54] net: phy: micrel: kszphy_resume(): add delay after genphy_resume() before accessing PHY registers Date: Sat, 11 Apr 2020 14:09:13 +0200 Message-Id: <20200411115511.571968882@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Oleksij Rempel [ Upstream commit 6110dff776f7fa65c35850ef65b41d3b39e2fac2 ] After the power-down bit is cleared, the chip internally triggers a global reset. According to the KSZ9031 documentation, we have to wait at least 1ms for the reset to finish. If the chip is accessed during reset, read will return 0xffff, while write will be ignored. Depending on the system performance and MDIO bus speed, we may or may not run in to this issue. This bug was discovered on an iMX6QP system with KSZ9031 PHY and attached PHY interrupt line. If IRQ was used, the link status update was lost. In polling mode, the link status update was always correct. The investigation showed, that during a read-modify-write access, the read returned 0xffff (while the chip was still in reset) and corresponding write hit the chip _after_ reset and triggered (due to the 0xffff) another reset in an undocumented bit (register 0x1f, bit 1), resulting in the next write being lost due to the new reset cycle. This patch fixes the issue by adding a 1...2 ms sleep after the genphy_resume(). Fixes: 836384d2501d ("net: phy: micrel: Add specific suspend") Signed-off-by: Oleksij Rempel Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/phy/micrel.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/net/phy/micrel.c +++ b/drivers/net/phy/micrel.c @@ -29,6 +29,7 @@ #include #include #include +#include /* Operation Mode Strap Override */ #define MII_KSZPHY_OMSO 0x16 @@ -738,6 +739,12 @@ static int kszphy_resume(struct phy_devi genphy_resume(phydev); + /* After switching from power-down to normal mode, an internal global + * reset is automatically generated. Wait a minimum of 1 ms before + * read/write access to the PHY registers. + */ + usleep_range(1000, 2000); + ret = kszphy_config_reset(phydev); if (ret) return ret; From patchwork Sat Apr 11 12:09:14 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228007 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.8 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,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 5FE48C2BA2B for ; Sat, 11 Apr 2020 12:26:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3069420644 for ; Sat, 11 Apr 2020 12:26:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607981; bh=pOhhefnT3vt7QwB756HsUerLLEmN5XhypxWbbN3FghQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=hxazE5sZK7gbBdkihJ7qHSQ8uJNgxiy3bJrIANj4+Lof6TPZf5xddHJyq46lMLetH 9r8YPMIaJ7EkkuJhfKywyXiiVy8nQhX8miNz4LHPQURWOcKQkJVngFaIyge3cVa3Uy FUCB1kmaHIxDbK5qI8ErOjvjeNTxSWl/+o07X9bw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727072AbgDKMPf (ORCPT ); Sat, 11 Apr 2020 08:15:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:49524 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728121AbgDKMPe (ORCPT ); Sat, 11 Apr 2020 08:15:34 -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 3FDDA20644; Sat, 11 Apr 2020 12:15:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607334; bh=pOhhefnT3vt7QwB756HsUerLLEmN5XhypxWbbN3FghQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RDydOwsAIrb3GnqxfC2VgY3FYB/7SJnb2tF3a/z00WvdGEipv48z/WkkKQTOjUXSI gkm7rw4dMrerC7MNLqnz9zk0E3lUirOPJEVmQD2oMgl1fysJIFhlohPkwxRfYnbXzP f3k/vxsPcu0UfmAnT6xfn5w2Wx9kh8+Cs3d4A+Ds= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jisheng Zhang , "David S. Miller" Subject: [PATCH 4.19 32/54] net: stmmac: dwmac1000: fix out-of-bounds mac address reg setting Date: Sat, 11 Apr 2020 14:09:14 +0200 Message-Id: <20200411115511.659292266@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Jisheng Zhang [ Upstream commit 3e1221acf6a8f8595b5ce354bab4327a69d54d18 ] Commit 9463c4455900 ("net: stmmac: dwmac1000: Clear unused address entries") cleared the unused mac address entries, but introduced an out-of bounds mac address register programming bug -- After setting the secondary unicast mac addresses, the "reg" value has reached netdev_uc_count() + 1, thus we should only clear address entries if (addr < perfect_addr_number) Fixes: 9463c4455900 ("net: stmmac: dwmac1000: Clear unused address entries") Signed-off-by: Jisheng Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c @@ -218,7 +218,7 @@ static void dwmac1000_set_filter(struct reg++; } - while (reg <= perfect_addr_number) { + while (reg < perfect_addr_number) { writel(0, ioaddr + GMAC_ADDR_HIGH(reg)); writel(0, ioaddr + GMAC_ADDR_LOW(reg)); reg++; From patchwork Sat Apr 11 12:09:17 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228008 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.8 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,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 238CFC2BBFD for ; Sat, 11 Apr 2020 12:26:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EF781214D8 for ; Sat, 11 Apr 2020 12:26:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607974; bh=C36/UM24Ib+reJOzn3QAWtdjKAstIRHb1g+mYTY2dwk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=Af/eu2DtuzYkA4qX+YGqaTAT07XKSt6L2yibdO8A5lGwjqozcqucgtnKvDKCFud0U YK1Oi3/X563UjCRsPUcdWCTGiX28JDCCToOFgvo9/umZFB3PSJKQd+ATWfOXdsw/GV ekRecpx42oSdgqE7s2I95Shy41yYShXAMiUzo73g= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728164AbgDKMPm (ORCPT ); Sat, 11 Apr 2020 08:15:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:49758 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728121AbgDKMPm (ORCPT ); Sat, 11 Apr 2020 08:15:42 -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 81C87214D8; Sat, 11 Apr 2020 12:15:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607342; bh=C36/UM24Ib+reJOzn3QAWtdjKAstIRHb1g+mYTY2dwk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UVV+mIrcOxj+/QIYK01u8JbVF35HLVf/FARkkuLZImWsWExgTmumm02bmUIw5WMec w5lRySby5+dTfVi+nZrZmNtY8tigG3whDh+w/RQSbV4fSA2k3KXeXPb20mHlz6JAKG LK7BLOZWN0yOlD6cd/4ZG0SAywg8hCTBXzTmWUck= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Jason A. Donenfeld" , Theodore Tso Subject: [PATCH 4.19 35/54] random: always use batched entropy for get_random_u{32, 64} Date: Sat, 11 Apr 2020 14:09:17 +0200 Message-Id: <20200411115511.985292690@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Jason A. Donenfeld commit 69efea712f5b0489e67d07565aad5c94e09a3e52 upstream. It turns out that RDRAND is pretty slow. Comparing these two constructions: for (i = 0; i < CHACHA_BLOCK_SIZE; i += sizeof(ret)) arch_get_random_long(&ret); and long buf[CHACHA_BLOCK_SIZE / sizeof(long)]; extract_crng((u8 *)buf); it amortizes out to 352 cycles per long for the top one and 107 cycles per long for the bottom one, on Coffee Lake Refresh, Intel Core i9-9880H. And importantly, the top one has the drawback of not benefiting from the real rng, whereas the bottom one has all the nice benefits of using our own chacha rng. As get_random_u{32,64} gets used in more places (perhaps beyond what it was originally intended for when it was introduced as get_random_{int,long} back in the md5 monstrosity era), it seems like it might be a good thing to strengthen its posture a tiny bit. Doing this should only be stronger and not any weaker because that pool is already initialized with a bunch of rdrand data (when available). This way, we get the benefits of the hardware rng as well as our own rng. Another benefit of this is that we no longer hit pitfalls of the recent stream of AMD bugs in RDRAND. One often used code pattern for various things is: do { val = get_random_u32(); } while (hash_table_contains_key(val)); That recent AMD bug rendered that pattern useless, whereas we're really very certain that chacha20 output will give pretty distributed numbers, no matter what. So, this simplification seems better both from a security perspective and from a performance perspective. Signed-off-by: Jason A. Donenfeld Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20200221201037.30231-1-Jason@zx2c4.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman --- drivers/char/random.c | 20 ++++---------------- 1 file changed, 4 insertions(+), 16 deletions(-) --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -2280,11 +2280,11 @@ struct batched_entropy { /* * Get a random word for internal kernel use only. The quality of the random - * number is either as good as RDRAND or as good as /dev/urandom, with the - * goal of being quite fast and not depleting entropy. In order to ensure + * number is good as /dev/urandom, but there is no backtrack protection, with + * the goal of being quite fast and not depleting entropy. In order to ensure * that the randomness provided by this function is okay, the function - * wait_for_random_bytes() should be called and return 0 at least once - * at any point prior. + * wait_for_random_bytes() should be called and return 0 at least once at any + * point prior. */ static DEFINE_PER_CPU(struct batched_entropy, batched_entropy_u64) = { .batch_lock = __SPIN_LOCK_UNLOCKED(batched_entropy_u64.lock), @@ -2297,15 +2297,6 @@ u64 get_random_u64(void) struct batched_entropy *batch; static void *previous; -#if BITS_PER_LONG == 64 - if (arch_get_random_long((unsigned long *)&ret)) - return ret; -#else - if (arch_get_random_long((unsigned long *)&ret) && - arch_get_random_long((unsigned long *)&ret + 1)) - return ret; -#endif - warn_unseeded_randomness(&previous); batch = raw_cpu_ptr(&batched_entropy_u64); @@ -2330,9 +2321,6 @@ u32 get_random_u32(void) struct batched_entropy *batch; static void *previous; - if (arch_get_random_int(&ret)) - return ret; - warn_unseeded_randomness(&previous); batch = raw_cpu_ptr(&batched_entropy_u32); From patchwork Sat Apr 11 12:09:18 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228009 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.8 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,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 BCB8AC2BA2B for ; Sat, 11 Apr 2020 12:26:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 893C220644 for ; Sat, 11 Apr 2020 12:26:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607970; bh=eDlxJIK+ajyAnrucoaBRW3ShFGqsrmf8FtcH3vNKYgc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=Ylkv0W7cKQAo6Wnbis+/jkfjWo9Otlruwc5iC2sWcr/t0RqLA+Liq7reCIShcY/HY tttzTzg007T1RNX7ExreL8+3ZxGAeQKYwSgXLv5cgA6ud3LP6ei/7gMZ9P9a2S2RdC Bjo5fD7FtInZlRwWLn2xRhOVxW5IJ3fjo1P7YMyU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728173AbgDKMPs (ORCPT ); Sat, 11 Apr 2020 08:15:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:49850 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728184AbgDKMPq (ORCPT ); Sat, 11 Apr 2020 08:15:46 -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 686D820644; Sat, 11 Apr 2020 12:15:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607346; bh=eDlxJIK+ajyAnrucoaBRW3ShFGqsrmf8FtcH3vNKYgc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MabmURGBp/Mz2S0P6QWurpIWiOYQHg8GxL/9r+NuavWUIGXoF3D1KRUzrBf/tOt97 UgLoex0fGKsb7Q7+3vpkYXsq/S/KuGv3USz6iJW/wbam2qJhG8FA7xKA5nw/FQT4td JP/mhoR6z9WUWHy3v1/vGxk82JSMd0Ue7UXxQXmg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Thinh Nguyen , Felipe Balbi Subject: [PATCH 4.19 36/54] usb: dwc3: gadget: Wrap around when skip TRBs Date: Sat, 11 Apr 2020 14:09:18 +0200 Message-Id: <20200411115512.087843119@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Thinh Nguyen commit 2dedea035ae82c5af0595637a6eda4655532b21e upstream. When skipping TRBs, we need to account for wrapping around the ring buffer and not modifying some invalid TRBs. Without this fix, dwc3 won't be able to check for available TRBs. Cc: stable Fixes: 7746a8dfb3f9 ("usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs()") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman --- drivers/usb/dwc3/gadget.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1369,7 +1369,7 @@ static void dwc3_gadget_ep_skip_trbs(str for (i = 0; i < req->num_trbs; i++) { struct dwc3_trb *trb; - trb = req->trb + i; + trb = &dep->trb_pool[dep->trb_dequeue]; trb->ctrl &= ~DWC3_TRB_CTRL_HWO; dwc3_ep_inc_deq(dep); } From patchwork Sat Apr 11 12:09:19 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228083 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.8 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, 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 4FE80C2BB85 for ; Sat, 11 Apr 2020 12:15:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 24F9220787 for ; Sat, 11 Apr 2020 12:15:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607351; bh=4+TtjYr36O5SbE+Sa5S/2ejVsVC84drhWt7x+7rn2KI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=zAB4dWKh/PYHqI2qZ9dQloyKZjaBDRfs9dVUpsUG15eFDKUxDPKUIs195611yVTCC DY35XzPbX4rFrolHgPUZYPgFZXVAUaXgyIpxoky52b53uH1Pdmk2kbsRlMfKek7gg2 xsGaT8bkqxOY7skF+9nnplUgwCsM3tbSm18E3XKk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728191AbgDKMPt (ORCPT ); Sat, 11 Apr 2020 08:15:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:49908 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727238AbgDKMPt (ORCPT ); Sat, 11 Apr 2020 08:15:49 -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 CD74120644; Sat, 11 Apr 2020 12:15:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607349; bh=4+TtjYr36O5SbE+Sa5S/2ejVsVC84drhWt7x+7rn2KI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CtZTyPkfFdYNZHRFcz/9NKVg99l9pmVFAx5JKqmUCJoq1hjXeDJ9jO0QLqBKg1VzP 5J812BTt6Ho31L/m4qGz+bKewpkCsgnL3IpaRfVdNSqBlSe5bc0iMfoUvCdWe791Ws NjLsIjWlwDp6SXhQ+7t5dshSIN5NOjFsA4cA/T94= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yafang Shao , David Ahern , Andrew Morton , Johannes Berg , Shailabh Nagar , Linus Torvalds Subject: [PATCH 4.19 37/54] tools/accounting/getdelays.c: fix netlink attribute length Date: Sat, 11 Apr 2020 14:09:19 +0200 Message-Id: <20200411115512.207596545@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: David Ahern commit 4054ab64e29bb05b3dfe758fff3c38a74ba753bb upstream. A recent change to the netlink code: 6e237d099fac ("netlink: Relax attr validation for fixed length types") logs a warning when programs send messages with invalid attributes (e.g., wrong length for a u32). Yafang reported this error message for tools/accounting/getdelays.c. send_cmd() is wrongly adding 1 to the attribute length. As noted in include/uapi/linux/netlink.h nla_len should be NLA_HDRLEN + payload length, so drop the +1. Fixes: 9e06d3f9f6b1 ("per task delay accounting taskstats interface: documentation fix") Reported-by: Yafang Shao Signed-off-by: David Ahern Signed-off-by: Andrew Morton Tested-by: Yafang Shao Cc: Johannes Berg Cc: Shailabh Nagar Cc: Link: http://lkml.kernel.org/r/20200327173111.63922-1-dsahern@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- tools/accounting/getdelays.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/accounting/getdelays.c +++ b/tools/accounting/getdelays.c @@ -136,7 +136,7 @@ static int send_cmd(int sd, __u16 nlmsg_ msg.g.version = 0x1; na = (struct nlattr *) GENLMSG_DATA(&msg); na->nla_type = nla_type; - na->nla_len = nla_len + 1 + NLA_HDRLEN; + na->nla_len = nla_len + NLA_HDRLEN; memcpy(NLA_DATA(na), nla_data, nla_len); msg.n.nlmsg_len += NLMSG_ALIGN(na->nla_len); From patchwork Sat Apr 11 12:09:21 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228010 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.8 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,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 956DFC2BA2B for ; Sat, 11 Apr 2020 12:26:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 605E020644 for ; Sat, 11 Apr 2020 12:26:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607963; bh=s0u7lDLLVe++4Weesyk9XvhvqRchgRX/r1SYmiD7pWo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=AKTL5x7fP83Pc9VadXbDFGtQaQlcOlimN/foi+GHGgKbf/KGOsl2YOj8z9lNhhdJp fNDZHyQxO1+tJYmccJFMsPHhKAvMLiRbn3UrfXKFz1cKpXKaKDd7bkpV1hi45w+CBd G+YC9SIJhpy1yYYoZ4cULCVWMs5sie395KIbP0uw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727880AbgDKMPy (ORCPT ); Sat, 11 Apr 2020 08:15:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:50044 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728215AbgDKMPy (ORCPT ); Sat, 11 Apr 2020 08:15:54 -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 AFEC320787; Sat, 11 Apr 2020 12:15:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607354; bh=s0u7lDLLVe++4Weesyk9XvhvqRchgRX/r1SYmiD7pWo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O0wRSDRv37uOySErELb8XBCpIk2npJjZwzHqvhKYO09268bYaoDh370893xsqXsyX //VnQH+Rvg82y20vsWj/cBRHZ4WFEMmxoSnTNP/ZoN0TL0ptJ0OT7LkAybKxgVY5tY nBJhdaZFm8vNgZQtbzmzUD4Vqn5k8x9XOTfCvuxA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Paul Cercueil , Mark Brown Subject: [PATCH 4.19 39/54] ASoC: jz4740-i2s: Fix divider written at incorrect offset in register Date: Sat, 11 Apr 2020 14:09:21 +0200 Message-Id: <20200411115512.445236380@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Paul Cercueil commit 9401d5aa328e64617d87abd59af1c91cace4c3e4 upstream. The 4-bit divider value was written at offset 8, while the jz4740 programming manual locates it at offset 0. Fixes: 26b0aad80a86 ("ASoC: jz4740: Add dynamic sampling rate support to jz4740-i2s") Signed-off-by: Paul Cercueil Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200306222931.39664-2-paul@crapouillou.net Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman --- sound/soc/jz4740/jz4740-i2s.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/sound/soc/jz4740/jz4740-i2s.c +++ b/sound/soc/jz4740/jz4740-i2s.c @@ -92,7 +92,7 @@ #define JZ_AIC_I2S_STATUS_BUSY BIT(2) #define JZ_AIC_CLK_DIV_MASK 0xf -#define I2SDIV_DV_SHIFT 8 +#define I2SDIV_DV_SHIFT 0 #define I2SDIV_DV_MASK (0xf << I2SDIV_DV_SHIFT) #define I2SDIV_IDV_SHIFT 8 #define I2SDIV_IDV_MASK (0xf << I2SDIV_IDV_SHIFT) From patchwork Sat Apr 11 12:09:23 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228011 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.8 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,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 05058C2BBC7 for ; Sat, 11 Apr 2020 12:26:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CF1B020644 for ; Sat, 11 Apr 2020 12:26:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607961; bh=9/F1HgN1yJlGKSkllksxsM4rLDTTAM51nN0ITD+mQ4A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=HfqGuRNeaJAq9nBPeeVq9hOmuI26dUWaVyOVodCUgj3ADWDm1z5v4VxL0M6/XoE3r uwLPP5Cg2M0RWZhIOEuTHXO8gCL5RJ8wo8zo4jH+nuUGewiv8rrRyy6dqizECuTC1r gZ8RiKn0VrjRWdHVzvJj4XFlFL29ZH58UHgYex+A= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728228AbgDKMP7 (ORCPT ); Sat, 11 Apr 2020 08:15:59 -0400 Received: from mail.kernel.org ([198.145.29.99]:50148 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728222AbgDKMP7 (ORCPT ); Sat, 11 Apr 2020 08:15:59 -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 88EF520787; Sat, 11 Apr 2020 12:15:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607359; bh=9/F1HgN1yJlGKSkllksxsM4rLDTTAM51nN0ITD+mQ4A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Htw6t2qu9PYhmekiuW2t2rdqtu1t83oMGRDWEl3is8X3MZZhFyOqBDEi3Nvg2GcsI CgjT6UcmAwuEKIscYfWSFz0ceVvhUPn5NtqBIsvpLiKWRW2+JAY1pbLRvDOK8ZQnK1 QKqeuiFO/X2Q0UIJDYy7PJZKANDutXQzvi9PiRQ0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mike Marciniszyn , Kaike Wan , Dennis Dalessandro , Jason Gunthorpe Subject: [PATCH 4.19 41/54] IB/hfi1: Fix memory leaks in sysfs registration and unregistration Date: Sat, 11 Apr 2020 14:09:23 +0200 Message-Id: <20200411115512.696605410@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Kaike Wan commit 5c15abc4328ad696fa61e2f3604918ed0c207755 upstream. When the hfi1 driver is unloaded, kmemleak will report the following issue: unreferenced object 0xffff8888461a4c08 (size 8): comm "kworker/0:0", pid 5, jiffies 4298601264 (age 2047.134s) hex dump (first 8 bytes): 73 64 6d 61 30 00 ff ff sdma0... backtrace: [<00000000311a6ef5>] kvasprintf+0x62/0xd0 [<00000000ade94d9f>] kobject_set_name_vargs+0x1c/0x90 [<0000000060657dbb>] kobject_init_and_add+0x5d/0xb0 [<00000000346fe72b>] 0xffffffffa0c5ecba [<000000006cfc5819>] 0xffffffffa0c866b9 [<0000000031c65580>] 0xffffffffa0c38e87 [<00000000e9739b3f>] local_pci_probe+0x41/0x80 [<000000006c69911d>] work_for_cpu_fn+0x16/0x20 [<00000000601267b5>] process_one_work+0x171/0x380 [<0000000049a0eefa>] worker_thread+0x1d1/0x3f0 [<00000000909cf2b9>] kthread+0xf8/0x130 [<0000000058f5f874>] ret_from_fork+0x35/0x40 This patch fixes the issue by: - Releasing dd->per_sdma[i].kobject in hfi1_unregister_sysfs(). - This will fix the memory leak. - Calling kobject_put() to unwind operations only for those entries in dd->per_sdma[] whose operations have succeeded (including the current one that has just failed) in hfi1_verbs_register_sysfs(). Cc: Fixes: 0cb2aa690c7e ("IB/hfi1: Add sysfs interface for affinity setup") Link: https://lore.kernel.org/r/20200326163807.21129.27371.stgit@awfm-01.aw.intel.com Reviewed-by: Mike Marciniszyn Signed-off-by: Kaike Wan Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman --- drivers/infiniband/hw/hfi1/sysfs.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/drivers/infiniband/hw/hfi1/sysfs.c +++ b/drivers/infiniband/hw/hfi1/sysfs.c @@ -861,8 +861,13 @@ bail: for (i = 0; i < ARRAY_SIZE(hfi1_attributes); ++i) device_remove_file(&dev->dev, hfi1_attributes[i]); - for (i = 0; i < dd->num_sdma; i++) - kobject_del(&dd->per_sdma[i].kobj); + /* + * The function kobject_put() will call kobject_del() if the kobject + * has been added successfully. The sysfs files created under the + * kobject directory will also be removed during the process. + */ + for (; i >= 0; i--) + kobject_put(&dd->per_sdma[i].kobj); return ret; } @@ -875,6 +880,10 @@ void hfi1_verbs_unregister_sysfs(struct struct hfi1_pportdata *ppd; int i; + /* Unwind operations in hfi1_verbs_register_sysfs() */ + for (i = 0; i < dd->num_sdma; i++) + kobject_put(&dd->per_sdma[i].kobj); + for (i = 0; i < dd->num_pports; i++) { ppd = &dd->pport[i]; From patchwork Sat Apr 11 12:09:26 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228012 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=-4.0 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, UNWANTED_LANGUAGE_BODY, 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 3A1EFC2BBC7 for ; Sat, 11 Apr 2020 12:25:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EE88420644 for ; Sat, 11 Apr 2020 12:25:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607956; bh=GJbNefvUwMlJrQducROtdksojVFFnS7Ma6pcTY09hLU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=EXe9SYI51nzDCJ9WQtJagMkgFsxY0jrllXcPPjrT5dC9esLbCrr2KQkSmGf5vjb2L m05YC4pE5KVAt7Xir/3dE68ETgqAt9RxU8AXcQjmMpSo6Y4it9EmsXUUAiJXD28MRZ Vol7asOJxUsycbkHDDj+Kjf6+NEUInYHKX64m+hg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728289AbgDKMZy (ORCPT ); Sat, 11 Apr 2020 08:25:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:50292 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727942AbgDKMQG (ORCPT ); Sat, 11 Apr 2020 08:16:06 -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 8904621775; Sat, 11 Apr 2020 12:16:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607366; bh=GJbNefvUwMlJrQducROtdksojVFFnS7Ma6pcTY09hLU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M5dgroqk8VQcAY8VR0F2FAlGSoxDqfCxc5U0RFA7PEUo/34WWQuPQ+9GZd641Umo+ hSDR6fa4Ko6CgGgjrOr8tQPUqgODLpDzzGiau6PaGnkD3AnN53Ok98zeRjd2mV18Lb u8CcYpu9+pVoJLCEmbZ5oboWi+VdLccL+QCTLbLM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+adb15cf8c2798e4e0db4@syzkaller.appspotmail.com, syzbot+e5579222b6a3edd96522@syzkaller.appspotmail.com, syzbot+4b628fcc748474003457@syzkaller.appspotmail.com, syzbot+29ee8f76017ce6cf03da@syzkaller.appspotmail.com, syzbot+6956235342b7317ec564@syzkaller.appspotmail.com, syzbot+b358909d8d01556b790b@syzkaller.appspotmail.com, syzbot+6b46b135602a3f3ac99e@syzkaller.appspotmail.com, syzbot+8458d13b13562abf6b77@syzkaller.appspotmail.com, syzbot+bd034f3fdc0402e942ed@syzkaller.appspotmail.com, syzbot+c92378b32760a4eef756@syzkaller.appspotmail.com, syzbot+68b44a1597636e0b342c@syzkaller.appspotmail.com, Jason Gunthorpe Subject: [PATCH 4.19 44/54] RDMA/ucma: Put a lock around every call to the rdma_cm layer Date: Sat, 11 Apr 2020 14:09:26 +0200 Message-Id: <20200411115513.031279873@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Jason Gunthorpe commit 7c11910783a1ea17e88777552ef146cace607b3c upstream. The rdma_cm must be used single threaded. This appears to be a bug in the design, as it does have lots of locking that seems like it should allow concurrency. However, when it is all said and done every single place that uses the cma_exch() scheme is broken, and all the unlocked reads from the ucma of the cm_id data are wrong too. syzkaller has been finding endless bugs related to this. Fixing this in any elegant way is some enormous amount of work. Take a very big hammer and put a mutex around everything to do with the ucma_context at the top of every syscall. Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace") Link: https://lore.kernel.org/r/20200218210432.GA31966@ziepe.ca Reported-by: syzbot+adb15cf8c2798e4e0db4@syzkaller.appspotmail.com Reported-by: syzbot+e5579222b6a3edd96522@syzkaller.appspotmail.com Reported-by: syzbot+4b628fcc748474003457@syzkaller.appspotmail.com Reported-by: syzbot+29ee8f76017ce6cf03da@syzkaller.appspotmail.com Reported-by: syzbot+6956235342b7317ec564@syzkaller.appspotmail.com Reported-by: syzbot+b358909d8d01556b790b@syzkaller.appspotmail.com Reported-by: syzbot+6b46b135602a3f3ac99e@syzkaller.appspotmail.com Reported-by: syzbot+8458d13b13562abf6b77@syzkaller.appspotmail.com Reported-by: syzbot+bd034f3fdc0402e942ed@syzkaller.appspotmail.com Reported-by: syzbot+c92378b32760a4eef756@syzkaller.appspotmail.com Reported-by: syzbot+68b44a1597636e0b342c@syzkaller.appspotmail.com Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman --- drivers/infiniband/core/ucma.c | 49 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 47 insertions(+), 2 deletions(-) --- a/drivers/infiniband/core/ucma.c +++ b/drivers/infiniband/core/ucma.c @@ -89,6 +89,7 @@ struct ucma_context { struct ucma_file *file; struct rdma_cm_id *cm_id; + struct mutex mutex; u64 uid; struct list_head list; @@ -215,6 +216,7 @@ static struct ucma_context *ucma_alloc_c init_completion(&ctx->comp); INIT_LIST_HEAD(&ctx->mc_list); ctx->file = file; + mutex_init(&ctx->mutex); mutex_lock(&mut); ctx->id = idr_alloc(&ctx_idr, ctx, 0, 0, GFP_KERNEL); @@ -596,6 +598,7 @@ static int ucma_free_ctx(struct ucma_con } events_reported = ctx->events_reported; + mutex_destroy(&ctx->mutex); kfree(ctx); return events_reported; } @@ -665,7 +668,10 @@ static ssize_t ucma_bind_ip(struct ucma_ if (IS_ERR(ctx)) return PTR_ERR(ctx); + mutex_lock(&ctx->mutex); ret = rdma_bind_addr(ctx->cm_id, (struct sockaddr *) &cmd.addr); + mutex_unlock(&ctx->mutex); + ucma_put_ctx(ctx); return ret; } @@ -688,7 +694,9 @@ static ssize_t ucma_bind(struct ucma_fil if (IS_ERR(ctx)) return PTR_ERR(ctx); + mutex_lock(&ctx->mutex); ret = rdma_bind_addr(ctx->cm_id, (struct sockaddr *) &cmd.addr); + mutex_unlock(&ctx->mutex); ucma_put_ctx(ctx); return ret; } @@ -712,8 +720,10 @@ static ssize_t ucma_resolve_ip(struct uc if (IS_ERR(ctx)) return PTR_ERR(ctx); + mutex_lock(&ctx->mutex); ret = rdma_resolve_addr(ctx->cm_id, (struct sockaddr *) &cmd.src_addr, (struct sockaddr *) &cmd.dst_addr, cmd.timeout_ms); + mutex_unlock(&ctx->mutex); ucma_put_ctx(ctx); return ret; } @@ -738,8 +748,10 @@ static ssize_t ucma_resolve_addr(struct if (IS_ERR(ctx)) return PTR_ERR(ctx); + mutex_lock(&ctx->mutex); ret = rdma_resolve_addr(ctx->cm_id, (struct sockaddr *) &cmd.src_addr, (struct sockaddr *) &cmd.dst_addr, cmd.timeout_ms); + mutex_unlock(&ctx->mutex); ucma_put_ctx(ctx); return ret; } @@ -759,7 +771,9 @@ static ssize_t ucma_resolve_route(struct if (IS_ERR(ctx)) return PTR_ERR(ctx); + mutex_lock(&ctx->mutex); ret = rdma_resolve_route(ctx->cm_id, cmd.timeout_ms); + mutex_unlock(&ctx->mutex); ucma_put_ctx(ctx); return ret; } @@ -848,6 +862,7 @@ static ssize_t ucma_query_route(struct u if (IS_ERR(ctx)) return PTR_ERR(ctx); + mutex_lock(&ctx->mutex); memset(&resp, 0, sizeof resp); addr = (struct sockaddr *) &ctx->cm_id->route.addr.src_addr; memcpy(&resp.src_addr, addr, addr->sa_family == AF_INET ? @@ -871,6 +886,7 @@ static ssize_t ucma_query_route(struct u ucma_copy_iw_route(&resp, &ctx->cm_id->route); out: + mutex_unlock(&ctx->mutex); if (copy_to_user(u64_to_user_ptr(cmd.response), &resp, sizeof(resp))) ret = -EFAULT; @@ -1022,6 +1038,7 @@ static ssize_t ucma_query(struct ucma_fi if (IS_ERR(ctx)) return PTR_ERR(ctx); + mutex_lock(&ctx->mutex); switch (cmd.option) { case RDMA_USER_CM_QUERY_ADDR: ret = ucma_query_addr(ctx, response, out_len); @@ -1036,6 +1053,7 @@ static ssize_t ucma_query(struct ucma_fi ret = -ENOSYS; break; } + mutex_unlock(&ctx->mutex); ucma_put_ctx(ctx); return ret; @@ -1076,7 +1094,9 @@ static ssize_t ucma_connect(struct ucma_ return PTR_ERR(ctx); ucma_copy_conn_param(ctx->cm_id, &conn_param, &cmd.conn_param); + mutex_lock(&ctx->mutex); ret = rdma_connect(ctx->cm_id, &conn_param); + mutex_unlock(&ctx->mutex); ucma_put_ctx(ctx); return ret; } @@ -1097,7 +1117,9 @@ static ssize_t ucma_listen(struct ucma_f ctx->backlog = cmd.backlog > 0 && cmd.backlog < max_backlog ? cmd.backlog : max_backlog; + mutex_lock(&ctx->mutex); ret = rdma_listen(ctx->cm_id, ctx->backlog); + mutex_unlock(&ctx->mutex); ucma_put_ctx(ctx); return ret; } @@ -1120,13 +1142,17 @@ static ssize_t ucma_accept(struct ucma_f if (cmd.conn_param.valid) { ucma_copy_conn_param(ctx->cm_id, &conn_param, &cmd.conn_param); mutex_lock(&file->mut); + mutex_lock(&ctx->mutex); ret = __rdma_accept(ctx->cm_id, &conn_param, NULL); + mutex_unlock(&ctx->mutex); if (!ret) ctx->uid = cmd.uid; mutex_unlock(&file->mut); - } else + } else { + mutex_lock(&ctx->mutex); ret = __rdma_accept(ctx->cm_id, NULL, NULL); - + mutex_unlock(&ctx->mutex); + } ucma_put_ctx(ctx); return ret; } @@ -1145,7 +1171,9 @@ static ssize_t ucma_reject(struct ucma_f if (IS_ERR(ctx)) return PTR_ERR(ctx); + mutex_lock(&ctx->mutex); ret = rdma_reject(ctx->cm_id, cmd.private_data, cmd.private_data_len); + mutex_unlock(&ctx->mutex); ucma_put_ctx(ctx); return ret; } @@ -1164,7 +1192,9 @@ static ssize_t ucma_disconnect(struct uc if (IS_ERR(ctx)) return PTR_ERR(ctx); + mutex_lock(&ctx->mutex); ret = rdma_disconnect(ctx->cm_id); + mutex_unlock(&ctx->mutex); ucma_put_ctx(ctx); return ret; } @@ -1195,7 +1225,9 @@ static ssize_t ucma_init_qp_attr(struct resp.qp_attr_mask = 0; memset(&qp_attr, 0, sizeof qp_attr); qp_attr.qp_state = cmd.qp_state; + mutex_lock(&ctx->mutex); ret = rdma_init_qp_attr(ctx->cm_id, &qp_attr, &resp.qp_attr_mask); + mutex_unlock(&ctx->mutex); if (ret) goto out; @@ -1274,9 +1306,13 @@ static int ucma_set_ib_path(struct ucma_ struct sa_path_rec opa; sa_convert_path_ib_to_opa(&opa, &sa_path); + mutex_lock(&ctx->mutex); ret = rdma_set_ib_path(ctx->cm_id, &opa); + mutex_unlock(&ctx->mutex); } else { + mutex_lock(&ctx->mutex); ret = rdma_set_ib_path(ctx->cm_id, &sa_path); + mutex_unlock(&ctx->mutex); } if (ret) return ret; @@ -1309,7 +1345,9 @@ static int ucma_set_option_level(struct switch (level) { case RDMA_OPTION_ID: + mutex_lock(&ctx->mutex); ret = ucma_set_option_id(ctx, optname, optval, optlen); + mutex_unlock(&ctx->mutex); break; case RDMA_OPTION_IB: ret = ucma_set_option_ib(ctx, optname, optval, optlen); @@ -1369,8 +1407,10 @@ static ssize_t ucma_notify(struct ucma_f if (IS_ERR(ctx)) return PTR_ERR(ctx); + mutex_lock(&ctx->mutex); if (ctx->cm_id->device) ret = rdma_notify(ctx->cm_id, (enum ib_event_type)cmd.event); + mutex_unlock(&ctx->mutex); ucma_put_ctx(ctx); return ret; @@ -1413,8 +1453,10 @@ static ssize_t ucma_process_join(struct mc->join_state = join_state; mc->uid = cmd->uid; memcpy(&mc->addr, addr, cmd->addr_size); + mutex_lock(&ctx->mutex); ret = rdma_join_multicast(ctx->cm_id, (struct sockaddr *)&mc->addr, join_state, mc); + mutex_unlock(&ctx->mutex); if (ret) goto err2; @@ -1518,7 +1560,10 @@ static ssize_t ucma_leave_multicast(stru goto out; } + mutex_lock(&mc->ctx->mutex); rdma_leave_multicast(mc->ctx->cm_id, (struct sockaddr *) &mc->addr); + mutex_unlock(&mc->ctx->mutex); + mutex_lock(&mc->ctx->file->mut); ucma_cleanup_mc_events(mc); list_del(&mc->list); From patchwork Sat Apr 11 12:09:28 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228081 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.8 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, 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 32BD6C2BA2B for ; Sat, 11 Apr 2020 12:16:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 092192084D for ; Sat, 11 Apr 2020 12:16:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607384; bh=Jttk726tXOUzFy4Zy+whTq1rsrkJW0mjXnvp9/CaKi0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=m7I0YFO+KAwf0CGh2OG/koHRdr0Vhp2M1PudUBx3tv1YdNS/yiYaimod39indj5Sn k+UsdytTHlTE/M2fuTGFWcevr0pvRdSZ5Ndur8E4/0QwM5vw1NYJmqAgdnQWdvxaSP M6mhDojPoW7LN1m4ty9sfKFNl/QfCvW7mXYzy1Vo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727920AbgDKMQW (ORCPT ); Sat, 11 Apr 2020 08:16:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:50408 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727528AbgDKMQN (ORCPT ); Sat, 11 Apr 2020 08:16:13 -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 DCE8E2084D; Sat, 11 Apr 2020 12:16:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607373; bh=Jttk726tXOUzFy4Zy+whTq1rsrkJW0mjXnvp9/CaKi0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LMlUKTXeqEWBGod6wgAvObK0U/AdDz0ZL0tD3LepP55ikEQxwVwnRJ3Q3JrEBV0Tt TzdVus5bNOFZYOiqQ/xRJklH6SVPSA2hOZ8yjS2lduLQw9/iiFz7+eDRl3DzMTPaUc 6cD+yB9wD+PG9rPJPJv61O3vJXLOyNANsV4JF4/8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+4496e82090657320efc6@syzkaller.appspotmail.com, Qiujun Huang , Hillf Danton , Marcel Holtmann Subject: [PATCH 4.19 46/54] Bluetooth: RFCOMM: fix ODEBUG bug in rfcomm_dev_ioctl Date: Sat, 11 Apr 2020 14:09:28 +0200 Message-Id: <20200411115513.335400701@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Qiujun Huang commit 71811cac8532b2387b3414f7cd8fe9e497482864 upstream. Needn't call 'rfcomm_dlc_put' here, because 'rfcomm_dlc_exists' didn't increase dlc->refcnt. Reported-by: syzbot+4496e82090657320efc6@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang Suggested-by: Hillf Danton Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman --- net/bluetooth/rfcomm/tty.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/net/bluetooth/rfcomm/tty.c +++ b/net/bluetooth/rfcomm/tty.c @@ -413,10 +413,8 @@ static int __rfcomm_create_dev(struct so dlc = rfcomm_dlc_exists(&req.src, &req.dst, req.channel); if (IS_ERR(dlc)) return PTR_ERR(dlc); - else if (dlc) { - rfcomm_dlc_put(dlc); + if (dlc) return -EBUSY; - } dlc = rfcomm_dlc_alloc(GFP_KERNEL); if (!dlc) return -ENOMEM; From patchwork Sat Apr 11 12:09:31 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228013 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.8 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,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 BBF83C2BB85 for ; Sat, 11 Apr 2020 12:25:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9118E20644 for ; Sat, 11 Apr 2020 12:25:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607951; bh=D7XvoFat6Y1aaR78hihBtrrJf1Mq8fezeVUfL892XaA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=V7p+acxXQ2mU+XDHIq3WdGOtdMwUbQdah3WsNLx1d6ycjCWkVXVFXggV9LfeYu6Mb S3SCKEymrpEnek7oduKEv55+F/z9pQPuL1MmGYx/f3lg5iEtH7y/ldwjCKspID4NlO 2PUEVyf6ipIffwxuoUt1YVSvvlhqB/W3/MlYEsVA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728495AbgDKMZr (ORCPT ); Sat, 11 Apr 2020 08:25:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:50588 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727173AbgDKMQU (ORCPT ); Sat, 11 Apr 2020 08:16:20 -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 21E3E2084D; Sat, 11 Apr 2020 12:16:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607380; bh=D7XvoFat6Y1aaR78hihBtrrJf1Mq8fezeVUfL892XaA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GAkJCynojTPYGelPuoeqZBh9VnpaYMF8B61Sh8rA5tbqHbo98Xp6ZQk5NXiS1waow dVjA1GNRPxXjjXbboRf1r5kUgV6aDTSIB+B+dLZci17KvSVM0eyfVbyaznmwTmLu3t ns+3ZLvODaaujbKvnuxTJaZ+1xWUf+QEyj7oi+SY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Taniya Das , Stephen Boyd , Lee Jones Subject: [PATCH 4.19 49/54] clk: qcom: rcg: Return failure for RCG update Date: Sat, 11 Apr 2020 14:09:31 +0200 Message-Id: <20200411115513.623424955@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Taniya Das commit 21ea4b62e1f3dc258001a68da98c9663a9dbd6c7 upstream. In case of update config failure, return -EBUSY, so that consumers could handle the failure gracefully. Signed-off-by: Taniya Das Link: https://lkml.kernel.org/r/1557339895-21952-2-git-send-email-tdas@codeaurora.org Signed-off-by: Stephen Boyd Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman --- drivers/clk/qcom/clk-rcg2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/clk/qcom/clk-rcg2.c +++ b/drivers/clk/qcom/clk-rcg2.c @@ -105,7 +105,7 @@ static int update_config(struct clk_rcg2 } WARN(1, "%s: rcg didn't update its configuration.", name); - return 0; + return -EBUSY; } static int clk_rcg2_set_parent(struct clk_hw *hw, u8 index) From patchwork Sat Apr 11 12:09:32 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228014 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.8 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,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 6DF16C2BB85 for ; Sat, 11 Apr 2020 12:25:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 45CC120644 for ; Sat, 11 Apr 2020 12:25:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607947; bh=tUsy8aF3aWK+tl2tlF53A4wyBaFqQHwl9Hs+toAEKpE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=YU+hupll5vNP8pSCX4/no6NgBn+Rvu+l5sGQrMwRUw3aKbgse51QtF1T9zVWmgYNV OaE4OmQEAe8yoXnw+2SnGN98Ekl0D6E7KUMISklFnoVHl3J+FqxGrhPquXwFdeb2DD +bVoE3kdxljlNitF84bD54jjpFf3OC/q1liADBJA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728369AbgDKMZm (ORCPT ); Sat, 11 Apr 2020 08:25:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:50640 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728039AbgDKMQX (ORCPT ); Sat, 11 Apr 2020 08:16:23 -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 852FE20692; Sat, 11 Apr 2020 12:16:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607383; bh=tUsy8aF3aWK+tl2tlF53A4wyBaFqQHwl9Hs+toAEKpE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oVvZWNlI1bhVtXViaflGG4P2qLxYF3MXhArsg/XAJCNDV2+w7TaMwi0gZL+SYrv9H x1/PRkGqwLtRlejGXnM4gn0S7ZMVmmUGk2YIysreN8g3AUVfRf6Jgux3fqfcNP9+TY uA6tIZyoyqGxz8oVLvfVhLvXrl6HXeBr+Phz4keM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stephen Boyd , Stephen Boyd , Jordan Crouse , Rob Clark , Sean Paul , Lee Jones Subject: [PATCH 4.19 50/54] drm/msm: stop abusing dma_map/unmap for cache Date: Sat, 11 Apr 2020 14:09:32 +0200 Message-Id: <20200411115513.709554942@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Rob Clark commit 0036bc73ccbe7e600a3468bf8e8879b122252274 upstream. Recently splats like this started showing up: WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451 __iommu_dma_unmap+0xb8/0xc0 Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo cfg80211 videobuf2_vmalloc videobuf2_memops vide CPU: 4 PID: 251 Comm: kworker/u16:4 Tainted: G W 5.2.0-rc5-next-20190619+ #2317 Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN23WW(V1.06) 10/25/2018 Workqueue: msm msm_gem_free_work [msm] pstate: 80c00005 (Nzcv daif +PAN +UAO) pc : __iommu_dma_unmap+0xb8/0xc0 lr : __iommu_dma_unmap+0x54/0xc0 sp : ffff0000119abce0 x29: ffff0000119abce0 x28: 0000000000000000 x27: ffff8001f9946648 x26: ffff8001ec271068 x25: 0000000000000000 x24: ffff8001ea3580a8 x23: ffff8001f95ba010 x22: ffff80018e83ba88 x21: ffff8001e548f000 x20: fffffffffffff000 x19: 0000000000001000 x18: 00000000c00001fe x17: 0000000000000000 x16: 0000000000000000 x15: ffff000015b70068 x14: 0000000000000005 x13: 0003142cc1be1768 x12: 0000000000000001 x11: ffff8001f6de9100 x10: 0000000000000009 x9 : ffff000015b78000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : fffffffffffff000 x5 : 0000000000000fff x4 : ffff00001065dbc8 x3 : 000000000000000d x2 : 0000000000001000 x1 : fffffffffffff000 x0 : 0000000000000000 Call trace: __iommu_dma_unmap+0xb8/0xc0 iommu_dma_unmap_sg+0x98/0xb8 put_pages+0x5c/0xf0 [msm] msm_gem_free_work+0x10c/0x150 [msm] process_one_work+0x1e0/0x330 worker_thread+0x40/0x438 kthread+0x12c/0x130 ret_from_fork+0x10/0x18 ---[ end trace afc0dc5ab81a06bf ]--- Not quite sure what triggered that, but we really shouldn't be abusing dma_{map,unmap}_sg() for cache maint. Cc: Stephen Boyd Tested-by: Stephen Boyd Reviewed-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190630124735.27786-1-robdclark@gmail.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/msm/msm_gem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -108,7 +108,7 @@ static struct page **get_pages(struct dr * because display controller, GPU, etc. are not coherent: */ if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED)) - dma_map_sg(dev->dev, msm_obj->sgt->sgl, + dma_sync_sg_for_device(dev->dev, msm_obj->sgt->sgl, msm_obj->sgt->nents, DMA_BIDIRECTIONAL); } @@ -138,7 +138,7 @@ static void put_pages(struct drm_gem_obj * GPU, etc. are not coherent: */ if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED)) - dma_unmap_sg(obj->dev->dev, msm_obj->sgt->sgl, + dma_sync_sg_for_cpu(obj->dev->dev, msm_obj->sgt->sgl, msm_obj->sgt->nents, DMA_BIDIRECTIONAL); From patchwork Sat Apr 11 12:09:35 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228015 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.8 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,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 6F9DCC2BBC7 for ; Sat, 11 Apr 2020 12:25:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 47FBA20644 for ; Sat, 11 Apr 2020 12:25:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607937; bh=LBQh2jSmXbzmkaoK4ZF56odHDu/7JiZOCyaPgfGhdfw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=nI+DPE3+g7/RWxWzCfhWzGS0zdIjkeLL56c+C5AL8BHlHPjQt3D4Q/RtQl/Vc98AL fu46f6lhkkIwKQNujqmj6OxP4DGFHdfhMN6stDKUDM89fzOyZYBnsp0FJYRXBO7yOp oJ+DOfrY3l9dxbGJalqBEgIZ4u1BOymOT4BYBWpY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726872AbgDKMQc (ORCPT ); Sat, 11 Apr 2020 08:16:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:50774 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726643AbgDKMQa (ORCPT ); Sat, 11 Apr 2020 08:16:30 -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 C19CF20644; Sat, 11 Apr 2020 12:16:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607390; bh=LBQh2jSmXbzmkaoK4ZF56odHDu/7JiZOCyaPgfGhdfw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Is4R43PBaY8aK8xZGRZ5DW43wHwRBtzPZGETQfyI2dxPJvYKkOh7Ah73p3gbopRpe VRQuTQCMzJiiWNxu8RS/2h0VcaEbgTeBMynM0lWs+8uHXs2gv3rsv8pQxnc8HgdXrm MM/UdlVf4AXdFJqd15CB9n3JWIQ2UsGBsgDod5Lc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Roger Quadros , Felipe Balbi , Lee Jones Subject: [PATCH 4.19 53/54] usb: dwc3: dont set gadget->is_otg flag Date: Sat, 11 Apr 2020 14:09:35 +0200 Message-Id: <20200411115513.920621450@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115508.284500414@linuxfoundation.org> References: <20200411115508.284500414@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: Roger Quadros commit c09b73cfac2a9317f1104169045c519c6021aa1d upstream. This reverts commit 6a4290cc28be1 ("usb: dwc3: gadget: set the OTG flag in dwc3 gadget driver.") We don't yet support any of the OTG mechanisms (HNP/SRP/ADP) and are not setting gadget->otg_caps, so don't set gadget->is_otg flag. If we do then we end up publishing a OTG1.0 descriptor in the gadget descriptor which causes device enumeration to fail if we are connected to a host with CONFIG_USB_OTG enabled. Host side log without this patch [ 96.720453] usb 1-1: new high-speed USB device number 2 using xhci-hcd [ 96.901391] usb 1-1: Dual-Role OTG device on non-HNP port [ 96.907552] usb 1-1: set a_alt_hnp_support failed: -32 [ 97.060447] usb 1-1: new high-speed USB device number 3 using xhci-hcd [ 97.241378] usb 1-1: Dual-Role OTG device on non-HNP port [ 97.247536] usb 1-1: set a_alt_hnp_support failed: -32 [ 97.253606] usb usb1-port1: attempt power cycle [ 97.960449] usb 1-1: new high-speed USB device number 4 using xhci-hcd [ 98.141383] usb 1-1: Dual-Role OTG device on non-HNP port [ 98.147540] usb 1-1: set a_alt_hnp_support failed: -32 [ 98.300453] usb 1-1: new high-speed USB device number 5 using xhci-hcd [ 98.481391] usb 1-1: Dual-Role OTG device on non-HNP port [ 98.487545] usb 1-1: set a_alt_hnp_support failed: -32 [ 98.493532] usb usb1-port1: unable to enumerate USB device Signed-off-by: Roger Quadros Signed-off-by: Felipe Balbi Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman --- drivers/usb/dwc3/gadget.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -3166,7 +3166,6 @@ int dwc3_gadget_init(struct dwc3 *dwc) dwc->gadget.speed = USB_SPEED_UNKNOWN; dwc->gadget.sg_supported = true; dwc->gadget.name = "dwc3-gadget"; - dwc->gadget.is_otg = dwc->dr_mode == USB_DR_MODE_OTG; /* * FIXME We might be setting max_speed to