From: Matthias Kaehlcke <mka@chromium.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Jonathan Cameron <jic23@kernel.org>,
Hartmut Knaack <knaack.h@gmx.de>,
Lars-Peter Clausen <lars@metafoo.de>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Benson Leung <bleung@chromium.org>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Guenter Roeck <groeck@chromium.org>,
linux-iio <linux-iio@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Gwendal Grignou <gwendal@chromium.org>
Subject: Re: [PATCH] iio: cros_ec_accel_legacy: Always release lock when returning from _read()
Date: Mon, 15 Jul 2019 12:50:23 -0700 [thread overview]
Message-ID: <20190715195023.GS250418@google.com> (raw)
In-Reply-To: <CAD=FV=WT6TT+iyGVNUhNcmAsVJip6X4mytuNJPGwMkk4F4i75g@mail.gmail.com>
On Mon, Jul 15, 2019 at 12:40:42PM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, Jul 15, 2019 at 12:10 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > Before doing any actual work cros_ec_accel_legacy_read() acquires
> > a mutex, which is released at the end of the function. However for
> > 'calibbias' channels the function returns directly, without releasing
> > the lock. The next attempt to acquire the lock blocks forever. Instead
> > of an explicit return statement use the common return path, which
> > releases the lock.
> >
> > Fixes: 11b86c7004ef1 ("platform/chrome: Add cros_ec_accel_legacy driver")
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> > drivers/iio/accel/cros_ec_accel_legacy.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
>
> See also <https://lkml.kernel.org/r/39403a4c-bf7f-6a98-890c-57397fa66493@collabora.com>
>
> Actually, the "Fixes" tag is wrong here, though. The problem only
> exists because we have <https://crrev.com/c/1632659> in our tree, AKA
> ("FROMLIST: iio: cros_ec : Extend legacy support to ARM device").
> Before that there was no mutex. For upstream purposes this could
> probably be squashed into the original patch.
Oops, I didn't realize that upstream doesn't have the mutex. In this
case the entire patch as is with it's commit message doesn't make much
sense.
next prev parent reply other threads:[~2019-07-15 19:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-15 19:10 [PATCH] iio: cros_ec_accel_legacy: Always release lock when returning from _read() Matthias Kaehlcke
2019-07-15 19:40 ` Doug Anderson
2019-07-15 19:50 ` Matthias Kaehlcke [this message]
2019-07-15 19:55 ` Benson Leung
2019-07-15 20:04 ` Matthias Kaehlcke
2019-07-15 23:17 ` Gwendal Grignou
2019-07-15 23:19 ` Gwendal Grignou
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=20190715195023.GS250418@google.com \
--to=mka@chromium.org \
--cc=bleung@chromium.org \
--cc=dianders@chromium.org \
--cc=enric.balletbo@collabora.com \
--cc=groeck@chromium.org \
--cc=gwendal@chromium.org \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
/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.