From patchwork Thu Oct 3 15:49:28 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175143 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp569023ill; Thu, 3 Oct 2019 09:39:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqzGcutqd/Bfupi+eAeVObNauJ25Ky+lGRvSCXHZkxjk34chWA6cDBz+64+F8D3DEdLL/2TB X-Received: by 2002:a05:6402:1a45:: with SMTP id bf5mr10243665edb.275.1570120761313; Thu, 03 Oct 2019 09:39:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570120761; cv=none; d=google.com; s=arc-20160816; b=UyFRGOa2HBFtmO2o6v9QKO5u9tUy8QMu0tqYdNko2KI4/CU74SI/1I+Z/Ecp0WMsqN YXyN0LSU/0f/GdZ+npAI0wTNkz+mP9C/sluBtV2KH/0T1Rv9Wp0nygsc6ODRRiB2dd4I xwjthrHDwmuTqhsUZglIBlIWl4O6Sm+YLsTQ8zYKRiLHdMa+ROatqnmgVlAQtFV1w0Vu /cz0a/QdU8wKzXaOoltcd3ehCZnwmxXMKhviXkDIZN0e1p1Pz//cGlxo2shk4bNAVFXa YTUMIU0geZmoewQBZ3IcNngUuITOzzUxW19ERb964Lfh8FpXvANpDeCMQLIbN1n8ZBgH HGIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=IQKa6JfM66a3dJn2xS/t3Fkh9JZJ54/vFGqhvlrKSKY=; b=d1j4YUSzlEVzz33go7h7Gip1XGluz+jHutYraFMShVg56hxBho6iGPUrElptQrPX1U bEJ2HIe/7PiOYY4kZ1TSqao2sxjdjRxAZtJ/tgMi2985Hpq7k6uv796POBWR6vH998xQ bELR523Qd5EM2lFDFV3cOuKvmzHb2+1GYTehc66ArzgXIEInw6ofx+zRKAkzT5EYhwXn PrXqDFXdBG+xRqi6clgEB/sCO0kGDAzjlSL1XONySL5L6Akj231cAxthve15OanBgCTI G80CakZTfEU5xqbcYag+l7UehuvNYX3iNFAn3zYCIZ1jY9yTNmY2Rgi2kP657xF0pmAs mP7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=jyKWV5yx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o27si1483647ejr.304.2019.10.03.09.39.21; Thu, 03 Oct 2019 09:39:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=jyKWV5yx; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404732AbfJCQjT (ORCPT + 27 others); Thu, 3 Oct 2019 12:39:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:49164 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404041AbfJCQjR (ORCPT ); Thu, 3 Oct 2019 12:39:17 -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 AC72E20830; Thu, 3 Oct 2019 16:39:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570120756; bh=LAc87+6+D18o5QYyIggT21SCRMDuq8+tv+1iJvp/tug=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jyKWV5yx4fbKIx4F/qLXM4q/xUirKOup1RpwXIjZZ/k3Qq10l/b0r4q3N16EYFX79 4KQ+lpC1RVZ5ZwOl5V/Zzn++PKibzSMoWH7d92Qty7pcOMbBhvgsOyDVQtilMkT+s0 0WO3QKJUIrPNWeovzGVoJfNHCHzlaf+oTtOY/pnI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Jason A. Donenfeld" , Wei Wang , "David S. Miller" Subject: [PATCH 5.3 003/344] ipv6: do not free rt if FIB_LOOKUP_NOREF is set on suppress rule Date: Thu, 3 Oct 2019 17:49:28 +0200 Message-Id: <20191003154540.394699981@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Jason A. Donenfeld" [ Upstream commit ca7a03c4175366a92cee0ccc4fec0038c3266e26 ] Commit 7d9e5f422150 removed references from certain dsts, but accounting for this never translated down into the fib6 suppression code. This bug was triggered by WireGuard users who use wg-quick(8), which uses the "suppress-prefix" directive to ip-rule(8) for routing all of their internet traffic without routing loops. The test case added here causes the reference underflow by causing packets to evaluate a suppress rule. Fixes: 7d9e5f422150 ("ipv6: convert major tx path to use RT6_LOOKUP_F_DST_NOREF") Signed-off-by: Jason A. Donenfeld Acked-by: Wei Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/ipv6/fib6_rules.c | 3 ++- tools/testing/selftests/net/fib_tests.sh | 17 ++++++++++++++++- 2 files changed, 18 insertions(+), 2 deletions(-) --- a/net/ipv6/fib6_rules.c +++ b/net/ipv6/fib6_rules.c @@ -287,7 +287,8 @@ static bool fib6_rule_suppress(struct fi return false; suppress_route: - ip6_rt_put(rt); + if (!(arg->flags & FIB_LOOKUP_NOREF)) + ip6_rt_put(rt); return true; } --- a/tools/testing/selftests/net/fib_tests.sh +++ b/tools/testing/selftests/net/fib_tests.sh @@ -9,7 +9,7 @@ ret=0 ksft_skip=4 # all tests in this script. Can be overridden with -t option -TESTS="unregister down carrier nexthop ipv6_rt ipv4_rt ipv6_addr_metric ipv4_addr_metric ipv6_route_metrics ipv4_route_metrics ipv4_route_v6_gw rp_filter" +TESTS="unregister down carrier nexthop suppress ipv6_rt ipv4_rt ipv6_addr_metric ipv4_addr_metric ipv6_route_metrics ipv4_route_metrics ipv4_route_v6_gw rp_filter" VERBOSE=0 PAUSE_ON_FAIL=no @@ -614,6 +614,20 @@ fib_nexthop_test() cleanup } +fib_suppress_test() +{ + $IP link add dummy1 type dummy + $IP link set dummy1 up + $IP -6 route add default dev dummy1 + $IP -6 rule add table main suppress_prefixlength 0 + ping -f -c 1000 -W 1 1234::1 || true + $IP -6 rule del table main suppress_prefixlength 0 + $IP link del dummy1 + + # If we got here without crashing, we're good. + return 0 +} + ################################################################################ # Tests on route add and replace @@ -1591,6 +1605,7 @@ do fib_carrier_test|carrier) fib_carrier_test;; fib_rp_filter_test|rp_filter) fib_rp_filter_test;; fib_nexthop_test|nexthop) fib_nexthop_test;; + fib_suppress_test|suppress) fib_suppress_test;; ipv6_route_test|ipv6_rt) ipv6_route_test;; ipv4_route_test|ipv4_rt) ipv4_route_test;; ipv6_addr_metric) ipv6_addr_metric_test;; From patchwork Thu Oct 3 15:49:31 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175144 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp569203ill; Thu, 3 Oct 2019 09:39:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqwVY1QzAhEuKMplQ9HXwzhjjjR9H2opyD8p8ww2SC+TjQN/AWLQk5jRU7rXOcWTPOm2jNXt X-Received: by 2002:a05:6402:13cd:: with SMTP id a13mr10362566edx.6.1570120770474; Thu, 03 Oct 2019 09:39:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570120770; cv=none; d=google.com; s=arc-20160816; b=tVgLcJJaU8SgNvvXnl03cXy1xS+dedIzNrbX5Chn4p4qZ8NTKKHbeFDUrmC8WE2eb6 hE+M7JFMDxNJTSVUfX/ZgIU+E/OaUQP1ZB1PsGEWid8XZzkBuZ9fDjdHADk9mzOu1Tcg +HFX7WR/kTlKkEa46fyrIETAaglsmwMVpng8UDJ4YdVeybwAKFlw/9fs1TOlTBO8qHze wovFf2GcTNn4weEpYsChgI9ADKf0dUyKhz5hJO2pCx5Y5U4B7BDOOoEjNutcUJBIgjj5 mlV3Bbyz3uiq1etMLGNm2HLzRysCSAUFy5tGk4Aio/0VbUIzcspLPAFCxL3dcwGpvVks pPfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=wnTM9D7gjE73iv/01ERT6DtJGUzHADOdRS2lRhk8bJU=; b=YFyzyDrTt4Vjnbu7TbLpJrorXhHpcMAcH+t1gUBJL9no0+BjCIXPJs5Voz1uof0PAP HZ2k3/ciNMAKWA7Y5CabKtGWLzIfxkfLo97Gc32Y8zPEpFGXfgPtGjdqVYCee4Pki2uU Uvq0TOn5QjLio+jLMkXKoCwHuJqK2FQTbQgvfdUoN2Jb2MFkrdhM2t41wo1zeIJYWmuS JFoVMQCPsQCxm9qtIP6+MAUHTkYpewUdmwUmPocbRKQoT/JmENyGE/H2wcBg4dmEtxJ8 FKwfQfbzOOlNVOS32m/uXwRfOuDdkJ+ROekVCxuO+cQQYLHWJXOVi8fSHiAfEKHB5MlR f0cw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=jSlRZAxu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e12si1905204edb.262.2019.10.03.09.39.30; Thu, 03 Oct 2019 09:39:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=jSlRZAxu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404776AbfJCQj0 (ORCPT + 27 others); Thu, 3 Oct 2019 12:39: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 S2404735AbfJCQjY (ORCPT ); Thu, 3 Oct 2019 12:39:24 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CFF3C2070B; Thu, 3 Oct 2019 16:39:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570120764; bh=kvo8e6FkZ7qO+5CeiOkhJiM1oUsYCDpijb9DiyqS2Zs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jSlRZAxudCrtv6r2AxJ7xZSM08/gO8yY7b4L2BXb1OIH19MZjiKrK+AE62WZnwZ+l TcJ0WfxbDEVSd2G5FLUAK/Rsg1uJ8141I66vgJtke97nT40lcdsjkMJ2kulCnJ0M35 UIYkJ1lqI6TMZNpD5FaLPrVKUWzWbUGKQFT40xqI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Bjorn Andersson , Jakub Kicinski Subject: [PATCH 5.3 006/344] net: qrtr: Stop rx_worker before freeing node Date: Thu, 3 Oct 2019 17:49:31 +0200 Message-Id: <20191003154540.701536820@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Bjorn Andersson [ Upstream commit 73f0c11d11329a0d6d205d4312b6e5d2512af7c5 ] As the endpoint is unregistered there might still be work pending to handle incoming messages, which will result in a use after free scenario. The plan is to remove the rx_worker, but until then (and for stable@) ensure that the work is stopped before the node is freed. Fixes: bdabad3e363d ("net: Add Qualcomm IPC router") Cc: stable@vger.kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman --- net/qrtr/qrtr.c | 1 + 1 file changed, 1 insertion(+) --- a/net/qrtr/qrtr.c +++ b/net/qrtr/qrtr.c @@ -150,6 +150,7 @@ static void __qrtr_node_release(struct k list_del(&node->item); mutex_unlock(&qrtr_node_lock); + cancel_work_sync(&node->work); skb_queue_purge(&node->rx_queue); kfree(node); } From patchwork Thu Oct 3 15:50:23 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175151 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp573618ill; Thu, 3 Oct 2019 09:43:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqyCUJrYw/zfqYQY9USa16sC8pM4GnyWdU90zfRcHHwPsmd3R6R0UkSsyJd05y9DPeUv6NRo X-Received: by 2002:aa7:dad3:: with SMTP id x19mr10555062eds.59.1570120858968; Thu, 03 Oct 2019 09:40:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570120858; cv=none; d=google.com; s=arc-20160816; b=g+IXaxans6W6l7ZcJr5Ocm+sdZZAQVjkOkr/s37jSnV/+fyIPyK/rJODrmFMYd3vYR RLM3KTdvPIK3r3jZMhW3OptQPJcUBDRaFiIAhQ3BiYEqHFcP+XaQTs7mbvwVsa/3tuok Dq6On7M89+4jrUIdWpE3cI1raTSz/IWwnMyaqNGXPaMldbU8/szeQvXkWunrwKnNuZkY h5n8pXIVDonqrT3toGegJ9l3fJYPFUR15G/c8wPiWydaVexD7WL6QTa8KsDQ0hRMugko Tq79Ebkd+y4dNcOopABEMeOEfY0NFMQueVrB4BJxJbU9Z8J7hpKHk+U3wa4V1QOTHk7I Sxfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=gjz9DCtJe6QcVFxELkDHyRozyHnXEhHPknlw+GIrEEY=; b=dusenh6BFPrQi+QnCHDk3bHkk5HqmU7GEY1NS/vqudR6xf7JNREzJsb3n5wG+XzfI4 wx5cIcj8Ac60hHChTSJZopGEUmkAd138HwKwyex9uFxHsYSmQQH/nXsFfYe7jcjDdUUI x6LrTmVlK6rgUvXpu15Jyo5qZMm8yD2BXJCEUAyOao+gICH1tqHWgm6nr0W7xtgQdnmc TsszXlzJSUNgSCRhwAb1j2hZdXdrtyxPYuvEOLZV8wu6np8I5ybit96bVjEGI9VMIJO7 R0dvoZHXSo+TI+g/pVEVRiuhYLUva+p0D/BvZrgaAZ5YK7x3m+4cuje1wrz+b0f0vc1f 1x9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UE2lttBd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id sb7si1581045ejb.321.2019.10.03.09.40.58; Thu, 03 Oct 2019 09:40:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UE2lttBd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404978AbfJCQkz (ORCPT + 27 others); Thu, 3 Oct 2019 12:40:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:51038 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404950AbfJCQkr (ORCPT ); Thu, 3 Oct 2019 12:40:47 -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 CD0872070B; Thu, 3 Oct 2019 16:40:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570120846; bh=CKOJhoQWKwRHugdFdAlJKtgD9dw0sIWNrDvnzJWLrKE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UE2lttBddwxvIOCXE5IWG3P2TCZLNX83wUpwqg6RcGK3jdyOhcUj04JZQ3KDSqQy6 26Mf9atrk+bD+ze+dFgJQyVSA8W4vphjdkZTu7mqWwUFZlF+yirNizdWOQbrdV2OnW 83oyucdbg8/VerRL1kOcIc8JTIBB5wFxKzRQ4fWs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arnd Bergmann , Nick Desaulniers , Hans Verkuil , Mauro Carvalho Chehab , Sasha Levin Subject: [PATCH 5.3 058/344] media: vivid: work around high stack usage with clang Date: Thu, 3 Oct 2019 17:50:23 +0200 Message-Id: <20191003154545.857596867@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann [ Upstream commit 1a03f91c2c2419c3709c4554952c66695575e91c ] Building a KASAN-enabled kernel with clang ends up in a case where too much is inlined into vivid_thread_vid_cap() and the stack usage grows a lot, possibly when the register allocation fails to produce efficient code and spills a lot of temporaries to the stack. This uses more than twice the amount of stack than the sum of the individual functions when they are not inlined: drivers/media/platform/vivid/vivid-kthread-cap.c:766:12: error: stack frame size of 2208 bytes in function 'vivid_thread_vid_cap' [-Werror,-Wframe-larger-than=] Marking two of the key functions in here as 'noinline_for_stack' avoids the pathological case in clang without any apparent downside for gcc. Signed-off-by: Arnd Bergmann Acked-by: Nick Desaulniers Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin --- drivers/media/platform/vivid/vivid-kthread-cap.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) -- 2.20.1 diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c b/drivers/media/platform/vivid/vivid-kthread-cap.c index ed466d737a90d..003319d7816d7 100644 --- a/drivers/media/platform/vivid/vivid-kthread-cap.c +++ b/drivers/media/platform/vivid/vivid-kthread-cap.c @@ -232,8 +232,8 @@ static void *plane_vaddr(struct tpg_data *tpg, struct vivid_buffer *buf, return vbuf; } -static int vivid_copy_buffer(struct vivid_dev *dev, unsigned p, u8 *vcapbuf, - struct vivid_buffer *vid_cap_buf) +static noinline_for_stack int vivid_copy_buffer(struct vivid_dev *dev, unsigned p, + u8 *vcapbuf, struct vivid_buffer *vid_cap_buf) { bool blank = dev->must_blank[vid_cap_buf->vb.vb2_buf.index]; struct tpg_data *tpg = &dev->tpg; @@ -672,7 +672,8 @@ static void vivid_cap_update_frame_period(struct vivid_dev *dev) dev->cap_frame_period = f_period; } -static void vivid_thread_vid_cap_tick(struct vivid_dev *dev, int dropped_bufs) +static noinline_for_stack void vivid_thread_vid_cap_tick(struct vivid_dev *dev, + int dropped_bufs) { struct vivid_buffer *vid_cap_buf = NULL; struct vivid_buffer *vbi_cap_buf = NULL; From patchwork Thu Oct 3 15:50:27 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175146 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp571214ill; Thu, 3 Oct 2019 09:41:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqxD4liWzd00SPi/S4/DlgOdmI+DEw7gW+n1YtJLBN5zeIEc+imHVohk4/VMydfLmtyOr1Ew X-Received: by 2002:a17:906:4990:: with SMTP id p16mr8725687eju.9.1570120871552; Thu, 03 Oct 2019 09:41:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570120871; cv=none; d=google.com; s=arc-20160816; b=J+5R9q1HJ1lJnzY/dq1qo/RXsNXT7QWIAHIya6DMlKWnaqvZwSLF5gi7TzPbk19m35 s8r18N6zvnVaDxIaN+jczYCHnL/1Qx76WpWNpK+24nuja2zrTDabh4TBB5M+vIalXJ0d 8keJSSgKWZEGQlEdy71h8Ht9yccPDipWWYOUEuCaUAzf0AoWPe6jgfkkzuRJT6LcZzAG vq757s1B6u8H6whffNR0YpJrMQ8Ee9LOwfn4h1LO2hWUlpQSWbSeHQrNrK7n163w+Rzc 5iSdLG3AXdGfsD5hYn5ExaBSo2EN4dTOTFwFwEJcMdKiUdjvFNj6beHaU3Q4FkRZezwM FZdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=T85Mt7ceCZCc6xb2hg1v4u3najU42avN/Q4U+mTTaYc=; b=NM0FJjF7qYrDEoVod3joHSUUtjCaiylRtLmgMiwy8rgVug6GRxI0esoD5Sey8Utqhg p+Ct6fyW15Q91o9j26I6hbTPDk/OwUHRhIB783Nowmu/OsS1dzINlRwNezjiLeLA1aJT OyP8Yy0Irz9k4qis7wuscng//2EnwrNP+iuOHYJ9PaLviK0b2ygshwrTJp2CFqgFp54L PgMAdbmGlEF7hvq5f699++wNuhDt8XlGN30hhNwcHJeFgmVoohzvj5eVa6vlFSngK5Yp o45t1TZMqT33PZvkKKUdyZNq9EMMQHAbyU5GmbdV19O/qthyWx3A3o/CtQOkwsCvnXmO 3YNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UtAC4e+H; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id sb7si1581045ejb.321.2019.10.03.09.41.10; Thu, 03 Oct 2019 09:41:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UtAC4e+H; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392236AbfJCQlJ (ORCPT + 27 others); Thu, 3 Oct 2019 12:41:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:51294 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404979AbfJCQk6 (ORCPT ); Thu, 3 Oct 2019 12:40:58 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CE65F20830; Thu, 3 Oct 2019 16:40:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570120857; bh=ZC9lpSM5Wj6CgnpGxKHza4H16yIMHAvueVMdgbA3+Lk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UtAC4e+Htg+QQXGjJzl1tafNzEW3+vt9yh9oJKB6GuRRfgbtlSIn7vWG4gxnsYrVA BsiaClNRYxAXH4RDfjosl+EzVPINyUdaegNjbOtAK5ZR/Lo2YSF/GHAcAwYxT55BxW py0NnvagqoeRuNdoKUjIt6dFmpSmBQ2c31SQzxFQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vincent Guittot , "Peter Zijlstra (Intel)" , Linus Torvalds , Thomas Gleixner , Ingo Molnar , Sasha Levin Subject: [PATCH 5.3 062/344] sched/fair: Fix imbalance due to CPU affinity Date: Thu, 3 Oct 2019 17:50:27 +0200 Message-Id: <20191003154546.221364910@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vincent Guittot [ Upstream commit f6cad8df6b30a5d2bbbd2e698f74b4cafb9fb82b ] The load_balance() has a dedicated mecanism to detect when an imbalance is due to CPU affinity and must be handled at parent level. In this case, the imbalance field of the parent's sched_group is set. The description of sg_imbalanced() gives a typical example of two groups of 4 CPUs each and 4 tasks each with a cpumask covering 1 CPU of the first group and 3 CPUs of the second group. Something like: { 0 1 2 3 } { 4 5 6 7 } * * * * But the load_balance fails to fix this UC on my octo cores system made of 2 clusters of quad cores. Whereas the load_balance is able to detect that the imbalanced is due to CPU affinity, it fails to fix it because the imbalance field is cleared before letting parent level a chance to run. In fact, when the imbalance is detected, the load_balance reruns without the CPU with pinned tasks. But there is no other running tasks in the situation described above and everything looks balanced this time so the imbalance field is immediately cleared. The imbalance field should not be cleared if there is no other task to move when the imbalance is detected. Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: https://lkml.kernel.org/r/1561996022-28829-1-git-send-email-vincent.guittot@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin --- kernel/sched/fair.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.20.1 diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 500f5db0de0ba..105b1aead0c3a 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -9052,9 +9052,10 @@ static int load_balance(int this_cpu, struct rq *this_rq, out_balanced: /* * We reach balance although we may have faced some affinity - * constraints. Clear the imbalance flag if it was set. + * constraints. Clear the imbalance flag only if other tasks got + * a chance to move and fix the imbalance. */ - if (sd_parent) { + if (sd_parent && !(env.flags & LBF_ALL_PINNED)) { int *group_imbalance = &sd_parent->groups->sgc->imbalance; if (*group_imbalance) From patchwork Thu Oct 3 15:50:45 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175155 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp574372ill; Thu, 3 Oct 2019 09:44:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqxDY//O/FR8zMVqZR5wxaDF22e4RIA61RmNqdcweg3asPSAe3w7fkf+4fXQlwOYG8MTv61F X-Received: by 2002:a50:da44:: with SMTP id a4mr10673294edk.120.1570120911097; Thu, 03 Oct 2019 09:41:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570120911; cv=none; d=google.com; s=arc-20160816; b=A74gTns3Cx6bK66bA+u9Us3z+b0gS8BPqjZT5UH2KDPc0ZGu/9XdhnlGK0SkKKS4HQ AHcTe18BIXXpKXaldewMnUbmVLWn3mF4swE5X+/vgG9wCiGpw6/AydP2KAJ/R0dV0qJi 31heie0FDepa7hCU9+GbrPmg/YJdHoJzkiZaxhpdAOXCCRTtP3MSb2NW/0AcfH6na+Bx v7i/xazJfmkaeRF6+s1MFtA9R0TGoRtqwaDlAAlcEyipChum81kUBS7UNfHHR7ftn4aP byHyyJ7IHPyxogNdGLTTWflXTyzzSpVAnkVj8e65oTuSlANz9jDjoktsP4XtsCa3LMq5 E9pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=z7SMPKqk6SPxfkVw6ffCpHp1FQu2jB4Ozv6D257BEjY=; b=pYaCEaefgaOiswZNdaJR+iZXjznUdfeRocwuc2gcmJhWiqX7bERwvLa5pRuyTrhQ3J +XN2X/E7sbsk+E1RzHPIq7o1FmCbHGdlpnd3m/pgWpZvmW/y+JOIep3pg2obCnEWWyYy 96wvvtY9WNcSAhLEVYnlHXAgCK6S2j2AD9I+1BcjEkIZX4DdcU6bP99hV9AoAL76zlWD JUa2u26oFGl0RgEgIZ0TPP7Ytp/3LRavWMnabB4oCRHpEHeg6d/tYBf7FlKImPaP/QGy EjFIhIH4W5YEVLlvxjsZsNfBiiC2MYuAVLie2lxX51DM6LI469DANmOen4kqGgVifVRe DRDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=IznPtvy7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z33si2039951edz.314.2019.10.03.09.41.50; Thu, 03 Oct 2019 09:41:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=IznPtvy7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392274AbfJCQlt (ORCPT + 27 others); Thu, 3 Oct 2019 12:41:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:52204 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405067AbfJCQlk (ORCPT ); Thu, 3 Oct 2019 12:41:40 -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 5BA342054F; Thu, 3 Oct 2019 16:41:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570120899; bh=xKTppu/GDfJLMQWpfzwwiblwXnUW9uwticGihbh1hF8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IznPtvy7QKs8/ExvVgSJPUTK+rL8LXB6nkEN63YNSlOwS/6mZQrgGn/K3xzb8Z+Qv CFA+N1wGWIsJGMzAM27iY59uF0d5iUqjgTTdilwH7KgSmzkVir/p5lOsvhirfwgzb0 jXdDCeNXl0TRC6Dj2JadH3Jd0iYuYgChHPTQOqp4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vinod Koul , Vaishali Thakkar , Stephen Boyd , Bjorn Andersson , Sasha Levin Subject: [PATCH 5.3 080/344] base: soc: Export soc_device_register/unregister APIs Date: Thu, 3 Oct 2019 17:50:45 +0200 Message-Id: <20191003154548.029974875@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vinod Koul [ Upstream commit f7ccc7a397cf2ef64aebb2f726970b93203858d2 ] Qcom Socinfo driver can be built as a module, so export these two APIs. Tested-by: Vinod Koul Signed-off-by: Vinod Koul Signed-off-by: Vaishali Thakkar Reviewed-by: Greg Kroah-Hartman Reviewed-by: Stephen Boyd Reviewed-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin --- drivers/base/soc.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.20.1 diff --git a/drivers/base/soc.c b/drivers/base/soc.c index 10b280f30217b..7e91894a380b5 100644 --- a/drivers/base/soc.c +++ b/drivers/base/soc.c @@ -157,6 +157,7 @@ struct soc_device *soc_device_register(struct soc_device_attribute *soc_dev_attr out1: return ERR_PTR(ret); } +EXPORT_SYMBOL_GPL(soc_device_register); /* Ensure soc_dev->attr is freed prior to calling soc_device_unregister. */ void soc_device_unregister(struct soc_device *soc_dev) @@ -166,6 +167,7 @@ void soc_device_unregister(struct soc_device *soc_dev) device_unregister(&soc_dev->dev); early_soc_dev_attr = NULL; } +EXPORT_SYMBOL_GPL(soc_device_unregister); static int __init soc_bus_register(void) { From patchwork Thu Oct 3 15:51:04 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175148 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp572943ill; Thu, 3 Oct 2019 09:42:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqxX5PMcUxNqt18SF6N96U+jWvru6O9s19NQBpwlmvKWraabS4Wllk+Y1sb+Gy0val+vkpeK X-Received: by 2002:a17:906:6bca:: with SMTP id t10mr8671126ejs.64.1570120961064; Thu, 03 Oct 2019 09:42:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570120961; cv=none; d=google.com; s=arc-20160816; b=BvxvXXes2rKBVS/nWmGd2ovOFDSZ1W8hR6UM6egemVn2BFLTg8JFz4qWIGLhFYcnxq JrMormhMkP1v/kemjBBeDkuH1HThROpBQfB9XeK4yJMkFXowRayFSKQ59hIpnzM0wHqh Z15SD5rn2V8yEAK/OsBWHkWcR5aYZbwCYPkjNZS+/P78+nvkJDBtTBcxqrJ61phVAKvQ z5rIVDxJImRwBmMa5q4ONlYAdNcuw4OTV0OrAAOV1PXIhZoyIdN3+UdQwRmR3Z2EBgR4 LidzpOPrDowApK7hSLD4Mxryo83BjTA2speEKGkV8Jm14tLwppjXKIHdbuZVXeTXP9q7 svFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=QysHqyJiNaBe1m1gUMpqTANmqSNRouVizu+qOvBPryA=; b=qh8kDgkeDQ2i1kRklu9qXvItYRnnyR7ZY/o0CX3kElDX2ESGT1TD1coj9NfYqSR1Lj Rudp/2WAROtCz2rWWSUBbLe7F90DzzdP7q6KylAz5s2W1rM0ucd2M8jbeCLc8IKQGTpd DZpJ/3LQE/e3XEU6b+vW8zkGbbq8ehMgMg2dRGX1idHOPlxTr6ML3idcuus9xOkzCwtm FBL3a3XDwnn4dgOFnCMbhjJpjM+fSO1H+rCVEHzy9eYSpfpqSY86lKqi75YXUK5xvn55 Ks2Isphkm+NNNHlIuiHXYp24Tm3LGSgYnRNmi7QwZkyFLZ9Xx4ayHH30pjEYt3/O70AJ hP9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="RBuHG/Fy"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z35si1771241edd.340.2019.10.03.09.42.40; Thu, 03 Oct 2019 09:42:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="RBuHG/Fy"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392686AbfJCQmj (ORCPT + 27 others); Thu, 3 Oct 2019 12:42:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:53686 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404062AbfJCQmg (ORCPT ); Thu, 3 Oct 2019 12:42:36 -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 066A92054F; Thu, 3 Oct 2019 16:42:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570120955; bh=iupxWFpcY6/cgaLlrAWuYCcnrImMYlOV5CQiGwgF2WE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RBuHG/FykYr7PhTKBry71DQslStZ69w8+4i0DAUO3kUYrZrpIbU9dDiRY335ymg1X EPgVQYKcbRuINLh6OloU7/6FyvU0PIQV2g47KHqTYoIri5G7N4B+H925vaEhzUMc9z D9TAdw/x9j8dBrCCuD5OlqgNw6mkTtItCdgaDKXw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jim Quinlan , Sudeep Holla , Sasha Levin Subject: [PATCH 5.3 099/344] firmware: arm_scmi: Check if platform has released shmem before using Date: Thu, 3 Oct 2019 17:51:04 +0200 Message-Id: <20191003154549.966139872@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sudeep Holla [ Upstream commit 9dc34d635c67e57051853855c43249408641a5ab ] Sometimes platfom may take too long to respond to the command and OS might timeout before platform transfer the ownership of the shared memory region to the OS with the response. Since the mailbox channel associated with the channel is freed and new commands are dispatch on the same channel, OS needs to wait until it gets back the ownership. If not, either OS may end up overwriting the platform response for the last command(which is fine as OS timed out that command) or platform might overwrite the payload for the next command with the response for the old. The latter is problematic as platform may end up interpretting the response as the payload. In order to avoid such race, let's wait until the OS gets back the ownership before we prepare the shared memory with the payload for the next command. Reported-by: Jim Quinlan Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin --- drivers/firmware/arm_scmi/driver.c | 8 ++++++++ 1 file changed, 8 insertions(+) -- 2.20.1 diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c index b5bc4c7a8fab2..b49c9e6f4bf10 100644 --- a/drivers/firmware/arm_scmi/driver.c +++ b/drivers/firmware/arm_scmi/driver.c @@ -271,6 +271,14 @@ static void scmi_tx_prepare(struct mbox_client *cl, void *m) struct scmi_chan_info *cinfo = client_to_scmi_chan_info(cl); struct scmi_shared_mem __iomem *mem = cinfo->payload; + /* + * Ideally channel must be free by now unless OS timeout last + * request and platform continued to process the same, wait + * until it releases the shared memory, otherwise we may endup + * overwriting its response with new message payload or vice-versa + */ + spin_until_cond(ioread32(&mem->channel_status) & + SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE); /* Mark channel busy + clear error */ iowrite32(0x0, &mem->channel_status); iowrite32(t->hdr.poll_completion ? 0 : SCMI_SHMEM_FLAG_INTR_ENABLED, From patchwork Thu Oct 3 15:51:19 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175150 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp573565ill; Thu, 3 Oct 2019 09:43:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqzvFtOwMxqZtVcVDCxvuh45H2+7xQ+n6MOFYRuLSFDdDbm6JeKXsrjLs29iBDuI8hV+8kes X-Received: by 2002:a50:aa96:: with SMTP id q22mr10485404edc.179.1570120995364; Thu, 03 Oct 2019 09:43:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570120995; cv=none; d=google.com; s=arc-20160816; b=S3tNutB6Zz7NPjSTvKhnhRzjpAgiF6uawNBH7H7YU5jzIVVz3tYueJsQivKzbflo+r 3fBz8jJN9rrOO6e1umfanwFXf2TsVC79SFX+KJnCt2f/ohYc2gj1zWORjU0GR8FopBEX K82xhbfxe9eiIG/ixSP5IZZ69fPuQEbaewcuJD/BdY5k9wf23QSVaSyxP1Bw/F28C2TB jsw7rpu2iPFpdJPS+jBX6wUMVJY9/RWLG541cJ+3sNhR72jjWIwxl48DC9+wYLVTknt1 4NjRR6FpLQpiwauXZn8XS06xMNPsFfs6OqCjkm4sB6c2ky9buUsZiHEqemr4GOpB1s6n XJtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=m6I3xn6EKZt4rJcOF1XQQjGGJ6TiIyyFBwU5bD4MkHg=; b=rOmWuqI1ByFbMCwSGVaPhlFITcxwfUvTMADEEYVFFMvehnfpnW8swVp+emnWNMUbAA i3UZTyApYIlDglBL/n6sYeTYnMrcZselI2OXyQfLzV79keSRpqgVVIUoc+zFrARGu8Hu C7/4d1ebvZpTzdhK2OtL77vPV3R/gS2jwkCt70Selw3IJuoseExR82dooTRMSzh8hL21 HVIEi5v/IHep2ddv68bQtiwdXddm7k0hNsZX0DvOZnvrapnA4nTfrxMjC761Xb8280yu JjIo2xIw7YY/9Rb2xXMsL3/TOe3aJPGCU3EQcI00T8FmxKMHDYRGh+0G3jwK/zlEqnuc kaVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="w21k/gQH"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f2si1582235ejq.395.2019.10.03.09.43.15; Thu, 03 Oct 2019 09:43:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="w21k/gQH"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405139AbfJCQnN (ORCPT + 27 others); Thu, 3 Oct 2019 12:43:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:54490 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405120AbfJCQnL (ORCPT ); Thu, 3 Oct 2019 12:43: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 C3EB920865; Thu, 3 Oct 2019 16:43:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570120990; bh=R84mSIxpEX1AcPIuhZJU0uwLWQyn3K4b+Mpvg9kxH0k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=w21k/gQHvA1HwrHNFFaHb55uh9WCsPGo8ikcYBrCtc2F1lRqcEku4MkPMkgui5MHO N5QXXH/QhkgvOAH/t5FuuO9FshM+J4qMYsMFBNaeWhZBZS/JPecCaRMXtWd4Cu/bwM bbU3rk0lFGdRoiQlizrR2eMp/UDYlX5aES7k6LuQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arnd Bergmann , Sasha Levin Subject: [PATCH 5.3 114/344] ARM: xscale: fix multi-cpu compilation Date: Thu, 3 Oct 2019 17:51:19 +0200 Message-Id: <20191003154551.446518473@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann [ Upstream commit c7b68049943079550d4e6af0f10aa3aabd64131a ] Building a combined ARMv4+XScale kernel produces these and other build failures: /tmp/copypage-xscale-3aa821.s: Assembler messages: /tmp/copypage-xscale-3aa821.s:167: Error: selected processor does not support `pld [r7,#0]' in ARM mode /tmp/copypage-xscale-3aa821.s:168: Error: selected processor does not support `pld [r7,#32]' in ARM mode /tmp/copypage-xscale-3aa821.s:169: Error: selected processor does not support `pld [r1,#0]' in ARM mode /tmp/copypage-xscale-3aa821.s:170: Error: selected processor does not support `pld [r1,#32]' in ARM mode /tmp/copypage-xscale-3aa821.s:171: Error: selected processor does not support `pld [r7,#64]' in ARM mode /tmp/copypage-xscale-3aa821.s:176: Error: selected processor does not support `ldrd r4,r5,[r7],#8' in ARM mode /tmp/copypage-xscale-3aa821.s:180: Error: selected processor does not support `strd r4,r5,[r1],#8' in ARM mode Add an explict .arch armv5 in the inline assembly to allow the ARMv5 specific instructions regardless of the compiler -march= target. Link: https://lore.kernel.org/r/20190809163334.489360-5-arnd@arndb.de Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin --- arch/arm/mm/copypage-xscale.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.20.1 diff --git a/arch/arm/mm/copypage-xscale.c b/arch/arm/mm/copypage-xscale.c index 61d834157bc05..382e1c2855e85 100644 --- a/arch/arm/mm/copypage-xscale.c +++ b/arch/arm/mm/copypage-xscale.c @@ -42,6 +42,7 @@ static void mc_copy_user_page(void *from, void *to) * when prefetching destination as well. (NP) */ asm volatile ("\ +.arch xscale \n\ pld [%0, #0] \n\ pld [%0, #32] \n\ pld [%1, #0] \n\ @@ -106,8 +107,9 @@ void xscale_mc_clear_user_highpage(struct page *page, unsigned long vaddr) { void *ptr, *kaddr = kmap_atomic(page); - asm volatile( - "mov r1, %2 \n\ + asm volatile("\ +.arch xscale \n\ + mov r1, %2 \n\ mov r2, #0 \n\ mov r3, #0 \n\ 1: mov ip, %0 \n\ From patchwork Thu Oct 3 15:51:25 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175171 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp595651ill; Thu, 3 Oct 2019 10:02:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqyEaao6QeFshkHjmbBLsl73HKw0vBuHTy/EcCW3conwgITsj2trFc56PglOC1Mx0flKh0VH X-Received: by 2002:a05:6402:1e4:: with SMTP id i4mr10658215edy.31.1570122136846; Thu, 03 Oct 2019 10:02:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570122136; cv=none; d=google.com; s=arc-20160816; b=TMqkZ3yylAYNX2G526/9nuRXE/QD8oOOnlSELYPhdJcz7zcpwfUoX8VtLTgK8Bbw4R aRy8frjjFjEYntIGfWnRM+3BE7LbgfeP+/ne0EwXJGfrl5CnavMoQyiSZteCus+6Qpzd jogvwjZ/nlXDeMVXqw382xaugY1n3xxsqj3M21QqTDF8h6b00g2CaVozB4Q+ySqy6k/4 v4A5rW9t9M/Prq4qCHpdaYalU17Mihi5KZqEqTBFo8CYSbJ+ixWrMQadodKE5DwxIMQR ggPDy9d2uqpeu8VU0BLaC7P4ykT6Hiv5dZe2fojII+18yWXPrB59tR0kXkWsnSyXCPFk Cvng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=3htRQl954QmBuJyLQwasHk4KigwbFor2wr91rI3ejzQ=; b=OqSX6KM2e11tH4Ja65dhXgn4Yz4+8JQtqngU/rMQARtpywkBq1LtjLmfJH7rP+W1T1 KYHFWaSIqLAKW+KehYxMhvpxqs+BaF6gWoIYpFsMAS64ebPmboqWETK2P6Jnv8TMT0Nk qx0lyGhvg6NJOKVuoHADBio1osCxmmjUKRS0NfDbmZIsrmAHU+Ujf5gnvGKigzySSZsn 9XGsfhYEkyWpPtmnfLsNAX3kUl5IQFvUAQEZDWLdefDFqs+EHuOL4gM5Wf2fobEGIDyc b4FinU+Dih0Frsq7ABLvkKmTluEHQWRV1r/K83lJwGXUuOvQ7ihfA6BaEL7bM6+Jjeh1 bXRg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=TuXC0dv3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h20si1817014edb.218.2019.10.03.10.02.16; Thu, 03 Oct 2019 10:02:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=TuXC0dv3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393232AbfJCRCP (ORCPT + 27 others); Thu, 3 Oct 2019 13:02:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:54888 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404879AbfJCQn1 (ORCPT ); Thu, 3 Oct 2019 12:43:27 -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 EDC3720865; Thu, 3 Oct 2019 16:43:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570121006; bh=Ykb93oMr+3gztSj7HV5KYl0vXoN7XcXRQ9o4/s8Ik+A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TuXC0dv35m2RHhPPS0WA9v2206OLTTreQRqVt1VvlmzZmY+rGPt+3kiihNf0A+Wk2 7g0cwEnpSA3d8r5IhIEyexkMvS8DbAiYYZvfL8Srg/PsaLR6NVrDroBVScZwGOTAC+ GDF10eUbHcmt/q1PA8MeM3exkuU95/7gF5q5nFA4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Catalin Marinas , Mark Rutland , Andrey Ryabinin , Will Deacon , Sasha Levin Subject: [PATCH 5.3 120/344] kasan/arm64: fix CONFIG_KASAN_SW_TAGS && KASAN_INLINE Date: Thu, 3 Oct 2019 17:51:25 +0200 Message-Id: <20191003154552.032770815@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mark Rutland [ Upstream commit 34b5560db40d2941cfbe82eca1641353d5aed1a9 ] The generic Makefile.kasan propagates CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET, but only does so for CONFIG_KASAN_GENERIC. Since commit: 6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET") ... arm64 defines CONFIG_KASAN_SHADOW_OFFSET in Kconfig rather than defining KASAN_SHADOW_OFFSET in a Makefile. Thus, if CONFIG_KASAN_SW_TAGS && KASAN_INLINE are selected, we get build time splats due to KASAN_SHADOW_OFFSET not being set: | [mark@lakrids:~/src/linux]% usellvm 8.0.1 usekorg 8.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- CC=clang | scripts/kconfig/conf --syncconfig Kconfig | CC scripts/mod/empty.o | clang (LLVM option parsing): for the -hwasan-mapping-offset option: '' value invalid for uint argument! | scripts/Makefile.build:273: recipe for target 'scripts/mod/empty.o' failed | make[1]: *** [scripts/mod/empty.o] Error 1 | Makefile:1123: recipe for target 'prepare0' failed | make: *** [prepare0] Error 2 Let's fix this by always propagating CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET if CONFIG_KASAN is selected, moving the existing common definition of +CFLAGS_KASAN_NOSANITIZE to the top of Makefile.kasan. Cc: Catalin Marinas Signed-off-by: Mark Rutland Acked-by: Andrey Ryabinin Tested-by Steve Capper Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- scripts/Makefile.kasan | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) -- 2.20.1 diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan index 6410bd22fe387..03757cc60e06c 100644 --- a/scripts/Makefile.kasan +++ b/scripts/Makefile.kasan @@ -1,4 +1,9 @@ # SPDX-License-Identifier: GPL-2.0 +ifdef CONFIG_KASAN +CFLAGS_KASAN_NOSANITIZE := -fno-builtin +KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET) +endif + ifdef CONFIG_KASAN_GENERIC ifdef CONFIG_KASAN_INLINE @@ -7,8 +12,6 @@ else call_threshold := 0 endif -KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET) - CFLAGS_KASAN_MINIMAL := -fsanitize=kernel-address cc-param = $(call cc-option, -mllvm -$(1), $(call cc-option, --param $(1))) @@ -45,7 +48,3 @@ CFLAGS_KASAN := -fsanitize=kernel-hwaddress \ $(instrumentation_flags) endif # CONFIG_KASAN_SW_TAGS - -ifdef CONFIG_KASAN -CFLAGS_KASAN_NOSANITIZE := -fno-builtin -endif From patchwork Thu Oct 3 15:51:26 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175152 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp573946ill; Thu, 3 Oct 2019 09:43:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqwEiSz2qU9bxez30/e7gU8sYJlB+K7EAvGsA9qDL+eKkbDBhmdNRYHGO43Ldf/fNcOujvz8 X-Received: by 2002:a05:6402:150a:: with SMTP id f10mr10297304edw.110.1570121015639; Thu, 03 Oct 2019 09:43:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570121015; cv=none; d=google.com; s=arc-20160816; b=aA5ZeNKabNu4WhlELo4IacVwihJYcRGdOnmA+Kh95yiIcQKR+Zew4+k642t3N1fhKP oF+UteepuXgMPN5NdK5baI0vLmm0ZWIhv/vKTipIoUG07LMN15qiTkRg3mdeHS+YTze8 JM2JZ1TblxkZtsA+5RdWlDl8kE9+j1kLcGI+XwSkGoTS5QTfc/uVJ30jmNrzyHu5VNmZ ghA6wGfgiVYC+MqyVtEqpfAkCuhqsZjeDdWovinlwUitlaUDa9BnvooKlqWI/aU8oBTu RfcvEdJdcan94leZrzEHREAHw6pWtI++iADa+1EKhKNkOfmQek3toJSGui/yP4ZAKEYj DibQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=7W1j5fE1yCxFsUrDAmnz15kcEplGWj3vcXwORa9si/Y=; b=SFgcGH+Q4G8c3L9HsLRTGqjY137RrCMKPEc2lnvJXpjXeC0ZmuXq2S98so+axKbvuL 4rO9vmezY58EjgwxJVpU7ZSWCiOKsdZ60CuWCdfGB8EZUIFYBJ4Rhie+oWKdYpw3I24S o7CqoG/4rXIS5EnNhGNSbFH4uILPZuv5w1fMiLX/NoGL5apGwU0pU9aj0qpKX2MUwvLc 5dcXL5SjBJ9bDsvqT4omIEHx2O/XeLdCgJo8ra6tLHSheaWt9svb26j4CTxpxPNLTOV8 0STBj+RTBGz6YrGp3Q2ECZLa9/ClPTVQSqssxlSYVLWyIxU3R0PUTmwiD/XMZp7F5bOG yfRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=a6XmUtF0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g3si1832779edu.432.2019.10.03.09.43.35; Thu, 03 Oct 2019 09:43:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=a6XmUtF0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392717AbfJCQne (ORCPT + 27 others); Thu, 3 Oct 2019 12:43:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:54924 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388237AbfJCQn3 (ORCPT ); Thu, 3 Oct 2019 12:43:29 -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 933662070B; Thu, 3 Oct 2019 16:43:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570121009; bh=ljyOOYLOrVHKPq0GoGX1yqA6Ygi+ssZEBM2nuLc3eP4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a6XmUtF0qpBd9YNCWgF9kMTOUAgDDxrLpsXkYm8IOjk92l6oVW5c6f4OpeA8QTbOP v6P6Go0J344rOYzLBdu6aGQ9r1dWDCtWsnpUKbK4/e3YHv3OnbkEd4BmgTSsTvBk57 bgAUut5YJa1rKJI4+uKx6dNC+jA5DfqhfpGGTpNo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, kbuild test robot , Arnd Bergmann , Sasha Levin Subject: [PATCH 5.3 121/344] net: lpc-enet: fix printk format strings Date: Thu, 3 Oct 2019 17:51:26 +0200 Message-Id: <20191003154552.134612304@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann [ Upstream commit de6f97b2bace0e2eb6c3a86e124d1e652a587b56 ] compile-testing this driver on other architectures showed multiple warnings: drivers/net/ethernet/nxp/lpc_eth.c: In function 'lpc_eth_drv_probe': drivers/net/ethernet/nxp/lpc_eth.c:1337:19: warning: format '%d' expects argument of type 'int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=] drivers/net/ethernet/nxp/lpc_eth.c:1342:19: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=] Use format strings that work on all architectures. Link: https://lore.kernel.org/r/20190809144043.476786-10-arnd@arndb.de Reported-by: kbuild test robot Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin --- drivers/net/ethernet/nxp/lpc_eth.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) -- 2.20.1 diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c index f7e11f1b0426c..b0c8be127bee1 100644 --- a/drivers/net/ethernet/nxp/lpc_eth.c +++ b/drivers/net/ethernet/nxp/lpc_eth.c @@ -1344,13 +1344,14 @@ static int lpc_eth_drv_probe(struct platform_device *pdev) pldat->dma_buff_base_p = dma_handle; netdev_dbg(ndev, "IO address space :%pR\n", res); - netdev_dbg(ndev, "IO address size :%d\n", resource_size(res)); + netdev_dbg(ndev, "IO address size :%zd\n", + (size_t)resource_size(res)); netdev_dbg(ndev, "IO address (mapped) :0x%p\n", pldat->net_base); netdev_dbg(ndev, "IRQ number :%d\n", ndev->irq); - netdev_dbg(ndev, "DMA buffer size :%d\n", pldat->dma_buff_size); - netdev_dbg(ndev, "DMA buffer P address :0x%08x\n", - pldat->dma_buff_base_p); + netdev_dbg(ndev, "DMA buffer size :%zd\n", pldat->dma_buff_size); + netdev_dbg(ndev, "DMA buffer P address :%pad\n", + &pldat->dma_buff_base_p); netdev_dbg(ndev, "DMA buffer V address :0x%p\n", pldat->dma_buff_base_v); @@ -1397,8 +1398,8 @@ static int lpc_eth_drv_probe(struct platform_device *pdev) if (ret) goto err_out_unregister_netdev; - netdev_info(ndev, "LPC mac at 0x%08x irq %d\n", - res->start, ndev->irq); + netdev_info(ndev, "LPC mac at 0x%08lx irq %d\n", + (unsigned long)res->start, ndev->irq); device_init_wakeup(dev, 1); device_set_wakeup_enable(dev, 0); From patchwork Thu Oct 3 15:51:34 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175154 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp574325ill; Thu, 3 Oct 2019 09:43:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqzWA72qMVAK2wZFUHiK9JEnwWvN33y1cnVxkTEInqL5nkMxg3RC/b1r9T6QMBPkzIGQ9E9V X-Received: by 2002:aa7:d803:: with SMTP id v3mr10623626edq.146.1570121037426; Thu, 03 Oct 2019 09:43:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570121037; cv=none; d=google.com; s=arc-20160816; b=qQZAWzjsEKeMWsWWICOBqRRZ51VYAqV0DGeaOKUqIgaihyeCR0lxlZ9FAMo7EJTYjm /SR3tO9GKW1RKeAC0Tubq3PcOQxgtN9Pqg7Yy9AMqS5OSO3f4pTjrAsA4wcnrFhcP7Iq CEaKENHv3wquM/9DspdNQ+vf3R0Z3o2qx0RDEIU3ZZnC2hJ1t9MSg4ntdlKN7UWSeen2 ReseBdEI036WIY9SLrpSTQ61Skbl++NwOweESzUctt7+iYzhIWDkP/pGJ6PYN3umZXZx QeARoyrxOhZEjq4sqVKz0BbyIZL3tqqyORQj7rzjC8CXrhndeR6eA8LDjCPyXXtj5H8e hCLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=uS3omDC5fL9ZppJQ/5196azGZw/FtRHQ9ADljr0/fK8=; b=jmyHTYikUBxp58BhPCgX77vlmWk1f4OV9aP+8Rh+1gwhTW5UGZ6pS3j9f7Sfil55UW P80Vf7nEt/7h9roqwA+A11x+3BbUmF/MiMJtIyu9juRt5r3/tr1MurVYYHGIPBcho15N TO7XHz3Iw3wPyAD9MblKVKwtQTznBqH2BG/KmQoqe+ACxkVwuRBqGdALTssRww7phoYp OkL8y7ZJgCEdH8b0d6/Rz4PV+g856AUDzrBOgq5NMJBfn/qOHfAz+Zp1F0J92AB0LeU4 iIWsHPuTt4+dcQg22tdAumgYQOg+rkBXvp44llFGADtzKD9Lddkr2Ic2AOs2aXp1EF3H axIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=tzRMHRth; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k16si1592244ejo.7.2019.10.03.09.43.57; Thu, 03 Oct 2019 09:43:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=tzRMHRth; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405296AbfJCQn4 (ORCPT + 27 others); Thu, 3 Oct 2019 12:43:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:55630 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405286AbfJCQny (ORCPT ); Thu, 3 Oct 2019 12:43: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 DE57B206BB; Thu, 3 Oct 2019 16:43:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570121033; bh=izJSz9zwaSm5xge40Tyl2gKrXmgr/JkniLuCjKggVes=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tzRMHRthY9T93J1Xh05kHcaw3OjgsI5fkMWjjFdt8MtCztBmhsLExkGfUk6iGb87V mRDPfgawo5bJMdtjtizJQZ3/mRkb00+L5bQ8ypPuNHOnhtcGQxbuWtkKrllhla5a65 RPVqERWlFHXmfMw2A4OQH52U5hDLy+638i7tclZc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kunihiko Hayashi , Mark Brown , Sasha Levin Subject: [PATCH 5.3 129/344] ASoC: uniphier: Fix double reset assersion when transitioning to suspend state Date: Thu, 3 Oct 2019 17:51:34 +0200 Message-Id: <20191003154552.965190602@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Kunihiko Hayashi [ Upstream commit c372a35550c8d60f673b20210eea58a06d6d38cb ] When transitioning to supend state, uniphier_aio_dai_suspend() is called and asserts reset lines and disables clocks. However, if there are two or more DAIs, uniphier_aio_dai_suspend() are called multiple times, and double reset assersion will cause. This patch defines the counter that has the number of DAIs at first, and whenever uniphier_aio_dai_suspend() are called, it decrements the counter. And only if the counter is zero, it asserts reset lines and disables clocks. In the same way, uniphier_aio_dai_resume() are called, it increments the counter after deasserting reset lines and enabling clocks. Fixes: 139a34200233 ("ASoC: uniphier: add support for UniPhier AIO CPU DAI driver") Signed-off-by: Kunihiko Hayashi Link: https://lore.kernel.org/r/1566281764-14059-1-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- sound/soc/uniphier/aio-cpu.c | 31 +++++++++++++++++++++---------- sound/soc/uniphier/aio.h | 1 + 2 files changed, 22 insertions(+), 10 deletions(-) -- 2.20.1 diff --git a/sound/soc/uniphier/aio-cpu.c b/sound/soc/uniphier/aio-cpu.c index ee90e6c3937ce..2ae582a99b636 100644 --- a/sound/soc/uniphier/aio-cpu.c +++ b/sound/soc/uniphier/aio-cpu.c @@ -424,8 +424,11 @@ int uniphier_aio_dai_suspend(struct snd_soc_dai *dai) { struct uniphier_aio *aio = uniphier_priv(dai); - reset_control_assert(aio->chip->rst); - clk_disable_unprepare(aio->chip->clk); + aio->chip->num_wup_aios--; + if (!aio->chip->num_wup_aios) { + reset_control_assert(aio->chip->rst); + clk_disable_unprepare(aio->chip->clk); + } return 0; } @@ -439,13 +442,15 @@ int uniphier_aio_dai_resume(struct snd_soc_dai *dai) if (!aio->chip->active) return 0; - ret = clk_prepare_enable(aio->chip->clk); - if (ret) - return ret; + if (!aio->chip->num_wup_aios) { + ret = clk_prepare_enable(aio->chip->clk); + if (ret) + return ret; - ret = reset_control_deassert(aio->chip->rst); - if (ret) - goto err_out_clock; + ret = reset_control_deassert(aio->chip->rst); + if (ret) + goto err_out_clock; + } aio_iecout_set_enable(aio->chip, true); aio_chip_init(aio->chip); @@ -458,7 +463,7 @@ int uniphier_aio_dai_resume(struct snd_soc_dai *dai) ret = aio_init(sub); if (ret) - goto err_out_clock; + goto err_out_reset; if (!sub->setting) continue; @@ -466,11 +471,16 @@ int uniphier_aio_dai_resume(struct snd_soc_dai *dai) aio_port_reset(sub); aio_src_reset(sub); } + aio->chip->num_wup_aios++; return 0; +err_out_reset: + if (!aio->chip->num_wup_aios) + reset_control_assert(aio->chip->rst); err_out_clock: - clk_disable_unprepare(aio->chip->clk); + if (!aio->chip->num_wup_aios) + clk_disable_unprepare(aio->chip->clk); return ret; } @@ -619,6 +629,7 @@ int uniphier_aio_probe(struct platform_device *pdev) return PTR_ERR(chip->rst); chip->num_aios = chip->chip_spec->num_dais; + chip->num_wup_aios = chip->num_aios; chip->aios = devm_kcalloc(dev, chip->num_aios, sizeof(struct uniphier_aio), GFP_KERNEL); diff --git a/sound/soc/uniphier/aio.h b/sound/soc/uniphier/aio.h index ca6ccbae0ee8c..a7ff7e556429b 100644 --- a/sound/soc/uniphier/aio.h +++ b/sound/soc/uniphier/aio.h @@ -285,6 +285,7 @@ struct uniphier_aio_chip { struct uniphier_aio *aios; int num_aios; + int num_wup_aios; struct uniphier_aio_pll *plls; int num_plls; From patchwork Thu Oct 3 15:51:54 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175159 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp577502ill; Thu, 3 Oct 2019 09:46:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqwkrzBEZBZP5oKtdYT2eRQrBW/YPLwYZ/2LhcMb9N84mmUeN5FksMsBuNbsgbuxTB6MlKpj X-Received: by 2002:a17:906:fac5:: with SMTP id lu5mr8565693ejb.71.1570121194063; Thu, 03 Oct 2019 09:46:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570121194; cv=none; d=google.com; s=arc-20160816; b=LOzcMWyZl+wfM5X0EdB7BpOsaYlItPbkb5Zp4Oi+pJug0BGT466xcBlCbJUGkhl8BL 9zpaTt3PdR8aeqqPkaA/iIRscRdI34M9e0PFN6zEp7hPWNq+JAcmXR2c3OZAZBvZh3g0 scxOPJdmThKIkjRTVAGvlgdqWQ2y7MofJ0RWVgOyeVqrzgVRsNjY7DwMjvfdRnW7hhEV u2v5b6g/+9og0GceBWIBSilQdiokgfaBziun6ekrXeFzCYZnRNSL8Q4Yyz0GHrlQGMSc X8N7lxbybxIwxbjnZRQWkjwh2Ec9QqGgtqrJ/7BovBUt0ne74tfBHGi4a3AVNKCJTrYO rK3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=XRuxb4X1jQo7nDcDUC3bbHA38puoZW/ioYGdfGKJeHw=; b=b5e6Sq5dkhoCADn/Xgn3qh1k8T0GoKTHPr5jHCsT2+ao5Lsm1ooDy/hIopCi6gkSHY cvUsKIF2dvwAESnr3tfjryG7EIY4ICk7UtYiK/Ja67A0BWfT8Gu0GCH6+imCBT1zEiRx iI8m8lrYzGA4LqFoxYMnXXh0/N8Awra0HkFPWJ9b/wNaFaKwyJ8+J9p2CfufjoByQ+ZZ BZIZuByy8LsDjZs1qxz/QJbjz8KYLj3nnRp+2oNO5nBHO6XA53rnvv1WofrQfN49z2Xu 12csCkIQjZA4vPaj3eEJkdc1DaOmnSduVq6i/CI1wkdvrPw7MhQ/Sif/shate0N34IMs h/fw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=stslWFFf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g19si1499386ejw.373.2019.10.03.09.46.33; Thu, 03 Oct 2019 09:46:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=stslWFFf; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392697AbfJCQqb (ORCPT + 27 others); Thu, 3 Oct 2019 12:46:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:59742 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387477AbfJCQq2 (ORCPT ); Thu, 3 Oct 2019 12:46:28 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1A8E220830; Thu, 3 Oct 2019 16:46:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570121186; bh=9fwelzb4gaRs6F+woif6HxRJvfWAzWKdIXQYj+jKX5Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=stslWFFf4FuAO5UQeLbipALmg6iwnJCuR/m9jarYnsTazsu3iSCKm/eJymj9yTHl9 eyR+0YBqIYG3nKoIQHqD6Jc0WJ32JK3J8gDSRo5LuaQf0rzaAaAWPRgE/M3BxZQ2A2 RDnkpuWjcQ0fRXgDsXFbBsW9j6jCYHVAbAOR97K4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Masahiro Yamada , Alexandre Belloni , Sasha Levin Subject: [PATCH 5.3 149/344] ARM: at91: move platform-specific asm-offset.h to arch/arm/mach-at91 Date: Thu, 3 Oct 2019 17:51:54 +0200 Message-Id: <20191003154554.952579697@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Masahiro Yamada [ Upstream commit 9fac85a6db8999922f2cd92dfe2e83e063b31a94 ] is only generated and included by arch/arm/mach-at91/, so it does not need to reside in the globally visible include/generated/. I renamed it to arch/arm/mach-at91/pm_data-offsets.h since the prefix 'at91_' is just redundant in mach-at91/. My main motivation of this change is to avoid the race condition for the parallel build (-j) when CONFIG_IKHEADERS is enabled. When it is enabled, all the headers under include/ are archived into kernel/kheaders_data.tar.xz and exposed in the sysfs. In the parallel build, we have no idea in which order files are built. - If at91_pm_data-offsets.h is built before kheaders_data.tar.xz, the header will be included in the archive. Probably nobody will use it, but it is harmless except that it will increase the archive size needlessly. - If kheaders_data.tar.xz is built before at91_pm_data-offsets.h, the header will not be included in the archive. However, in the next build, the archive will be re-generated to include the newly-found at91_pm_data-offsets.h. This is not nice from the build system point of view. - If at91_pm_data-offsets.h and kheaders_data.tar.xz are built at the same time, the corrupted header might be included in the archive, which does not look nice either. This commit fixes the race. Signed-off-by: Masahiro Yamada Link: https://lore.kernel.org/r/20190823024346.591-1-yamada.masahiro@socionext.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin --- arch/arm/mach-at91/.gitignore | 1 + arch/arm/mach-at91/Makefile | 5 +++-- arch/arm/mach-at91/pm_suspend.S | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-) create mode 100644 arch/arm/mach-at91/.gitignore -- 2.20.1 diff --git a/arch/arm/mach-at91/.gitignore b/arch/arm/mach-at91/.gitignore new file mode 100644 index 0000000000000..2ecd6f51c8a95 --- /dev/null +++ b/arch/arm/mach-at91/.gitignore @@ -0,0 +1 @@ +pm_data-offsets.h diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile index 31b61f0e1c077..de64301dcff25 100644 --- a/arch/arm/mach-at91/Makefile +++ b/arch/arm/mach-at91/Makefile @@ -19,9 +19,10 @@ ifeq ($(CONFIG_PM_DEBUG),y) CFLAGS_pm.o += -DDEBUG endif -include/generated/at91_pm_data-offsets.h: arch/arm/mach-at91/pm_data-offsets.s FORCE +$(obj)/pm_data-offsets.h: $(obj)/pm_data-offsets.s FORCE $(call filechk,offsets,__PM_DATA_OFFSETS_H__) -arch/arm/mach-at91/pm_suspend.o: include/generated/at91_pm_data-offsets.h +$(obj)/pm_suspend.o: $(obj)/pm_data-offsets.h targets += pm_data-offsets.s +clean-files += pm_data-offsets.h diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S index c751f047b1166..ed57c879d4e17 100644 --- a/arch/arm/mach-at91/pm_suspend.S +++ b/arch/arm/mach-at91/pm_suspend.S @@ -10,7 +10,7 @@ #include #include #include "pm.h" -#include "generated/at91_pm_data-offsets.h" +#include "pm_data-offsets.h" #define SRAMC_SELF_FRESH_ACTIVE 0x01 #define SRAMC_SELF_FRESH_EXIT 0x00 From patchwork Thu Oct 3 15:52:32 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175168 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp590975ill; Thu, 3 Oct 2019 09:58:46 -0700 (PDT) X-Google-Smtp-Source: APXvYqwXuLIBEhMUrlJhU0yBn+8LG7qyGNedRRpkqFZJO7ddoJ1bl2w23aS37PlMOYvP9wEHPmhL X-Received: by 2002:a17:906:4ad2:: with SMTP id u18mr8577419ejt.117.1570121926743; Thu, 03 Oct 2019 09:58:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570121926; cv=none; d=google.com; s=arc-20160816; b=mzJJ1TocGRRKfmFyUkmG14Vo9sh5ugxtnELB2paetG05UaDuOmRuqHiQbcgTncsKZh C/7vqzSkeLjrGOoNQURkpFL/7Ao1U9AQIsOyINhbwa8OfNl6XAc2bNFi66wziczppBLo UYDjREAq+QneNRNJDocneo4jv3uEcLlgU6sWPTWiYmcKHPwGwiYtNt4NM/3ruC8/ezD9 vwT+ztKTZa3V7DtONpxhpVFF3pedbrFsUbbNnRKWGOanhdy3BmcSIpGuzxXci3RfgJIH pE/43RGz3DosuFwLRjLQtp+Qn5rBfSgJk55NiwGJuRig3hwJjrdSK0ovxx77PJKD8JII AoSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=xy3IVWJa3oYzdcDQdIXFSvUPZOD3kSwZp7yk4A7DuYo=; b=sM7hOG5cIphbgaFHK87xJz8n6qlf9qQi2JhqcK1YaXT8RxVeRU/7jdfcgGmUhq/gp7 TFDc90otjqSjZLviTc5GWkpX3Xvj+yQk4Si6BRT+86ipKnz2l2FejMwJofvAonkDo1fY qHnd5N5ALYpv4UTGslRB5rbUENJ48ze/kLMA+k3KZycqxsgMoNLuJICFh0B0+bn0egx/ HI0Q0pYYDFRFexskUIvNLRsSugkf0UeI8DY2atBI4kXoNizkYRAesq3v3JmL7KGdUcxu qfgtR2kWkO5KBDBWAiLjT0gvOWgvZ3o2PXCCKNwczxCKfzRKlks3aq28rQlMdZ0kYqQ2 epqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=dlkQGSMJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l22si1997845edb.241.2019.10.03.09.58.46; Thu, 03 Oct 2019 09:58:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=dlkQGSMJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392609AbfJCQsK (ORCPT + 27 others); Thu, 3 Oct 2019 12:48:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:33696 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730393AbfJCQsH (ORCPT ); Thu, 3 Oct 2019 12:48:07 -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 CC52621848; Thu, 3 Oct 2019 16:48:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570121286; bh=3iuTUPH38z8GhXhGf0ZoFLJizgr0/Dx+jX0EiSbp/nM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dlkQGSMJvndGXc5UdImLxdlUTpY3bnuDGfS0taioldSVrd3OuupvH3oKiqWCDcECI iDRma8MhvsGukVWK+rw1sElUrmRSMd4qbih1ceFFG7IMccDRMPOcTXYfcKZHKAgpQc 3UAAKqAcfs4BBaDor2b0KoHc5ANw64NQE1/b/YYI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marek Szyprowski , Krzysztof Kozlowski , Sasha Levin Subject: [PATCH 5.3 187/344] ARM: dts: exynos: Mark LDO10 as always-on on Peach Pit/Pi Chromebooks Date: Thu, 3 Oct 2019 17:52:32 +0200 Message-Id: <20191003154558.657691404@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Marek Szyprowski [ Upstream commit 5b0eeeaa37615df37a9a30929b73e9defe61ca84 ] Commit aff138bf8e37 ("ARM: dts: exynos: Add TMU nodes regulator supply for Peach boards") assigned LDO10 to Exynos Thermal Measurement Unit, but it turned out that it supplies also some other critical parts and board freezes/crashes when it is turned off. The mentioned commit made Exynos TMU a consumer of that regulator and in typical case Exynos TMU driver keeps it enabled from early boot. However there are such configurations (example is multi_v7_defconfig), in which some of the regulators are compiled as modules and are not available from early boot. In such case it may happen that LDO10 is turned off by regulator core, because it has no consumers yet (in this case consumer drivers cannot get it, because the supply regulators for it are not yet available). This in turn causes the board to crash. This patch restores 'always-on' property for the LDO10 regulator. Fixes: aff138bf8e37 ("ARM: dts: exynos: Add TMU nodes regulator supply for Peach boards") Signed-off-by: Marek Szyprowski Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin --- arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 + arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 + 2 files changed, 2 insertions(+) -- 2.20.1 diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts index f78db6809cca4..9eb48cabcca45 100644 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts @@ -440,6 +440,7 @@ regulator-name = "vdd_ldo10"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; + regulator-always-on; regulator-state-mem { regulator-off-in-suspend; }; diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts index e0f470fe54c81..4398f2d1fe881 100644 --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts @@ -440,6 +440,7 @@ regulator-name = "vdd_ldo10"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; + regulator-always-on; regulator-state-mem { regulator-off-in-suspend; }; From patchwork Thu Oct 3 15:52:56 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175162 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp578852ill; Thu, 3 Oct 2019 09:47:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqxnR9EQQykXLrsamruwfpCb24uDMZO3OGA/9ISJVRUkjGE/x4+mFtIIuxHq56WHlgwBBAxW X-Received: by 2002:a50:e718:: with SMTP id a24mr10608790edn.289.1570121263385; Thu, 03 Oct 2019 09:47:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570121263; cv=none; d=google.com; s=arc-20160816; b=ukZ/OkeBEnz8hTvNLoXoUnA17nRO8ohwZ4k4Pz4CYjWC9iHeTIrabGgih/GnuTQmEB TM9S5lOZ4IA83qofmHK8S4XyWGG5uv9N9TJDQ4fwq0ILo6AzcWStaIhmskD/nknPZuTg Ncd348lnsCsf06GaHlVGDGmakE/t/gS29CG2IGnbN312s1fFhu50yM1PRUTRj7a7v/mi zhqHrgx4hZDGekkuQ2mbhgUn6Xc3iIA0Y0CmS9ahabc+1d3g06hNh6+OHNoN2e2Lk36I DDfjEWJitXENweZiKsYsp5FwGBbCCDnnIY0QObJ8x1STMM78EVjzerJPO1ff3da3r4Dp Nmzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=WQOBTEIzsv07ILh61mY90MH4XlQMjbDffp9gqdfr29o=; b=lrI455Kgr4vT2TcJrHHPGW+Iy4hmPJSnXeLn25KC1z7GkxjYhy8L73t7sr5SvDox2b 4aCHSqPiUm7Su4YqEV3UwKMChyiSmlBTdqtXsfIyPMQvzEDjGfUOFA3jt3kIaIjjGlFX CaN1VwwdlaKq8owkflYHQHxlD6T8BscwYp5Mi7kGgXRL4/BZ6NzlZsXqqXzZrixPCoBF 5kn15c4LNQqTAIoXiDiYT6knmz7gXkG64Tbys14on12HbdDvdORc3QjfNbr1olEQf+b7 E7vveya8TLPgIGe5lMMnBoQv9OeHF8CWVJqmn3YbIVt3/0SGYI+WMw1sycawTSt6xAIy hBeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=KFl0yU4v; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b42si1857543eda.367.2019.10.03.09.47.43; Thu, 03 Oct 2019 09:47:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=KFl0yU4v; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405527AbfJCQrm (ORCPT + 27 others); Thu, 3 Oct 2019 12:47:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:33014 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405290AbfJCQrh (ORCPT ); Thu, 3 Oct 2019 12:47:37 -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 42CB621848; Thu, 3 Oct 2019 16:47:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570121256; bh=tNKTrgo6pekEMV7o4Yg/oW12mfaytm7NtZ+DZIXJrIo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KFl0yU4vP0N2nc1iQMt54+J5quF0FkgrW8vpTpgluFUZPJ1VUOWo6daaucoeQ9s+4 7GSRV6+9D+0K2/J1B879VrnuiKTyQ9YxS+xGoAqmwv+BE9Ptbg6+b60Qil5ZqPfhAh 1OgcQkVEj10cBt+iBdyFfRqBHa0uBVoInFfm44nk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Matthias Kaehlcke , Ulf Hansson , Douglas Anderson , Sasha Levin Subject: [PATCH 5.3 211/344] mmc: core: Clarify sdio_irq_pending flag for MMC_CAP2_SDIO_IRQ_NOTHREAD Date: Thu, 3 Oct 2019 17:52:56 +0200 Message-Id: <20191003154601.098886365@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ulf Hansson [ Upstream commit 36d57efb4af534dd6b442ea0b9a04aa6dfa37abe ] The sdio_irq_pending flag is used to let host drivers indicate that it has signaled an IRQ. If that is the case and we only have a single SDIO func that have claimed an SDIO IRQ, our assumption is that we can avoid reading the SDIO_CCCR_INTx register and just call the SDIO func irq handler immediately. This makes sense, but the flag is set/cleared in a somewhat messy order, let's fix that up according to below. First, the flag is currently set in sdio_run_irqs(), which is executed as a work that was scheduled from sdio_signal_irq(). To make it more implicit that the host have signaled an IRQ, let's instead immediately set the flag in sdio_signal_irq(). This also makes the behavior consistent with host drivers that uses the legacy, mmc_signal_sdio_irq() API. This have no functional impact, because we don't expect host drivers to call sdio_signal_irq() until after the work (sdio_run_irqs()) have been executed anyways. Second, currently we never clears the flag when using the sdio_run_irqs() work, but only when using the sdio_irq_thread(). Let make the behavior consistent, by moving the flag to be cleared inside the common process_sdio_pending_irqs() function. Additionally, tweak the behavior of the flag slightly, by avoiding to clear it unless we processed the SDIO IRQ. The purpose with this at this point, is to keep the information about whether there have been an SDIO IRQ signaled by the host, so at system resume we can decide to process it without reading the SDIO_CCCR_INTx register. Tested-by: Matthias Kaehlcke Reviewed-by: Matthias Kaehlcke Signed-off-by: Ulf Hansson Reviewed-by: Douglas Anderson Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin --- drivers/mmc/core/sdio_irq.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) -- 2.20.1 diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c index 0bcc5e83bd1a0..40109a6159228 100644 --- a/drivers/mmc/core/sdio_irq.c +++ b/drivers/mmc/core/sdio_irq.c @@ -31,6 +31,7 @@ static int process_sdio_pending_irqs(struct mmc_host *host) { struct mmc_card *card = host->card; int i, ret, count; + bool sdio_irq_pending = host->sdio_irq_pending; unsigned char pending; struct sdio_func *func; @@ -38,13 +39,16 @@ static int process_sdio_pending_irqs(struct mmc_host *host) if (mmc_card_suspended(card)) return 0; + /* Clear the flag to indicate that we have processed the IRQ. */ + host->sdio_irq_pending = false; + /* * Optimization, if there is only 1 function interrupt registered * and we know an IRQ was signaled then call irq handler directly. * Otherwise do the full probe. */ func = card->sdio_single_irq; - if (func && host->sdio_irq_pending) { + if (func && sdio_irq_pending) { func->irq_handler(func); return 1; } @@ -96,7 +100,6 @@ static void sdio_run_irqs(struct mmc_host *host) { mmc_claim_host(host); if (host->sdio_irqs) { - host->sdio_irq_pending = true; process_sdio_pending_irqs(host); if (host->ops->ack_sdio_irq) host->ops->ack_sdio_irq(host); @@ -114,6 +117,7 @@ void sdio_irq_work(struct work_struct *work) void sdio_signal_irq(struct mmc_host *host) { + host->sdio_irq_pending = true; queue_delayed_work(system_wq, &host->sdio_irq_work, 0); } EXPORT_SYMBOL_GPL(sdio_signal_irq); @@ -159,7 +163,6 @@ static int sdio_irq_thread(void *_host) if (ret) break; ret = process_sdio_pending_irqs(host); - host->sdio_irq_pending = false; mmc_release_host(host); /* From patchwork Thu Oct 3 15:53:02 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175164 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp579150ill; Thu, 3 Oct 2019 09:47:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqxr91GpI4fHV1uc7Gs7YOgW6+VR59fOavx3cs+xnjIHJagAaoQfVgZB9GuXioEQET0qOjM8 X-Received: by 2002:a17:906:d04f:: with SMTP id bo15mr8766152ejb.296.1570121277351; Thu, 03 Oct 2019 09:47:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570121277; cv=none; d=google.com; s=arc-20160816; b=Y7cKqV4aJKSIt/ryh+GtHKRak93uTAMB/T+OPmTFxU9BJW5yr/7jnfVG2aOMBPLpHa Zk/m4j80+OoHrU3OPIs1ROfg9WlitK2QCvyDPYn7Ca9N9h2nm6JnQ/tl2ZRrNnWse7ji CV1vsdIUP6Tiw7BBTAoiakkQfnNFkjYQa2k4VXFePW2GLWW9anGwtwtlGYyPAArS7F/k 0LR6DDp8rO6l50wgr8dZa39u9ZuX55RPziAbw4/SRurcgL1YVCh3XfgTadiQzuh//O4C eZzs7+4f7K0q2wL1t/gGDF5xJI5B/wjPtr18vz+OgEb0KOaZygg3RRMvESW4ubj06t1b A/AQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=7xusYlWhFKzzWiCXxRIOQvSBsEVKu1kjtnfarMQ9cYQ=; b=E0xp71LIbSUExM1KQzSy/PmFip7r4Xmj8bajU+UdUGTZgesnWRNkFrB0HMWv7TlSm3 zvwJZ7Ll1vAG/C9KPWLX5EQcU6HzOYUbGRHDVnYMx9Cd2p6FfiLtXIc2nobTtl0JPXV5 rPhWmDMMxNNU5yZaX13ZBvxyH8H9TGhrfEv2kGVX7ic5aRkV19cNAVYe47B0ty4YZR4X xmr0e2Lep6YfVJtstv+6x4dmOVw3eFCwk2ogS8Lfu952M16UqfEz8DCtC+wMsB3nbkWT KrT+N3YGyMW9vmmlh8Cd2sT2lwtkueRlLV7ME10dKQpOya8VDQNbVYgnHAaVmmlHdswL W31A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=SoTAn9Hr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m5si1518474ejr.125.2019.10.03.09.47.57; Thu, 03 Oct 2019 09:47:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=SoTAn9Hr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393041AbfJCQr4 (ORCPT + 27 others); Thu, 3 Oct 2019 12:47:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:33400 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2393029AbfJCQrx (ORCPT ); Thu, 3 Oct 2019 12:47:53 -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 657A62070B; Thu, 3 Oct 2019 16:47:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570121272; bh=dWZQeEXELj4oPCyvPKatzqbyZkyD3e/BEQa+Mm6YXN8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SoTAn9HrRhsSoLMUk8f8k6rBCr6FmUQJ0xSRpQ5IzvqhK1TXz5c6ntP3/tYoi/9mj HNgXSEZOgxyaV1L2+3ZIs4JA4LguYlhq7GQLP4oy6KWp0yUKz9EA6UQ6qICiq+7j8J PLza7exYPTG+sOLaq/EsmWQQxxz/j1C1EMOPz+9w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ulf Hansson , Sasha Levin Subject: [PATCH 5.3 217/344] mmc: mtk-sd: Re-store SDIO IRQs mask at system resume Date: Thu, 3 Oct 2019 17:53:02 +0200 Message-Id: <20191003154601.711711454@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ulf Hansson [ Upstream commit 1c81d69d4c98aab56c5a7d5a810f84aefdb37e9b ] In cases when SDIO IRQs have been enabled, runtime suspend is prevented by the driver. However, this still means msdc_runtime_suspend|resume() gets called during system suspend/resume, via pm_runtime_force_suspend|resume(). This means during system suspend/resume, the register context of the mtk-sd device most likely loses its register context, even in cases when SDIO IRQs have been enabled. To re-enable the SDIO IRQs during system resume, the mtk-sd driver currently relies on the mmc core to re-enable the SDIO IRQs when it resumes the SDIO card, but this isn't the recommended solution. Instead, it's better to deal with this locally in the mtk-sd driver, so let's do that. Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin --- drivers/mmc/host/mtk-sd.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.20.1 diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c index 33f4b6387ef71..978c8ccce7e31 100644 --- a/drivers/mmc/host/mtk-sd.c +++ b/drivers/mmc/host/mtk-sd.c @@ -2421,6 +2421,9 @@ static void msdc_restore_reg(struct msdc_host *host) } else { writel(host->save_para.pad_tune, host->base + tune_reg); } + + if (sdio_irq_claimed(host->mmc)) + __msdc_enable_sdio_irq(host, 1); } static int msdc_runtime_suspend(struct device *dev) From patchwork Thu Oct 3 15:53:56 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175167 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp589313ill; Thu, 3 Oct 2019 09:57:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqzRWrO8atSDXv+0x6XsfwBclGuLjs42WSoJuJruGAqwPjZpw70JH+Z66EEl2/cP/5184bMI X-Received: by 2002:a17:907:20eb:: with SMTP id rh11mr8416820ejb.25.1570121834833; Thu, 03 Oct 2019 09:57:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570121834; cv=none; d=google.com; s=arc-20160816; b=qwe4PdZoiZJHTagJP2G6/r/8A0SeE+j+r3HHFry3tU0u9lu+Yh60MZZXhENGx6NZnK FarMg+UydmCjy58zrXGzv+y+cxgG8X7Gt601OHLrJouqijI0da4LRQFEGXrn31edObPA kUE5+3BiKPG4QpSx4KFu9Zq/PqQTdJMzFSfEc6iOrdAUyRfl1YYQI21kCDW32C5KKnDJ WU/o1kxRPdBoLjbxd+9dhspMIPGC4gtIQsFk0mjKaybliWpWSGLsBCp7qrGNeYv6cET1 +QDHNnLMiyjOuyz5C6lxf8oHUz3kHEOCET1kaIywoRRaGyfDUmgAdUVfoDRr7w534715 b2gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=SUljDWYNpkbWUfdAsGBgy1pPlCItBaFY1ayUMkStQrY=; b=NEbSRbMUIEMAK8lqiyaeR1Pvvyhonoa9TqD05PJY30VWYEg+4r3e0qpK4Gqnfi8BEW f+T3Bg2V8ukfe09RRPlMzFFg+I7vsHUaBCkusvz1lD9hrz5VRwu5OQhWfEpc1lRN3mBm TdcrJUNsCokjr5yXTJeqZpxYuGd5OiHvXAXtltnOOMjlVPX7TuARNXozTk8XrdtoiboY CqZJoU1n+oDHO5Yuu9eO6dGwaIDM7FJdRrazv2zSzSi+DpnXyyHLWOn0C9g5OaIP8FCU zzOvveCCd+zGaXt9kdFa/uKS4hXBCT0Ri/aZ4PCI3IngiUvzGTev4IFQG4MYV1jvDtSY dw3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=aLQjdk8p; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d52si1836181ede.370.2019.10.03.09.57.14; Thu, 03 Oct 2019 09:57:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=aLQjdk8p; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732288AbfJCQ5M (ORCPT + 27 others); Thu, 3 Oct 2019 12:57:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:37276 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405013AbfJCQuQ (ORCPT ); Thu, 3 Oct 2019 12:50:16 -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 3C6D42070B; Thu, 3 Oct 2019 16:50:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570121415; bh=rv/sl+mL7lEXLkuRhSTikzTsj23M93TzHboTgmeC/qA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aLQjdk8pZ4d7NGlmXUpgs/O86qZU2Ky1NB53C+tXQQQGfyXBJWSRXhuxyiSx8W7Wh ao9YD6hCJr4f9qTWVJ+dUg5MdYIEw0FryzDIEt2J60A2k0EMLratJZ+2HewVhClnd2 +0YGtIYymLPKWZv7A3UJtI4scSZy/z5k74ZMW3lQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Max Kellermann , Wolfgang Rohdewald , Arnd Bergmann , Sean Young , Mauro Carvalho Chehab Subject: [PATCH 5.3 271/344] media: dont drop front-end reference count for ->detach Date: Thu, 3 Oct 2019 17:53:56 +0200 Message-Id: <20191003154606.976684706@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann commit 14e3cdbb00a885eedc95c0cf8eda8fe28d26d6b4 upstream. A bugfix introduce a link failure in configurations without CONFIG_MODULES: In file included from drivers/media/usb/dvb-usb/pctv452e.c:20:0: drivers/media/usb/dvb-usb/pctv452e.c: In function 'pctv452e_frontend_attach': drivers/media/dvb-frontends/stb0899_drv.h:151:36: error: weak declaration of 'stb0899_attach' being applied to a already existing, static definition The problem is that the !IS_REACHABLE() declaration of stb0899_attach() is a 'static inline' definition that clashes with the weak definition. I further observed that the bugfix was only done for one of the five users of stb0899_attach(), the other four still have the problem. This reverts the bugfix and instead addresses the problem by not dropping the reference count when calling '->detach()', instead we call this function directly in dvb_frontend_put() before dropping the kref on the front-end. I first submitted this in early 2018, and after some discussion it was apparently discarded. While there is a long-term plan in place, that plan is obviously not nearing completion yet, and the current kernel is still broken unless this patch is applied. Link: https://patchwork.kernel.org/patch/10140175/ Link: https://patchwork.linuxtv.org/patch/54831/ Cc: Max Kellermann Cc: Wolfgang Rohdewald Cc: stable@vger.kernel.org Fixes: f686c14364ad ("[media] stb0899: move code to "detach" callback") Fixes: 6cdeaed3b142 ("media: dvb_usb_pctv452e: module refcount changes were unbalanced") Signed-off-by: Arnd Bergmann Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman --- drivers/media/dvb-core/dvb_frontend.c | 4 +++- drivers/media/usb/dvb-usb/pctv452e.c | 8 -------- 2 files changed, 3 insertions(+), 9 deletions(-) --- a/drivers/media/dvb-core/dvb_frontend.c +++ b/drivers/media/dvb-core/dvb_frontend.c @@ -152,6 +152,9 @@ static void dvb_frontend_free(struct kre static void dvb_frontend_put(struct dvb_frontend *fe) { + /* call detach before dropping the reference count */ + if (fe->ops.detach) + fe->ops.detach(fe); /* * Check if the frontend was registered, as otherwise * kref was not initialized yet. @@ -3040,7 +3043,6 @@ void dvb_frontend_detach(struct dvb_fron dvb_frontend_invoke_release(fe, fe->ops.release_sec); dvb_frontend_invoke_release(fe, fe->ops.tuner_ops.release); dvb_frontend_invoke_release(fe, fe->ops.analog_ops.release); - dvb_frontend_invoke_release(fe, fe->ops.detach); dvb_frontend_put(fe); } EXPORT_SYMBOL(dvb_frontend_detach); --- a/drivers/media/usb/dvb-usb/pctv452e.c +++ b/drivers/media/usb/dvb-usb/pctv452e.c @@ -909,14 +909,6 @@ static int pctv452e_frontend_attach(stru &a->dev->i2c_adap); if (!a->fe_adap[0].fe) return -ENODEV; - - /* - * dvb_frontend will call dvb_detach for both stb0899_detach - * and stb0899_release but we only do dvb_attach(stb0899_attach). - * Increment the module refcount instead. - */ - symbol_get(stb0899_attach); - if ((dvb_attach(lnbp22_attach, a->fe_adap[0].fe, &a->dev->i2c_adap)) == NULL) err("Cannot attach lnbp22\n"); From patchwork Thu Oct 3 15:54:12 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 175166 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp585618ill; Thu, 3 Oct 2019 09:53:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqzIUTyNftDNe+YgNxBT4DfM81Y7s9/5UVLYBENk09/TgdY43R2Db08rGo4FyVLusaZz1G22 X-Received: by 2002:aa7:dd8e:: with SMTP id g14mr10512070edv.233.1570121474349; Thu, 03 Oct 2019 09:51:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570121474; cv=none; d=google.com; s=arc-20160816; b=AATYeUSt2bWIGh7cZBAA8SGColhz2ABsevhQ3uCdzW2xgBBIN8SwXlkvpMdfjKQrR4 vY12MGrATPHNnoYzxmS6CTOb+3RqYeVeC8adEf9o4/Wmwvi8CfG8BnWx1R5po2oP0GaA h8JS9Az7Awxvv9/nIzgjhZy43oqQ6BxAE6R+kz4TOyLQfvl31F8VhNN7Vma66sGeLPhd A5WeVvx0NAq6SyBgObLyhBxQI3KZcx2teP1/K2CSLVHHaaR0CH4DrGlO4rIAxC+3Wrig CRAs988C5YINL6WERyus6xYQrSyjG/qZQUUAVwYJP8gvFOd4p4vqjz3bdmeI7Z2tdrtK Y15g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=n5qeobAJvPPKl69IOKHJZeNyBj+uP9BLmTDhdyvT6lk=; b=SktGT0049zGz65zmWNyOZxQ8480KqyvXgY2Qnr03A+2HwqFgx8orayPgPx5c2FlGJJ AR4Qzkr+nxQ8vkhaq25Fue8IG0/kdR8jMNKbNkN+5R6CMrN9lFzWsGrtHAYZ9/CwASOy cMKDvRw+wNa1DCplcPxTbrHDFx5NjzF5092z7tkQni0NP42e43wE6aaHgY6k9dO49Nef meFuE5Ng91Nmak8MeI/iMWSxuPjs7+XXxRVgnq1keua43IjsdUUcRyB6MhaCOp0rDdSH LfknWciWVXjxHcRw+GHH0IFPTsof0dTcdRMbrXiBuc8TsIov5yNq5rs+5GyyiU+Mmcgg k1aw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=QTb50mI4; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d14si1529968ejr.358.2019.10.03.09.51.13; Thu, 03 Oct 2019 09:51:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=QTb50mI4; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406004AbfJCQvM (ORCPT + 27 others); Thu, 3 Oct 2019 12:51:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:38390 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405982AbfJCQvC (ORCPT ); Thu, 3 Oct 2019 12:51:02 -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 4CCA920867; Thu, 3 Oct 2019 16:51:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570121461; bh=GaFBzWQLwO+dySvhLRFxq60xkVTUnrkFqZ/q4+XN0xs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QTb50mI4YKs8s/n6Tfe/gwzWHvMRzdrO3PorNT3IfQQgBfxBRrY/HTyqFReEzO/WH V5Gglpl4pqG106vgxBDw64qfIqMB1bg3dgjV6uK59qVtRXka/f4A0sNQHFqotgGJHx GJdQukJQD5g+V8yLT4hQ/bA2liNQ8HrjeVFfFnZw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mark Brown , Lee Jones Subject: [PATCH 5.3 287/344] regulator: Defer init completion for a while after late_initcall Date: Thu, 3 Oct 2019 17:54:12 +0200 Message-Id: <20191003154608.151402340@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154540.062170222@linuxfoundation.org> References: <20191003154540.062170222@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mark Brown commit 55576cf1853798e86f620766e23b604c9224c19c upstream. The kernel has no way of knowing when we have finished instantiating drivers, between deferred probe and systems that build key drivers as modules we might be doing this long after userspace has booted. This has always been a bit of an issue with regulator_init_complete since it can power off hardware that's not had it's driver loaded which can result in user visible effects, the main case is powering off displays. Practically speaking it's not been an issue in real systems since most systems that use the regulator API are embedded and build in key drivers anyway but with Arm laptops coming on the market it's becoming more of an issue so let's do something about it. In the absence of any better idea just defer the powering off for 30s after late_initcall(), this is obviously a hack but it should mask the issue for now and it's no more arbitrary than late_initcall() itself. Ideally we'd have some heuristics to detect if we're on an affected system and tune or skip the delay appropriately, and there may be some need for a command line option to be added. Link: https://lore.kernel.org/r/20190904124250.25844-1-broonie@kernel.org Signed-off-by: Mark Brown Tested-by: Lee Jones Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- drivers/regulator/core.c | 42 +++++++++++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 11 deletions(-) --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -5640,7 +5640,7 @@ static int __init regulator_init(void) /* init early to allow our consumers to complete system booting */ core_initcall(regulator_init); -static int __init regulator_late_cleanup(struct device *dev, void *data) +static int regulator_late_cleanup(struct device *dev, void *data) { struct regulator_dev *rdev = dev_to_rdev(dev); const struct regulator_ops *ops = rdev->desc->ops; @@ -5689,18 +5689,9 @@ unlock: return 0; } -static int __init regulator_init_complete(void) +static void regulator_init_complete_work_function(struct work_struct *work) { /* - * Since DT doesn't provide an idiomatic mechanism for - * enabling full constraints and since it's much more natural - * with DT to provide them just assume that a DT enabled - * system has full constraints. - */ - if (of_have_populated_dt()) - has_full_constraints = true; - - /* * Regulators may had failed to resolve their input supplies * when were registered, either because the input supply was * not registered yet or because its parent device was not @@ -5717,6 +5708,35 @@ static int __init regulator_init_complet */ class_for_each_device(®ulator_class, NULL, NULL, regulator_late_cleanup); +} + +static DECLARE_DELAYED_WORK(regulator_init_complete_work, + regulator_init_complete_work_function); + +static int __init regulator_init_complete(void) +{ + /* + * Since DT doesn't provide an idiomatic mechanism for + * enabling full constraints and since it's much more natural + * with DT to provide them just assume that a DT enabled + * system has full constraints. + */ + if (of_have_populated_dt()) + has_full_constraints = true; + + /* + * We punt completion for an arbitrary amount of time since + * systems like distros will load many drivers from userspace + * so consumers might not always be ready yet, this is + * particularly an issue with laptops where this might bounce + * the display off then on. Ideally we'd get a notification + * from userspace when this happens but we don't so just wait + * a bit and hope we waited long enough. It'd be better if + * we'd only do this on systems that need it, and a kernel + * command line option might be useful. + */ + schedule_delayed_work(®ulator_init_complete_work, + msecs_to_jiffies(30000)); return 0; }