From: Jonathan Cameron <jic23@kernel.org>
To: Brian Masney <masneyb@onstation.org>
Cc: linux-iio@vger.kernel.org, gregkh@linuxfoundation.org,
devel@driverdev.osuosl.org, knaack.h@gmx.de, lars@metafoo.de,
pmeerw@pmeerw.net, linux-kernel@vger.kernel.org,
Jon.Brenner@ams.com
Subject: Re: [PATCH 05/12] staging: iio: tsl2x7x: convert mutex_trylock() to mutex_lock()
Date: Sat, 10 Mar 2018 14:39:56 +0000 [thread overview]
Message-ID: <20180310143956.29443f83@archlinux> (raw)
In-Reply-To: <20180304014942.18727-6-masneyb@onstation.org>
On Sat, 3 Mar 2018 20:49:35 -0500
Brian Masney <masneyb@onstation.org> wrote:
> The driver uses mutex_lock() and mutex_trylock() in several places.
> Convert the mutex_trylock() to mutex_lock() for consistency with other
> IIO light drivers in mainline.
>
> Signed-off-by: Brian Masney <masneyb@onstation.org>
This was a little odd given we don't lock the device for long and all this
will do is slow down userspace access if it tries several at the same time
(a fairy uncommon usecase).
Applied
Thanks,
Jonathan
> ---
> drivers/staging/iio/light/tsl2x7x.c | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/iio/light/tsl2x7x.c b/drivers/staging/iio/light/tsl2x7x.c
> index cf16dd206c0b..5c611250127f 100644
> --- a/drivers/staging/iio/light/tsl2x7x.c
> +++ b/drivers/staging/iio/light/tsl2x7x.c
> @@ -350,8 +350,7 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
> u32 ch0lux = 0;
> u32 ch1lux = 0;
>
> - if (mutex_trylock(&chip->als_mutex) == 0)
> - return chip->als_cur_info.lux; /* busy, so return LAST VALUE */
> + mutex_lock(&chip->als_mutex);
>
> if (chip->tsl2x7x_chip_status != TSL2X7X_CHIP_WORKING) {
> /* device is not enabled */
> @@ -478,11 +477,7 @@ static int tsl2x7x_get_prox(struct iio_dev *indio_dev)
> u8 chdata[2];
> struct tsl2X7X_chip *chip = iio_priv(indio_dev);
>
> - if (mutex_trylock(&chip->prox_mutex) == 0) {
> - dev_err(&chip->client->dev,
> - "%s: Can't get prox mutex\n", __func__);
> - return -EBUSY;
> - }
> + mutex_lock(&chip->prox_mutex);
>
> ret = tsl2x7x_read_status(chip);
> if (ret < 0)
next prev parent reply other threads:[~2018-03-10 14:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-04 1:49 [PATCH 00/12] staging cleanups Brian Masney
2018-03-04 1:49 ` [PATCH 01/12] staging: iio: tsl2x7x: remove power functions from tsl2X7X_platform_data Brian Masney
2018-03-10 14:20 ` Jonathan Cameron
2018-03-04 1:49 ` [PATCH 02/12] staging: iio: tsl2x7x: add common function for clearing interrupts Brian Masney
2018-03-10 14:27 ` Jonathan Cameron
2018-03-04 1:49 ` [PATCH 03/12] staging: iio: tsl2x7x: add common function for reading chip status Brian Masney
2018-03-10 14:34 ` Jonathan Cameron
2018-03-04 1:49 ` [PATCH 04/12] staging: iio: tsl2x7x: add common function for writing to the control register Brian Masney
2018-03-10 14:36 ` Jonathan Cameron
2018-03-04 1:49 ` [PATCH 05/12] staging: iio: tsl2x7x: convert mutex_trylock() to mutex_lock() Brian Masney
2018-03-10 14:39 ` Jonathan Cameron [this message]
2018-03-04 1:49 ` [PATCH 06/12] staging: iio: tsl2x7x: correctly return errors in tsl2x7x_get_prox() Brian Masney
2018-03-10 14:42 ` Jonathan Cameron
2018-03-04 1:49 ` [PATCH 07/12] staging: iio: tsl2x7x: correct 'Avoid CamelCase' warning from checkpatch Brian Masney
2018-03-10 14:43 ` Jonathan Cameron
2018-03-04 1:49 ` [PATCH 08/12] staging: iio: tsl2x7x: add error handling to tsl2x7x_prox_cal() Brian Masney
2018-03-10 14:44 ` Jonathan Cameron
2018-03-04 1:49 ` [PATCH 09/12] staging: iio: tsl2x7x: add missing error checks Brian Masney
2018-03-10 14:45 ` Jonathan Cameron
2018-03-04 1:49 ` [PATCH 10/12] staging: iio: tsl2x7x: make logging consistent and correct newlines Brian Masney
2018-03-10 14:52 ` Jonathan Cameron
2018-03-11 13:45 ` Jonathan Cameron
2018-03-04 1:49 ` [PATCH 11/12] staging: iio: tsl2x7x: remove unnecessary sysfs attribute Brian Masney
2018-03-10 14:54 ` Jonathan Cameron
2018-03-04 1:49 ` [PATCH 12/12] staging: iio: tsl2x7x: make proximity sensor function correctly Brian Masney
2018-03-10 14:56 ` Jonathan Cameron
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=20180310143956.29443f83@archlinux \
--to=jic23@kernel.org \
--cc=Jon.Brenner@ams.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masneyb@onstation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).