On Fri, Mar 31, 2017 at 12:02 AM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > On 28/03/17 19:37, Alison Schofield wrote: >> On Tue, Mar 28, 2017 at 10:55:17PM +0530, SIMRAN SINGHAL wrote: >>> On Fri, Mar 24, 2017 at 12:51 AM, Alison Schofield <amsfield22@xxxxxxxxx> wrote: >>>> On Fri, Mar 24, 2017 at 12:05:20AM +0530, simran singhal wrote: >>>>> The IIO subsystem is redefining iio_dev->mlock to be used by >>>>> the IIO core only for protecting device operating mode changes. >>>>> ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. >>>>> >>>>> In this driver, mlock was being used to protect hardware state >>>>> changes. Replace it with a lock in the devices global data. >>>> >>>> Hi Simran, >>>> >>>> Please post all revision histories below the --- not just the most >>>> recent. >>>> >>> Sorry, will not repeat this. >>> >>>> Does this lock enforce the needed "atomicity" in the write_frequency >>>> function? I read Jonathans comment on a previous revision about >>>> "ensuring the spi bus frequency and sampling frequency of the device >>>> are changed in an atomic fashion" >>>> >>> >>> By introducing another lock I am protecting read_modify_write and >>> in this way also protecting the designated register that we are about >>> to write. >> >> I see it protecting this path from being re-entered. My uncertainty >> is about other paths to read/write. >> >>> >>>> Is it possible for another spi bus transaction (read or write) to >>>> occur between the read and write in write_frequency? >>>> >>> >>> Gargi has also come up with a solution. >>> https://groups.google.com/forum/#!topic/outreachy-kernel/kzE9CrI5Bd8 >>> >>> Should I do like her as her's also seem correct or go ahead with this. >> >> My suggestion would be to wait for feedback on Gargi's patch. >> (See the Outreachy log about creating similar solutions.) >> >> We will not be able to close on this set of patches during the >> Outreachy application window. You can continue to push for closure >> beyond the March 30th date as your time allows :) >> > It is a close choice between the two approaches. In some ways > yours is easier to follow, but Gargi's is more elegant. > > Lets go with that one for consistency across similar drivers, > but if you had been the original author and done it this way > I certainly wouldn't bother asking you to change it! Yes, jonathan I am the original author. > > So in conclusion both patches are good. > > Jonathan > >> Thanks, >> alisons >> >>> >>>> alisons >>>>> >>>>> Signed-off-by: simran singhal <singhalsimran0@xxxxxxxxx> >>>>> --- >>>>> >>>>> v4: >>>>> -Add mutex_init >>>>> >>>>> drivers/staging/iio/meter/ade7753.c | 7 +++++-- >>>>> 1 file changed, 5 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/drivers/staging/iio/meter/ade7753.c b/drivers/staging/iio/meter/ade7753.c >>>>> index b71fbd3..30aebaf 100644 >>>>> --- a/drivers/staging/iio/meter/ade7753.c >>>>> +++ b/drivers/staging/iio/meter/ade7753.c >>>>> @@ -80,11 +80,13 @@ >>>>> * @us: actual spi_device >>>>> * @tx: transmit buffer >>>>> * @rx: receive buffer >>>>> + * @lock: protect sensor state >>>>> * @buf_lock: mutex to protect tx and rx >>>>> **/ >>>>> struct ade7753_state { >>>>> struct spi_device *us; >>>>> struct mutex buf_lock; >>>>> + struct mutex lock; /* protect sensor state */ >>>>> u8 tx[ADE7753_MAX_TX] ____cacheline_aligned; >>>>> u8 rx[ADE7753_MAX_RX]; >>>>> }; >>>>> @@ -484,7 +486,7 @@ static ssize_t ade7753_write_frequency(struct device *dev, >>>>> if (!val) >>>>> return -EINVAL; >>>>> >>>>> - mutex_lock(&indio_dev->mlock); >>>>> + mutex_lock(&st->lock); >>>>> >>>>> t = 27900 / val; >>>>> if (t > 0) >>>>> @@ -505,7 +507,7 @@ static ssize_t ade7753_write_frequency(struct device *dev, >>>>> ret = ade7753_spi_write_reg_16(dev, ADE7753_MODE, reg); >>>>> >>>>> out: >>>>> - mutex_unlock(&indio_dev->mlock); >>>>> + mutex_unlock(&st->lock); >>>>> >>>>> return ret ? ret : len; >>>>> } >>>>> @@ -581,6 +583,7 @@ static int ade7753_probe(struct spi_device *spi) >>>>> st = iio_priv(indio_dev); >>>>> st->us = spi; >>>>> mutex_init(&st->buf_lock); >>>>> + mutex_init(&st->lock); >>>>> >>>>> indio_dev->name = spi->dev.driver->name; >>>>> indio_dev->dev.parent = &spi->dev; >>>>> -- >>>>> 2.7.4 >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@xxxxxxxxxxxxxxxx. >>>>> To post to this group, send email to outreachy-kernel@xxxxxxxxxxxxxxxx. >>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/20170323183520.GA9871%40singhal-Inspiron-5558. >>>>> For more options, visit https://groups.google.com/d/optout. > -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
