From: Gargi Sharma <gs051095@gmail.com>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: Alison Schofield <amsfield22@gmail.com>,
outreachy-kernel@googlegroups.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org, knaack.h@gmx.de,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
linux-iio@vger.kernel.org
Subject: Re: [Outreachy kernel] [PATCH] staging: iio: adc: Replace mlock with driver private lock
Date: Mon, 13 Mar 2017 14:11:28 +0530 [thread overview]
Message-ID: <CAOCi2DGcpoN791cH82nKWYdYdS82MmfJeUpcTcUSG9cbEw3Q4g@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1703122321140.7649@hadrien>
On Mon, Mar 13, 2017 at 3:57 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>> Please insert the new lock above the __cacheline_aligned struct
>> member.
>
> Regrettably, at the moment, Coccinelle can't help you find this. It could
> help if there is something particular about the type.
>
>
>> I like the automated editing because it certainly cuts down on typos,
>> and even with this one, you can just move the new lock field upon
>> inspection. Sadly, I don't think the script will apply too widely
>> because the use of "_state" for driver global data isn't a standard,
>> nor availability of that struct in the functions needing the locking.
>
> The _state is part of a metavariable name. It doesn't have any impact on
> what is matched.
>
>> That sadness expressed ;) we do have a boatload of drivers upstream
>> that will eventually make this migration, so the value of the cocci
>> script would go beyond these 15 staging drivers. That's valuable.
>>
>> Let's make sure anything done with any automated tools is walked
>> through thoroughly. Per the task description: this is not intended
>> as a search&replace exercise.
>
> Automation is great, modulo the need to manually check the result.
> However, it could be better not to include in the commit log semantic
> patches that are too far off from what updates the driver in a safe way.
> It doesn't have to update all drivers safely, but it should work for the
> modified one. The goal should be to complement the log message text, not
> to make the reader confused :)
Will it be better if I remove the script from the commit log here? That way the
confusion can be prevented :)
Thanks!
Gargi
>
> julia
>
>> alisons
>>
>>
>> > > >>
>> > > >> Signed-off-by: Gargi Sharma <gs051095@gmail.com>
>> > > >> ---
>> > > >> drivers/staging/iio/adc/ad7280a.c | 21 +++++++++++----------
>> > > >> 1 file changed, 11 insertions(+), 10 deletions(-)
>> > > >>
>> > > >> diff --git a/drivers/staging/iio/adc/ad7280a.c b/drivers/staging/iio/adc/ad7280a.c
>> > > >> index ee679ac..27a3ce3 100644
>> > > >> --- a/drivers/staging/iio/adc/ad7280a.c
>> > > >> +++ b/drivers/staging/iio/adc/ad7280a.c
>> > > >> @@ -136,6 +136,7 @@ struct ad7280_state {
>> > > >> unsigned char cb_mask[AD7280A_MAX_CHAIN];
>> > > >>
>> > > >> __be32 buf[2] ____cacheline_aligned;
>> > > >> + struct mutex lock; /* protect sensor state */
>> > > >> };
>> > > >>
>> > > >> static void ad7280_crc8_build_table(unsigned char *crc_tab)
>> > > >> @@ -410,7 +411,7 @@ static ssize_t ad7280_store_balance_sw(struct device *dev,
>> > > >> devaddr = this_attr->address >> 8;
>> > > >> ch = this_attr->address & 0xFF;
>> > > >>
>> > > >> - mutex_lock(&indio_dev->mlock);
>> > > >> + mutex_lock(&st->lock);
>> > > >> if (readin)
>> > > >> st->cb_mask[devaddr] |= 1 << (ch + 2);
>> > > >> else
>> > > >> @@ -418,7 +419,7 @@ static ssize_t ad7280_store_balance_sw(struct device *dev,
>> > > >>
>> > > >> ret = ad7280_write(st, devaddr, AD7280A_CELL_BALANCE,
>> > > >> 0, st->cb_mask[devaddr]);
>> > > >> - mutex_unlock(&indio_dev->mlock);
>> > > >> + mutex_unlock(&st->lock);
>> > > >>
>> > > >> return ret ? ret : len;
>> > > >> }
>> > > >> @@ -433,10 +434,10 @@ static ssize_t ad7280_show_balance_timer(struct device *dev,
>> > > >> int ret;
>> > > >> unsigned int msecs;
>> > > >>
>> > > >> - mutex_lock(&indio_dev->mlock);
>> > > >> + mutex_lock(&st->lock);
>> > > >> ret = ad7280_read(st, this_attr->address >> 8,
>> > > >> this_attr->address & 0xFF);
>> > > >> - mutex_unlock(&indio_dev->mlock);
>> > > >> + mutex_unlock(&st->lock);
>> > > >>
>> > > >> if (ret < 0)
>> > > >> return ret;
>> > > >> @@ -466,11 +467,11 @@ static ssize_t ad7280_store_balance_timer(struct device *dev,
>> > > >> if (val > 31)
>> > > >> return -EINVAL;
>> > > >>
>> > > >> - mutex_lock(&indio_dev->mlock);
>> > > >> + mutex_lock(&st->lock);
>> > > >> ret = ad7280_write(st, this_attr->address >> 8,
>> > > >> this_attr->address & 0xFF,
>> > > >> 0, (val & 0x1F) << 3);
>> > > >> - mutex_unlock(&indio_dev->mlock);
>> > > >> + mutex_unlock(&st->lock);
>> > > >>
>> > > >> return ret ? ret : len;
>> > > >> }
>> > > >> @@ -655,7 +656,7 @@ static ssize_t ad7280_write_channel_config(struct device *dev,
>> > > >>
>> > > >> val = clamp(val, 0L, 0xFFL);
>> > > >>
>> > > >> - mutex_lock(&indio_dev->mlock);
>> > > >> + mutex_lock(&st->lock);
>> > > >> switch ((u32)this_attr->address) {
>> > > >> case AD7280A_CELL_OVERVOLTAGE:
>> > > >> st->cell_threshhigh = val;
>> > > >> @@ -674,7 +675,7 @@ static ssize_t ad7280_write_channel_config(struct device *dev,
>> > > >> ret = ad7280_write(st, AD7280A_DEVADDR_MASTER,
>> > > >> this_attr->address, 1, val);
>> > > >>
>> > > >> - mutex_unlock(&indio_dev->mlock);
>> > > >> + mutex_unlock(&st->lock);
>> > > >>
>> > > >> return ret ? ret : len;
>> > > >> }
>> > > >> @@ -792,13 +793,13 @@ static int ad7280_read_raw(struct iio_dev *indio_dev,
>> > > >>
>> > > >> switch (m) {
>> > > >> case IIO_CHAN_INFO_RAW:
>> > > >> - mutex_lock(&indio_dev->mlock);
>> > > >> + mutex_lock(&st->lock);
>> > > >> if (chan->address == AD7280A_ALL_CELLS)
>> > > >> ret = ad7280_read_all_channels(st, st->scan_cnt, NULL);
>> > > >> else
>> > > >> ret = ad7280_read_channel(st, chan->address >> 8,
>> > > >> chan->address & 0xFF);
>> > > >> - mutex_unlock(&indio_dev->mlock);
>> > > >> + mutex_unlock(&st->lock);
>> > > >>
>> > > >> if (ret < 0)
>> > > >> return ret;
>> > > >> --
>> > > >> 2.7.4
>> > > >>
>> > > >> --
>> > >
>> >
>> > --
next prev parent reply other threads:[~2017-03-13 8:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-12 20:45 [PATCH] staging: iio: adc: Replace mlock with driver private lock Gargi Sharma
2017-03-12 20:56 ` [Outreachy kernel] " Julia Lawall
2017-03-12 21:33 ` Gargi Sharma
2017-03-12 21:37 ` Julia Lawall
2017-03-12 22:13 ` Alison Schofield
2017-03-12 22:27 ` Julia Lawall
2017-03-13 8:41 ` Gargi Sharma [this message]
2017-03-15 9:44 ` Julia Lawall
2017-03-13 8:40 ` Gargi Sharma
2017-03-13 20:40 ` Julia Lawall
2017-03-13 20:50 ` Jonathan Cameron
2017-03-13 21:09 ` Julia Lawall
2017-03-13 20:51 ` Jonathan Cameron
2017-03-13 20:54 ` Lars-Peter Clausen
2017-03-13 21:25 ` Jonathan Cameron
2017-03-14 17:36 ` Gargi Sharma
2017-03-14 22:44 ` Jonathan Cameron
2017-03-15 18:15 ` Gargi Sharma
2017-03-16 17:41 ` Alison Schofield
2017-03-16 17:45 ` Alison Schofield
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=CAOCi2DGcpoN791cH82nKWYdYdS82MmfJeUpcTcUSG9cbEw3Q4g@mail.gmail.com \
--to=gs051095@gmail.com \
--cc=Michael.Hennerich@analog.com \
--cc=amsfield22@gmail.com \
--cc=jic23@kernel.org \
--cc=julia.lawall@lip6.fr \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=outreachy-kernel@googlegroups.com \
--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).