From patchwork Thu Oct 3 15:51:52 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 175184 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp627168ill; Thu, 3 Oct 2019 10:26:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqx0ha3SsA3ThvUpUsBdoc7S3mHqLyml5oy+2cbYRykXM6WABoU7OgohZOsCJWXzOkbIYl0v X-Received: by 2002:a17:906:d926:: with SMTP id rn6mr8520559ejb.175.1570123575720; Thu, 03 Oct 2019 10:26:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570123575; cv=none; d=google.com; s=arc-20160816; b=bYmsV8z1LpriX2E51xNS+NMOYZwyQjDRZmSxFqvbhLwnPUUjxYAPenIQUn8df60G+t 9LnNUx20XoRQvhSjwED2R8xcQ00xC8wNIXC1RuJ5mx11XvfnnPdOg/37GjaQJvnJO+En w1AO3rTa+Mutx+CQNLSaewQcfbqIsc+5Uo6YVta2uP/CzP3M2m2IyUMMIFatvRizqtxY DD7l64GMR6QiBJZzhipy5rDjTER8u9VJYuOdefDXOHdNY60SeVxw3v1JFyeijRcH2vaU JyorgRW3AAEl0vYMfBlKlBYgiLNtaV1kgyVDV/jGq1hwVH3fW0YLn4N7syOQz/aVy4bM ylyw== 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=skfHzbnpMoMCzJP77C7m+dDMcBWSLaYi9HOKhfcMK5k=; b=gSNribW3XaQgfnQvtK9B25Ok8VA7iPF3CJf7HZGIb0Xt5iwHdBxNcVDHHR9d2XhWW/ vExx6NF4q56uHpO85oZrA2CwvCEIieTU3jeNa8rl6HexGzSAIFvlVuBfz/8pJjw9gr6l HnXUYgC1i0YqDKgwXCbjUc8P3YyTfjX/r5HUzLJ6N6bPykGa7jvwRuhqJsgcCUDle6/K 1TKv7wkzc8X2OrpnJ3wYepvTUFUYDzZ2W5DFtPdLHcZJPXqAFHzxFO8ZbO7+TnGXFuv8 2G+gy2Be22V+5hlYUqp99XOaGAr8UifEEIa4Mkbft4Ihfik7bws8fkgIHT9fFNSq3EvR 2/eg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Tgkw+Mjl; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 s17si1565483ejz.148.2019.10.03.10.26.15; Thu, 03 Oct 2019 10:26:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-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=Tgkw+Mjl; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730592AbfJCR0K (ORCPT + 14 others); Thu, 3 Oct 2019 13:26:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:41352 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388969AbfJCQQZ (ORCPT ); Thu, 3 Oct 2019 12:16:25 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E423D20700; Thu, 3 Oct 2019 16:16:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570119384; bh=REPlmJ3AG9u8ggMbAE/uWkhiDbswCFmGAr0G8TJ0BKE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Tgkw+Mjl2Z/PxXOCD1b2BUHiP//FQf+0EaS1C0SUQPXg+GvOtP4c2CwVMv5T4iusU DkRi00GC/P8gMNSX+sQsQe+S4R83YuG6SiIiS9Ormkq2FMhf7M0n+dpLi1ksG6IC1j S0hWnZKHZ00+i5AKbqG5PsPzpkwJWUO5ceKxzgMM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Robert Richter , Borislav Petkov , "linux-edac@vger.kernel.org" , James Morse , Mauro Carvalho Chehab , Tony Luck , Sasha Levin Subject: [PATCH 4.19 046/211] EDAC/mc: Fix grain_bits calculation Date: Thu, 3 Oct 2019 17:51:52 +0200 Message-Id: <20191003154458.628881944@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154447.010950442@linuxfoundation.org> References: <20191003154447.010950442@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Robert Richter [ Upstream commit 3724ace582d9f675134985727fd5e9811f23c059 ] The grain in EDAC is defined as "minimum granularity for an error report, in bytes". The following calculation of the grain_bits in edac_mc is wrong: grain_bits = fls_long(e->grain) + 1; Where grain_bits is defined as: grain = 1 << grain_bits Example: grain = 8 # 64 bit (8 bytes) grain_bits = fls_long(8) + 1 grain_bits = 4 + 1 = 5 grain = 1 << grain_bits grain = 1 << 5 = 32 Replace it with the correct calculation: grain_bits = fls_long(e->grain - 1); The example gives now: grain_bits = fls_long(8 - 1) grain_bits = fls_long(7) grain_bits = 3 grain = 1 << 3 = 8 Also, check if the hardware reports a reasonable grain != 0 and fallback with a warning to 1 byte granularity otherwise. [ bp: massage a bit. ] Signed-off-by: Robert Richter Signed-off-by: Borislav Petkov Cc: "linux-edac@vger.kernel.org" Cc: James Morse Cc: Mauro Carvalho Chehab Cc: Tony Luck Link: https://lkml.kernel.org/r/20190624150758.6695-2-rrichter@marvell.com Signed-off-by: Sasha Levin --- drivers/edac/edac_mc.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) -- 2.20.1 diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c index 7d3edd7139328..f59511bd99261 100644 --- a/drivers/edac/edac_mc.c +++ b/drivers/edac/edac_mc.c @@ -1246,9 +1246,13 @@ void edac_mc_handle_error(const enum hw_event_mc_err_type type, if (p > e->location) *(p - 1) = '\0'; - /* Report the error via the trace interface */ - grain_bits = fls_long(e->grain) + 1; + /* Sanity-check driver-supplied grain value. */ + if (WARN_ON_ONCE(!e->grain)) + e->grain = 1; + + grain_bits = fls_long(e->grain - 1); + /* Report the error via the trace interface */ if (IS_ENABLED(CONFIG_RAS)) trace_mc_event(type, e->msg, e->label, e->error_count, mci->mc_idx, e->top_layer, e->mid_layer, From patchwork Thu Oct 3 15:52:09 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 175112 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp540244ill; Thu, 3 Oct 2019 09:17:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqylQa/P0GRfxo35j3kcUPMVxUvRf52Qbkb6vURQJS+soyxaq6IjZtJnW7m20anYFLu67LZL X-Received: by 2002:a17:906:828c:: with SMTP id h12mr8466188ejx.155.1570119441096; Thu, 03 Oct 2019 09:17:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570119441; cv=none; d=google.com; s=arc-20160816; b=lyub1V/MgtJmEnGYtV/2tyTMrCZZuHeejsBiydqmU84A03V49u3wYEO3jhCjkGvGJr KOFAfHyzINYqHT1I3vFN7BLD4ogPxAdMZbSw3wu5ip+2tCF5N4xng56jOAGN+eHtD/oS gCcBT5wMcEurEnlQ9vNupeDlMSrp+A46JBGPOscyMAe3rSHgCFYNnYwJJQFwGZS9W8cL cZU40SscWhFaCJMpxKPc0FPdo1RoJ5UgdQGaUMxUjZ7rz0ZFwcOAUpFeFyl+FTeTE0mW pQiDXV9l2gb713BbEXVCW/OMI8eNVbl0J6fjkjbOLZAosE97BbEOm2e8lNlzaXnDoIYv QZ0g== 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=Qrq66J2UiLjPgoxZGtd/ihjJBmHxOxsotE9335B0LJs=; b=k1+G/C1xQzphc2uwNzJgIkiNeoOXropDCu45HJ8nb6QiBKDxF0srnZRbICzrxZejLS sajaodHPTlT6beTZyCpGz3iiHWw9OlNDd3LXQ6HZGEYsMA/cTeinSPS2joLMYXgklTeC ysYlgs7hDA8JVN3WTyC65845uTxXHfvPny/rVh2N5JUYf2wcA6VYhUdtQiodIezWcVn8 bviao8EF+Hz4MlusTVefDTyhzNvpWtsIHTONV0ols6JKDGPnLTIe5dTThstFev67ZjvK MxDqW1M8pB80E7qv/9jN/29iIm/WQg7gg0Mkhv9LomQFq1A2ajCus0mIh/zAG8Nj0Fgq dlwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=XjOPlZcT; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 d26si1686202edq.91.2019.10.03.09.17.20; Thu, 03 Oct 2019 09:17:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-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=XjOPlZcT; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732422AbfJCQRR (ORCPT + 14 others); Thu, 3 Oct 2019 12:17:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:42910 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389205AbfJCQRR (ORCPT ); Thu, 3 Oct 2019 12:17: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 0F7B320700; Thu, 3 Oct 2019 16:17:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570119436; bh=Oh+7ZXgLTx07OWwHyaxKMRlgpijwLPFXyLLpXRu+Qls=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XjOPlZcT6E21D6T99/2ymp2LaxC+TMlDCi1q4itAHYnMCnBNmybFNuTbgkoe4JlYO etznXaQXurRKBKTLnAZaFGw8B/k/o7Oqt9MnWU309uGpE1Fc4bms9NSUxFC3BNCdft bba0ZSSqaQGIqn4eBM6kXpmM9TbkEPAx8M9w9fa4= 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 4.19 063/211] firmware: arm_scmi: Check if platform has released shmem before using Date: Thu, 3 Oct 2019 17:52:09 +0200 Message-Id: <20191003154502.983205965@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154447.010950442@linuxfoundation.org> References: <20191003154447.010950442@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: 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 8f952f2f1a292..09119e3f5c018 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:52:31 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 175182 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp621133ill; Thu, 3 Oct 2019 10:21:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqw1X58yYCHT60nWL+dDkOVwPniDWv4et2afD1gCXGtZT6C93hrOj4L0FswrGCgY3Cne4+oP X-Received: by 2002:a05:6402:16d5:: with SMTP id r21mr10556374edx.71.1570123260896; Thu, 03 Oct 2019 10:21:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570123260; cv=none; d=google.com; s=arc-20160816; b=M0PVgRhHHIivbKZqjLL9ulR5qMpoPvHiFlLmV3R1KDok48lJf0XCe3Q1CK3geK8LWm dfRc4Ps5L2VLIz0LFjXjUDiIPb5aLh1NsDi1tQrKxtqdppMCGPO75Cmn7e1AdzZXyPWI cgSSUmCvCxEsOgbPYPHYt0CsonoGiIcVzh5HLEnOxhx9SA3P5MoOWpsLKq1jFBn20vT8 Uwn02gSU95bt6hEWLcoc36zDcxwXOn4F7H2RV0z6tCLMznDs9Mq3Nyes6xKo56oktjVS N004KO5vZixsAC6JvBXLjEVInOlh8rBJAPO//mswlEVv/SCc4NFgvjsqU12yDOfdzr06 zCPQ== 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=bG82j6nkHEFFD5Ujw068bnRh0NUhjROzv5KY78CLMPAP//xHzXn3F4PPBZ+/Ews/5c Xb8s6LaOGCjfcLqiUXU0N5ke/0pGGBQuvHWLv4zE6iblgj90mcMcgZ+gnUmGj6RfPR83 Ih9ZCgLgcqK221gKpBZGI73qAAsqf7AzYdAxCNLSLib8iyrgFfkUXwAT32JSJpTin9tQ fEhe5CSZbYMi14rnb/CEIrvMIcOMloISUy33FSL8z1WkATNJPjx/RxTX04IM5C5CPxse J7HvoPMyvPA1deBx5NrrNl37hWsfXq5cXDuzVSQwcNhKZ3F1+iTLyavwGSnUVI3zqsC6 8sJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=E7DVvZPo; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 y44si1935733edb.251.2019.10.03.10.21.00; Thu, 03 Oct 2019 10:21:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-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=E7DVvZPo; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390393AbfJCRUp (ORCPT + 14 others); Thu, 3 Oct 2019 13:20:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:44668 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389572AbfJCQSL (ORCPT ); Thu, 3 Oct 2019 12:18: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 73FAE2133F; Thu, 3 Oct 2019 16:18:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570119490; bh=izJSz9zwaSm5xge40Tyl2gKrXmgr/JkniLuCjKggVes=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E7DVvZPoeaC5kEZv0pwC+2S9ixtLKFrxVXeeUj9MknuDTJIdElg2Gcuf1OFudyW+q yDNhBitfxKjnba/8x4xnRjWyMLodShIYtOwtaivkKLmGv/6fi2I0JKJGsHyLKjuIoR SEV7qmtiuI0gspTnaoe8RHOkV8HRrUADB7t83Cko= 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 4.19 085/211] ASoC: uniphier: Fix double reset assersion when transitioning to suspend state Date: Thu, 3 Oct 2019 17:52:31 +0200 Message-Id: <20191003154506.476502103@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154447.010950442@linuxfoundation.org> References: <20191003154447.010950442@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: 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:52:55 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 175114 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp543101ill; Thu, 3 Oct 2019 09:19:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqy80nDFSjKOdq9zKlwxbdHzVPQe5bXtMA2t3Ip1qkod5wQmu3nqt4b7S0K1ReVXvEAS69tT X-Received: by 2002:a17:906:90d4:: with SMTP id v20mr8636742ejw.189.1570119565943; Thu, 03 Oct 2019 09:19:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570119565; cv=none; d=google.com; s=arc-20160816; b=qCE1D9hKJGaXFYwEbpcP7ZbtWyD7PEh0moD5UffkxXYnkwpTcr2zVg2AbuR6fw7NAn P0xFxE3uibKrbe4qbWX6q1a6vDvYZ3lrlPO9c3Q2zMjHulH13AOEZmYgMZBYFDBM3Tlw BuoHqjMSyTTKbT1kOV76EYbg8K2HGUmGnn/lZ3NHZZMt5b1zeYwaESmNRIR7plk0FqT/ Ohsxsv5zXuUZhL7NyFq183oF0UNl0exdW75Gc2EPJHVbVvleJ7TcI2ffuKuG2gHNo6D5 r76QaoFyMjzFQHk3PvkeowApxL+iZQLGUtTHS0/7Z97DoF9voYKdqRo3LpmGWQ59j83K /RLA== 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=9pUp8RyE+XXL5os/Cu61Mh8Sq3I3VsACfPOYVMs9tZ8=; b=aLluF4PpnSYn4+KoKzSat2nOJJnAlBXoSvGJHSh8fivDpH7hmbfcGd6QeFlZxuopPz k1Gk14LtmXj6tWxmUdvH3im017W/A5+DBaqwpejc37l1I34UQxrqydie5fGoqcZl1V30 S71uFbhTb4Dl/Yy3PGjr9HEdI6Ff3IdzXWlUw+bx6wYvR0Us+KWdPZx9DTYeN139tG0g kgOyyPF1jnhkSCxh2aOXTGslNNky73IrWY6NWXCuEfXopYc1nWiRcU8h6BjcfcVzAx1e whWK/kKkm5cP1sjZLQVlGnFM35b0ATv5FNUs8DHmpz4jjxiI1f2b6B06B2f7ShHIlCHn 3yIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=LjMnI3+n; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 ot41si1444054ejb.215.2019.10.03.09.19.25; Thu, 03 Oct 2019 09:19:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-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=LjMnI3+n; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388174AbfJCQTY (ORCPT + 14 others); Thu, 3 Oct 2019 12:19:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:46324 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387497AbfJCQTV (ORCPT ); Thu, 3 Oct 2019 12:19:21 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BD0EB2054F; Thu, 3 Oct 2019 16:19:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570119561; bh=URUZzsuEtvmqgS69CvYyDYYGVRNJ0Jzif+eoUQ1PBvo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LjMnI3+nj6LVEp5O7KAsMdqFeFfecUu2MUy9oz5tTd2KfdJpPdlhYcUxub48IE8xd fopLl8IQxUo7FGoZfshKM6OfDVYIMcqw0YX7lLMJhGomsS7OOofjhRAOJZsOpNv8Ji WIM2V0wfe7wvpcsG4il79QXb8Oizf/bzXsLmNKd4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mark Rutland , Catalin Marinas , James Morse , Will Deacon , Sasha Levin Subject: [PATCH 4.19 109/211] arm64: kpti: ensure patched kernel text is fetched from PoU Date: Thu, 3 Oct 2019 17:52:55 +0200 Message-Id: <20191003154512.244293884@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154447.010950442@linuxfoundation.org> References: <20191003154447.010950442@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mark Rutland [ Upstream commit f32c7a8e45105bd0af76872bf6eef0438ff12fb2 ] While the MMUs is disabled, I-cache speculation can result in instructions being fetched from the PoC. During boot we may patch instructions (e.g. for alternatives and jump labels), and these may be dirty at the PoU (and stale at the PoC). Thus, while the MMU is disabled in the KPTI pagetable fixup code we may load stale instructions into the I-cache, potentially leading to subsequent crashes when executing regions of code which have been modified at runtime. Similarly to commit: 8ec41987436d566f ("arm64: mm: ensure patched kernel text is fetched from PoU") ... we can invalidate the I-cache after enabling the MMU to prevent such issues. The KPTI pagetable fixup code itself should be clean to the PoC per the boot protocol, so no maintenance is required for this code. Signed-off-by: Mark Rutland Cc: Catalin Marinas Reviewed-by: James Morse Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- arch/arm64/mm/proc.S | 9 +++++++++ 1 file changed, 9 insertions(+) -- 2.20.1 diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S index 8cce091b6c21e..ec6aa18633162 100644 --- a/arch/arm64/mm/proc.S +++ b/arch/arm64/mm/proc.S @@ -294,6 +294,15 @@ skip_pgd: msr sctlr_el1, x18 isb + /* + * Invalidate the local I-cache so that any instructions fetched + * speculatively from the PoC are discarded, since they may have + * been dynamically patched at the PoU. + */ + ic iallu + dsb nsh + isb + /* Set the flag to zero to indicate that we're all done */ str wzr, [flag_ptr] ret From patchwork Thu Oct 3 15:53:22 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 175117 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp544725ill; Thu, 3 Oct 2019 09:20:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqxkslsN5l9urWSnHZ+vwg1df5mMo5IY2vaZcLGvJsIaALJ4sjhA75b6qA6iN0j7pg+P34/O X-Received: by 2002:a17:906:e297:: with SMTP id gg23mr8313193ejb.47.1570119635505; Thu, 03 Oct 2019 09:20:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570119635; cv=none; d=google.com; s=arc-20160816; b=KMNby+Eu9Y5ifSF0C23Psisg73ZWaLwZ1M/K1VhZFvIKkMERtxWHpjJhqhfXC8teUq 2ycf4Ue3P58BpMTFTstj2yp+bokX7Qz36JgnAsmpZWKLrPSpqKkHBvTNr6zGT8nH4KcM 3zL7s2c9SAnRfw+rGDsbBdDMSbyQpv8SIJnN7nxbR3ILkaveuqPNGMssqyoNOkGGl4Bs JuM/KwRuEWAGQte37vyQGH/wQ9IKaRhZ8T07piSKkXJ/sfTz05cHXdGVuSnx7g1SvQW/ 55rffUl/3ziNR4wOIq+93TrK2P36xAhsDxrWLjdSNz9rVk/6Q5p8Oewd+a093+QCyNCE 8/+g== 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=YtNiCp9tv6jPL6Tl8j8y3bz6AR2tFrlYDEM4Bhl/18A=; b=yJ70HBGDbGDi9IJxQZoRvhVYctSr4l9xzxLqbZhD75KBSBhOBPN0HPeF/P8aiuVG4c seUUCZu7UzHRQMHpEh+SlkP+7aKltb8IDanvRNWF65DjlsxL94JrCQNcJz8312Wtxlld nD/Dn8NbE9X+9ZAc5ssdEzpQWqel12bSvvUXWSk4WWrBad4xcsqJwqFGrWsA2c6TPQhI TCI59Afh/x+9EQy4N/3/x4rS3vJb1A9Mmg2/ZyaC0e719mK+BXxXV5KodQPF4Zcjc6Mc vJW4zcAn2JgpGxL59qKZYk9TEw6kV7hYxUEYGvbGiMFFbjf/Mu17Y8j9vFy7pQvJzMnj 4C7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=SBH6riL5; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 g90si1919517edd.329.2019.10.03.09.20.34; Thu, 03 Oct 2019 09:20:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-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=SBH6riL5; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389928AbfJCQUe (ORCPT + 14 others); Thu, 3 Oct 2019 12:20:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:48298 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731517AbfJCQUd (ORCPT ); Thu, 3 Oct 2019 12:20:33 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 90DB720865; Thu, 3 Oct 2019 16:20:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570119633; bh=+hiAlNfbSBPF8qKfDkfN4sNImtyxNSb/HIggk7vL2UE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SBH6riL5/qd/BA9nrJf1OjUpZAune74uhhx5DzC0qoPVx/us5Eaj/aXg/q+ch1xkV iGexVsgvcCQRaJs6AkLekpgQM+fFUto3lAqzf+KjljNJJK+ddGvugo48lZ2q5FSQlB JB57GzYXeESN6iFQUrOB82LpGJ1wR6cWNkvYbnio= 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 4.19 136/211] mmc: dw_mmc: Re-store SDIO IRQs mask at system resume Date: Thu, 3 Oct 2019 17:53:22 +0200 Message-Id: <20191003154518.185905298@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154447.010950442@linuxfoundation.org> References: <20191003154447.010950442@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Ulf Hansson [ Upstream commit 7c526608d5afb62cbc967225e2ccaacfdd142e9d ] In cases when SDIO IRQs have been enabled, runtime suspend is prevented by the driver. However, this still means dw_mci_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 dw_mmc 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 dw_mmc 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 dw_mmc driver, so let's do that. Tested-by: Matthias Kaehlcke Signed-off-by: Ulf Hansson Reviewed-by: Douglas Anderson Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin --- drivers/mmc/host/dw_mmc.c | 4 ++++ 1 file changed, 4 insertions(+) -- 2.20.1 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 942da07c9eb87..22c454c7aaca6 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -3486,6 +3486,10 @@ int dw_mci_runtime_resume(struct device *dev) /* Force setup bus to guarantee available clock output */ dw_mci_setup_bus(host->slot, true); + /* Re-enable SDIO interrupts. */ + if (sdio_irq_claimed(host->slot->mmc)) + __dw_mci_enable_sdio_irq(host->slot, 1); + /* Now that slots are all setup, we can enable card detect */ dw_mci_enable_cd(host); From patchwork Thu Oct 3 15:54:06 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 175123 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp549205ill; Thu, 3 Oct 2019 09:24:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqwPvkfzogK9Aex1WSBznJtUxF+6ffIM0iuAkq6+gXQUc0rxlYD0dfYvgcW+81TASqIV0/s4 X-Received: by 2002:a17:906:c79a:: with SMTP id cw26mr8337174ejb.265.1570119762524; Thu, 03 Oct 2019 09:22:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570119762; cv=none; d=google.com; s=arc-20160816; b=dNcJzeFZfQjiu+63pUudx/Vaxo0Rfk+F4Q7Fnr71PW8afzYvAFfAhxHQgy58bhwuh2 2Lcl6eyjtB9iSw+LOA1IXa5zyayviYmPOv7IvxbIK/bzat3dVu1fCLgJQLIH5IZOtrhA fy2JN8vqYHWjKSQLx+glJgeh5RBk8v1r+Ykoou9aTtkKUPN3zYjoGuT+KGFp81pa/N40 hmuoPCogZdKUfOWkBNNQYGJEnCVLSjDHVD9gHKjBv+aordUvymrShxno7RCXysefPY0H Qcf3x/DBn3xf/sqYZn/zFlvEf4wTahQ0j3yla1lJ4Znci2DBa620vn8Dxig8hWbXhm9I f0Fw== 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=0GKoO9jmZPRYpMRPoO82KM5BDBmvU+BmaUdYvygjXdQ=; b=yYHGzIdZ/rcjpGIcakb36Hgwx9/9NRH4GsdneJA1zmUk/Vcx/qOLGUI6iKKhVIANvP heXTVV1sYffh3jGB6Xn5piXeLf98+2ACUZS8yr8kL+SaK/ebcFXVqyeLW1ET253t9m6O cldU4hcKow5xhdXFzdlZXf/Ze9xCdGKZU2/ddhQaV7udhd2eT9zya5mxxU4NVQDZlk+9 nw+bKa1Jss7dhDXR8x00csGvvIq18pixRa0Gp4b3p50Qs1GgOjhQiEcWwOEGD4q6WxiP EobCBTVFkc7nswbJtVPws+lnGVBdc6GKLWdgkkLL2NUOlrQRm/3YNhGWIoWGwKNxpgcG BI7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=bHqH9a7H; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 r9si1466232eju.10.2019.10.03.09.22.42; Thu, 03 Oct 2019 09:22:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-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=bHqH9a7H; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390338AbfJCQWf (ORCPT + 14 others); Thu, 3 Oct 2019 12:22:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:51252 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390333AbfJCQWe (ORCPT ); Thu, 3 Oct 2019 12:22:34 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D1CB7215EA; Thu, 3 Oct 2019 16:22:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570119753; bh=iJES15h1t2wVL0pPglc2PLGWkPNnaLGEqbTRypL0zkQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bHqH9a7HriKzrgqun8Or1/jeF90ZOg2iTv6XZSoZx9DwIjQVWucuOOOy0RoNCrOWw CGv4dY+LBOESuNDDLcAC28Bu/zZd+KEmMf7aNaBRrBHMGXCpfIQecZ21h8wronAgw4 RxFdbI754tsM/M3RaBUhD9bq3xjoKjKopxEEkY4w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mark Brown , Lee Jones Subject: [PATCH 4.19 180/211] regulator: Defer init completion for a while after late_initcall Date: Thu, 3 Oct 2019 17:54:06 +0200 Message-Id: <20191003154527.299754434@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191003154447.010950442@linuxfoundation.org> References: <20191003154447.010950442@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: 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 @@ -4789,7 +4789,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; @@ -4838,18 +4838,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 @@ -4866,6 +4857,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)); class_for_each_device(®ulator_class, NULL, NULL, regulator_register_fill_coupling_array);