From: Sasha Levin <sashal@kernel.org>
To: gregkh@linuxfoundation.org
Cc: hdegoede@redhat.com, andriy.shevchenko@linux.intel.com,
mika.westerberg@linux.intel.com, stable@vger.kernel.org
Subject: Re: FAILED: patch "[PATCH] pinctrl: baytrail: Really serialize all register accesses" failed to apply to 4.19-stable tree
Date: Wed, 1 Jan 2020 20:05:21 -0500 [thread overview]
Message-ID: <20200102010521.GD16372@sasha-vm> (raw)
In-Reply-To: <1577634412127144@kroah.com>
On Sun, Dec 29, 2019 at 04:46:52PM +0100, gregkh@linuxfoundation.org wrote:
>
>The patch below does not apply to the 4.19-stable tree.
>If someone wants it applied there, or to any other stable or longterm
>tree, then please email the backport, including the original git commit
>id to <stable@vger.kernel.org>.
>
>thanks,
>
>greg k-h
>
>------------------ original commit in Linus's tree ------------------
>
>From 40ecab551232972a39cdd8b6f17ede54a3fdb296 Mon Sep 17 00:00:00 2001
>From: Hans de Goede <hdegoede@redhat.com>
>Date: Tue, 19 Nov 2019 16:46:41 +0100
>Subject: [PATCH] pinctrl: baytrail: Really serialize all register accesses
>
>Commit 39ce8150a079 ("pinctrl: baytrail: Serialize all register access")
>added a spinlock around all register accesses because:
>
>"There is a hardware issue in Intel Baytrail where concurrent GPIO register
> access might result reads of 0xffffffff and writes might get dropped
> completely."
>
>Testing has shown that this does not catch all cases, there are still
>2 problems remaining
>
>1) The original fix uses a spinlock per byt_gpio device / struct,
>additional testing has shown that this is not sufficient concurent
>accesses to 2 different GPIO banks also suffer from the same problem.
>
>This commit fixes this by moving to a single global lock.
>
>2) The original fix did not add a lock around the register accesses in
>the suspend/resume handling.
>
>Since pinctrl-baytrail.c is using normal suspend/resume handlers,
>interrupts are still enabled during suspend/resume handling. Nothing
>should be using the GPIOs when they are being taken down, _but_ the
>GPIOs themselves may still cause interrupts, which are likely to
>use (read) the triggering GPIO. So we need to protect against
>concurrent GPIO register accesses in the suspend/resume handlers too.
>
>This commit fixes this by adding the missing spin_lock / unlock calls.
>
>The 2 fixes together fix the Acer Switch 10 SW5-012 getting completely
>confused after a suspend resume. The DSDT for this device has a bug
>in its _LID method which reprograms the home and power button trigger-
>flags requesting both high and low _level_ interrupts so the IRQs for
>these 2 GPIOs continuously fire. This combined with the saving of
>registers during suspend, triggers concurrent GPIO register accesses
>resulting in saving 0xffffffff as pconf0 value during suspend and then
>when restoring this on resume the pinmux settings get all messed up,
>resulting in various I2C busses being stuck, the wifi no longer working
>and often the tablet simply not coming out of suspend at all.
>
>Cc: stable@vger.kernel.org
>Fixes: 39ce8150a079 ("pinctrl: baytrail: Serialize all register access")
>Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
There were quite a few variable/struct renames in the file which
resulted in conflicts. I've fixed them up and queued for all branches.
--
Thanks,
Sasha
next prev parent reply other threads:[~2020-01-02 1:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-29 15:46 FAILED: patch "[PATCH] pinctrl: baytrail: Really serialize all register accesses" failed to apply to 4.19-stable tree gregkh
2020-01-02 1:05 ` Sasha Levin [this message]
2020-01-02 14:29 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200102010521.GD16372@sasha-vm \
--to=sashal@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=mika.westerberg@linux.intel.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.