* [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code @ 2017-03-20 7:39 Gargi Sharma 2017-03-21 17:24 ` [Outreachy kernel] " Alison Schofield 2017-03-21 19:45 ` Jonathan Cameron 0 siblings, 2 replies; 10+ messages in thread From: Gargi Sharma @ 2017-03-20 7:39 UTC (permalink / raw) To: outreachy-kernel Cc: linux-iio, lars, Michael.Hennerich, jic23, knaack.h, pmeerw, gregkh, Gargi Sharma 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 buf_lock in the devices global data. As buf_lock already protects operations in ade7754_write_frequency, there isn't a need to acquire the lock inside ade7754_spi_write_reg_8 when writing to the register. Signed-off-by: Gargi Sharma <gs051095@gmail.com> --- drivers/staging/iio/meter/ade7754.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/staging/iio/meter/ade7754.c b/drivers/staging/iio/meter/ade7754.c index 024463a..eb03469 100644 --- a/drivers/staging/iio/meter/ade7754.c +++ b/drivers/staging/iio/meter/ade7754.c @@ -29,6 +29,15 @@ static int ade7754_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val) struct iio_dev *indio_dev = dev_to_iio_dev(dev); struct ade7754_state *st = iio_priv(indio_dev); + if (reg_address == ADE7754_WAVMODE) { + st->tx[0] = ADE7754_WRITE_REG(reg_address); + st->tx[1] = val; + + ret = spi_write(st->us, st->tx, 2); + + return ret; + } + mutex_lock(&st->buf_lock); st->tx[0] = ADE7754_WRITE_REG(reg_address); st->tx[1] = val; @@ -430,7 +439,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, if (!val) return -EINVAL; - mutex_lock(&indio_dev->mlock); + mutex_lock(&st->buf_lock); t = 26000 / val; if (t > 0) @@ -451,7 +460,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, ret = ade7754_spi_write_reg_8(dev, ADE7754_WAVMODE, reg); out: - mutex_unlock(&indio_dev->mlock); + mutex_unlock(&st->buf_lock); return ret ? ret : len; } -- 2.7.4 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [Outreachy kernel] [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code 2017-03-20 7:39 [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code Gargi Sharma @ 2017-03-21 17:24 ` Alison Schofield 2017-03-21 17:48 ` Gargi Sharma 2017-03-21 19:45 ` Jonathan Cameron 1 sibling, 1 reply; 10+ messages in thread From: Alison Schofield @ 2017-03-21 17:24 UTC (permalink / raw) To: Gargi Sharma Cc: outreachy-kernel, linux-iio, lars, Michael.Hennerich, jic23, knaack.h, pmeerw, gregkh On Mon, Mar 20, 2017 at 01:09:21PM +0530, Gargi Sharma 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 buf_lock in the devices global data. > > As buf_lock already protects operations in ade7754_write_frequency, > there isn't a need to acquire the lock inside ade7754_spi_write_reg_8 > when writing to the register. Hi Gargi, Looks like something went wrong in your patch below. It doesn't do what you say it'll do...Instead of removing the lock from _write_reg_8() it inserts a bunch of code. Anyway, it seems that w_rite_reg_8() is used in multiple places, so removing that lock doesn't appear to be an option. See below... alisons > > Signed-off-by: Gargi Sharma <gs051095@gmail.com> > --- > drivers/staging/iio/meter/ade7754.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/iio/meter/ade7754.c b/drivers/staging/iio/meter/ade7754.c > index 024463a..eb03469 100644 > --- a/drivers/staging/iio/meter/ade7754.c > +++ b/drivers/staging/iio/meter/ade7754.c > @@ -29,6 +29,15 @@ static int ade7754_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val) > struct iio_dev *indio_dev = dev_to_iio_dev(dev); > struct ade7754_state *st = iio_priv(indio_dev); > > + if (reg_address == ADE7754_WAVMODE) { > + st->tx[0] = ADE7754_WRITE_REG(reg_address); > + st->tx[1] = val; > + > + ret = spi_write(st->us, st->tx, 2); > + > + return ret; > + } > + What's this? > mutex_lock(&st->buf_lock); > st->tx[0] = ADE7754_WRITE_REG(reg_address); > st->tx[1] = val; > @@ -430,7 +439,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, > if (!val) > return -EINVAL; > > - mutex_lock(&indio_dev->mlock); > + mutex_lock(&st->buf_lock); > > t = 26000 / val; > if (t > 0) > @@ -451,7 +460,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, > ret = ade7754_spi_write_reg_8(dev, ADE7754_WAVMODE, reg); > > out: > - mutex_unlock(&indio_dev->mlock); > + mutex_unlock(&st->buf_lock); > > return ret ? ret : len; > } > -- > 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@googlegroups.com. > To post to this group, send email to outreachy-kernel@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1489995561-6988-1-git-send-email-gs051095%40gmail.com. > For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Outreachy kernel] [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code 2017-03-21 17:24 ` [Outreachy kernel] " Alison Schofield @ 2017-03-21 17:48 ` Gargi Sharma 2017-03-21 18:12 ` Alison Schofield 0 siblings, 1 reply; 10+ messages in thread From: Gargi Sharma @ 2017-03-21 17:48 UTC (permalink / raw) To: Alison Schofield Cc: outreachy-kernel, linux-iio, Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler, Greg KH On Tue, Mar 21, 2017 at 10:54 PM, Alison Schofield <amsfield22@gmail.com> wrote: > On Mon, Mar 20, 2017 at 01:09:21PM +0530, Gargi Sharma 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 buf_lock in the devices global data. >> >> As buf_lock already protects operations in ade7754_write_frequency, >> there isn't a need to acquire the lock inside ade7754_spi_write_reg_8 >> when writing to the register. > > Hi Gargi, > > Looks like something went wrong in your patch below. It doesn't do what > you say it'll do...Instead of removing the lock from _write_reg_8() > it inserts a bunch of code. Anyway, it seems that w_rite_reg_8() is used > in multiple places, so removing that lock doesn't appear to be an > option. > > See below... > > alisons > >> >> Signed-off-by: Gargi Sharma <gs051095@gmail.com> >> --- >> drivers/staging/iio/meter/ade7754.c | 13 +++++++++++-- >> 1 file changed, 11 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/staging/iio/meter/ade7754.c b/drivers/staging/iio/meter/ade7754.c >> index 024463a..eb03469 100644 >> --- a/drivers/staging/iio/meter/ade7754.c >> +++ b/drivers/staging/iio/meter/ade7754.c >> @@ -29,6 +29,15 @@ static int ade7754_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val) >> struct iio_dev *indio_dev = dev_to_iio_dev(dev); >> struct ade7754_state *st = iio_priv(indio_dev); >> >> + if (reg_address == ADE7754_WAVMODE) { >> + st->tx[0] = ADE7754_WRITE_REG(reg_address); >> + st->tx[1] = val; >> + >> + ret = spi_write(st->us, st->tx, 2); >> + >> + return ret; >> + } >> + > What's this? When the function ade_spi_write_reg_8() is called inside ade7754_write_frequency(), we are writing to this( ADE7754_WAVMODE) register. When writing to this register we don't need to hold the buf_lock since ade7754_write_frequency() already takes care of that. > >> mutex_lock(&st->buf_lock); >> st->tx[0] = ADE7754_WRITE_REG(reg_address); >> st->tx[1] = val; >> @@ -430,7 +439,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, >> if (!val) >> return -EINVAL; >> >> - mutex_lock(&indio_dev->mlock); >> + mutex_lock(&st->buf_lock); >> >> t = 26000 / val; >> if (t > 0) >> @@ -451,7 +460,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, >> ret = ade7754_spi_write_reg_8(dev, ADE7754_WAVMODE, reg); >> >> out: >> - mutex_unlock(&indio_dev->mlock); >> + mutex_unlock(&st->buf_lock); >> >> return ret ? ret : len; >> } The buf_lock inside ade7754_write_frequency() takes into account that when using the function ade7754_spi_write_reg_8, lock is already held and locking is no longer required inside the ade7754_spi_write_reg_8() function. Let me know if this sounds okay, I can perhaps edit the commit log to make this clearer. Thanks, Gargi >> -- >> 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@googlegroups.com. >> To post to this group, send email to outreachy-kernel@googlegroups.com. >> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1489995561-6988-1-git-send-email-gs051095%40gmail.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > 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@googlegroups.com. > To post to this group, send email to outreachy-kernel@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/20170321172438.GC2793%40d830.WORKGROUP. > For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Outreachy kernel] [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code 2017-03-21 17:48 ` Gargi Sharma @ 2017-03-21 18:12 ` Alison Schofield 2017-03-21 18:18 ` Gargi Sharma 0 siblings, 1 reply; 10+ messages in thread From: Alison Schofield @ 2017-03-21 18:12 UTC (permalink / raw) To: Gargi Sharma Cc: outreachy-kernel, linux-iio, Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler, Greg KH On Tue, Mar 21, 2017 at 11:18:23PM +0530, Gargi Sharma wrote: > On Tue, Mar 21, 2017 at 10:54 PM, Alison Schofield <amsfield22@gmail.com> wrote: > > On Mon, Mar 20, 2017 at 01:09:21PM +0530, Gargi Sharma 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 buf_lock in the devices global data. > >> > >> As buf_lock already protects operations in ade7754_write_frequency, > >> there isn't a need to acquire the lock inside ade7754_spi_write_reg_8 > >> when writing to the register. > > > > Hi Gargi, > > > > Looks like something went wrong in your patch below. It doesn't do what > > you say it'll do...Instead of removing the lock from _write_reg_8() > > it inserts a bunch of code. Anyway, it seems that w_rite_reg_8() is used > > in multiple places, so removing that lock doesn't appear to be an > > option. > > > > See below... > > > > alisons > > > >> > >> Signed-off-by: Gargi Sharma <gs051095@gmail.com> > >> --- > >> drivers/staging/iio/meter/ade7754.c | 13 +++++++++++-- > >> 1 file changed, 11 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/staging/iio/meter/ade7754.c b/drivers/staging/iio/meter/ade7754.c > >> index 024463a..eb03469 100644 > >> --- a/drivers/staging/iio/meter/ade7754.c > >> +++ b/drivers/staging/iio/meter/ade7754.c > >> @@ -29,6 +29,15 @@ static int ade7754_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val) > >> struct iio_dev *indio_dev = dev_to_iio_dev(dev); > >> struct ade7754_state *st = iio_priv(indio_dev); > >> > >> + if (reg_address == ADE7754_WAVMODE) { > >> + st->tx[0] = ADE7754_WRITE_REG(reg_address); > >> + st->tx[1] = val; > >> + > >> + ret = spi_write(st->us, st->tx, 2); > >> + > >> + return ret; > >> + } > >> + > > What's this? > > When the function ade_spi_write_reg_8() is called inside > ade7754_write_frequency(), we are writing to this( ADE7754_WAVMODE) > register. When writing to this register we don't need to hold the > buf_lock since ade7754_write_frequency() already takes care of that. Oh! I see it now. You created a special 'no lock needed' case inside of --write_reg_8 for writing frequency. That works, but it's...ummm...sneaky ;) Let's see if there's another way. Look back at Lars suggestion on a similar patch. Maybe that will apply here. http://marc.info/?l=linux-kernel&m=148940648615743&w=2 alisons > > > > >> mutex_lock(&st->buf_lock); > >> st->tx[0] = ADE7754_WRITE_REG(reg_address); > >> st->tx[1] = val; > >> @@ -430,7 +439,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, > >> if (!val) > >> return -EINVAL; > >> > >> - mutex_lock(&indio_dev->mlock); > >> + mutex_lock(&st->buf_lock); > >> > >> t = 26000 / val; > >> if (t > 0) > >> @@ -451,7 +460,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, > >> ret = ade7754_spi_write_reg_8(dev, ADE7754_WAVMODE, reg); > >> > >> out: > >> - mutex_unlock(&indio_dev->mlock); > >> + mutex_unlock(&st->buf_lock); > >> > >> return ret ? ret : len; > >> } > > The buf_lock inside ade7754_write_frequency() takes into account that > when using the function ade7754_spi_write_reg_8, lock is already held > and locking is no longer required inside the ade7754_spi_write_reg_8() > function. > > Let me know if this sounds okay, I can perhaps edit the commit log to > make this clearer. > > Thanks, > Gargi > > >> -- > >> 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@googlegroups.com. > >> To post to this group, send email to outreachy-kernel@googlegroups.com. > >> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1489995561-6988-1-git-send-email-gs051095%40gmail.com. > >> For more options, visit https://groups.google.com/d/optout. > > > > -- > > 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@googlegroups.com. > > To post to this group, send email to outreachy-kernel@googlegroups.com. > > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/20170321172438.GC2793%40d830.WORKGROUP. > > For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Outreachy kernel] [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code 2017-03-21 18:12 ` Alison Schofield @ 2017-03-21 18:18 ` Gargi Sharma 2017-03-21 18:54 ` Alison Schofield 2017-03-21 20:12 ` Alison Schofield 0 siblings, 2 replies; 10+ messages in thread From: Gargi Sharma @ 2017-03-21 18:18 UTC (permalink / raw) To: Alison Schofield Cc: outreachy-kernel, linux-iio, Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler, Greg KH On Tue, Mar 21, 2017 at 11:42 PM, Alison Schofield <amsfield22@gmail.com> wrote: > On Tue, Mar 21, 2017 at 11:18:23PM +0530, Gargi Sharma wrote: >> On Tue, Mar 21, 2017 at 10:54 PM, Alison Schofield <amsfield22@gmail.com> wrote: >> > On Mon, Mar 20, 2017 at 01:09:21PM +0530, Gargi Sharma 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 buf_lock in the devices global data. >> >> >> >> As buf_lock already protects operations in ade7754_write_frequency, >> >> there isn't a need to acquire the lock inside ade7754_spi_write_reg_8 >> >> when writing to the register. >> > >> > Hi Gargi, >> > >> > Looks like something went wrong in your patch below. It doesn't do what >> > you say it'll do...Instead of removing the lock from _write_reg_8() >> > it inserts a bunch of code. Anyway, it seems that w_rite_reg_8() is used >> > in multiple places, so removing that lock doesn't appear to be an >> > option. >> > >> > See below... >> > >> > alisons >> > >> >> >> >> Signed-off-by: Gargi Sharma <gs051095@gmail.com> >> >> --- >> >> drivers/staging/iio/meter/ade7754.c | 13 +++++++++++-- >> >> 1 file changed, 11 insertions(+), 2 deletions(-) >> >> >> >> diff --git a/drivers/staging/iio/meter/ade7754.c b/drivers/staging/iio/meter/ade7754.c >> >> index 024463a..eb03469 100644 >> >> --- a/drivers/staging/iio/meter/ade7754.c >> >> +++ b/drivers/staging/iio/meter/ade7754.c >> >> @@ -29,6 +29,15 @@ static int ade7754_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val) >> >> struct iio_dev *indio_dev = dev_to_iio_dev(dev); >> >> struct ade7754_state *st = iio_priv(indio_dev); >> >> >> >> + if (reg_address == ADE7754_WAVMODE) { >> >> + st->tx[0] = ADE7754_WRITE_REG(reg_address); >> >> + st->tx[1] = val; >> >> + >> >> + ret = spi_write(st->us, st->tx, 2); >> >> + >> >> + return ret; >> >> + } >> >> + >> > What's this? >> >> When the function ade_spi_write_reg_8() is called inside >> ade7754_write_frequency(), we are writing to this( ADE7754_WAVMODE) >> register. When writing to this register we don't need to hold the >> buf_lock since ade7754_write_frequency() already takes care of that. > > Oh! I see it now. You created a special 'no lock needed' case > inside of --write_reg_8 for writing frequency. That works, > but it's...ummm...sneaky ;) Let's see if there's another way. > > Look back at Lars suggestion on a similar patch. Maybe that > will apply here. > http://marc.info/?l=linux-kernel&m=148940648615743&w=2 > I did look at the patch you suggested for inspiration :) What I could not understand was the part where Lars wrote about "doing a read-modify-write cycle in a protected section." I can write a separate function for --write_reg_8 that does not take the lock, but do not know how to do a "read-modify-write cycle in a protected section" :( Gargi > alisons > > >> >> > >> >> mutex_lock(&st->buf_lock); >> >> st->tx[0] = ADE7754_WRITE_REG(reg_address); >> >> st->tx[1] = val; >> >> @@ -430,7 +439,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, >> >> if (!val) >> >> return -EINVAL; >> >> >> >> - mutex_lock(&indio_dev->mlock); >> >> + mutex_lock(&st->buf_lock); >> >> >> >> t = 26000 / val; >> >> if (t > 0) >> >> @@ -451,7 +460,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, >> >> ret = ade7754_spi_write_reg_8(dev, ADE7754_WAVMODE, reg); >> >> >> >> out: >> >> - mutex_unlock(&indio_dev->mlock); >> >> + mutex_unlock(&st->buf_lock); >> >> >> >> return ret ? ret : len; >> >> } >> >> The buf_lock inside ade7754_write_frequency() takes into account that >> when using the function ade7754_spi_write_reg_8, lock is already held >> and locking is no longer required inside the ade7754_spi_write_reg_8() >> function. >> >> Let me know if this sounds okay, I can perhaps edit the commit log to >> make this clearer. >> >> Thanks, >> Gargi >> >> >> -- >> >> 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@googlegroups.com. >> >> To post to this group, send email to outreachy-kernel@googlegroups.com. >> >> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1489995561-6988-1-git-send-email-gs051095%40gmail.com. >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > -- >> > 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@googlegroups.com. >> > To post to this group, send email to outreachy-kernel@googlegroups.com. >> > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/20170321172438.GC2793%40d830.WORKGROUP. >> > For more options, visit https://groups.google.com/d/optout. > > -- > 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@googlegroups.com. > To post to this group, send email to outreachy-kernel@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/20170321181207.GA10699%40d830.WORKGROUP. > For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Outreachy kernel] [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code 2017-03-21 18:18 ` Gargi Sharma @ 2017-03-21 18:54 ` Alison Schofield 2017-03-21 20:12 ` Alison Schofield 1 sibling, 0 replies; 10+ messages in thread From: Alison Schofield @ 2017-03-21 18:54 UTC (permalink / raw) To: Gargi Sharma, Lars-Peter Clausen Cc: outreachy-kernel, linux-iio, Michael Hennerich, Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler, Greg KH On Tue, Mar 21, 2017 at 11:48:27PM +0530, Gargi Sharma wrote: > On Tue, Mar 21, 2017 at 11:42 PM, Alison Schofield <amsfield22@gmail.com> wrote: > > On Tue, Mar 21, 2017 at 11:18:23PM +0530, Gargi Sharma wrote: > >> On Tue, Mar 21, 2017 at 10:54 PM, Alison Schofield <amsfield22@gmail.com> wrote: > >> > On Mon, Mar 20, 2017 at 01:09:21PM +0530, Gargi Sharma 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 buf_lock in the devices global data. > >> >> > >> >> As buf_lock already protects operations in ade7754_write_frequency, > >> >> there isn't a need to acquire the lock inside ade7754_spi_write_reg_8 > >> >> when writing to the register. > >> > > >> > Hi Gargi, > >> > > >> > Looks like something went wrong in your patch below. It doesn't do what > >> > you say it'll do...Instead of removing the lock from _write_reg_8() > >> > it inserts a bunch of code. Anyway, it seems that w_rite_reg_8() is used > >> > in multiple places, so removing that lock doesn't appear to be an > >> > option. > >> > > >> > See below... > >> > > >> > alisons > >> > > >> >> > >> >> Signed-off-by: Gargi Sharma <gs051095@gmail.com> > >> >> --- > >> >> drivers/staging/iio/meter/ade7754.c | 13 +++++++++++-- > >> >> 1 file changed, 11 insertions(+), 2 deletions(-) > >> >> > >> >> diff --git a/drivers/staging/iio/meter/ade7754.c b/drivers/staging/iio/meter/ade7754.c > >> >> index 024463a..eb03469 100644 > >> >> --- a/drivers/staging/iio/meter/ade7754.c > >> >> +++ b/drivers/staging/iio/meter/ade7754.c > >> >> @@ -29,6 +29,15 @@ static int ade7754_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val) > >> >> struct iio_dev *indio_dev = dev_to_iio_dev(dev); > >> >> struct ade7754_state *st = iio_priv(indio_dev); > >> >> > >> >> + if (reg_address == ADE7754_WAVMODE) { > >> >> + st->tx[0] = ADE7754_WRITE_REG(reg_address); > >> >> + st->tx[1] = val; > >> >> + > >> >> + ret = spi_write(st->us, st->tx, 2); > >> >> + > >> >> + return ret; > >> >> + } > >> >> + > >> > What's this? > >> > >> When the function ade_spi_write_reg_8() is called inside > >> ade7754_write_frequency(), we are writing to this( ADE7754_WAVMODE) > >> register. When writing to this register we don't need to hold the > >> buf_lock since ade7754_write_frequency() already takes care of that. > > > > Oh! I see it now. You created a special 'no lock needed' case > > inside of --write_reg_8 for writing frequency. That works, > > but it's...ummm...sneaky ;) Let's see if there's another way. > > > > Look back at Lars suggestion on a similar patch. Maybe that > > will apply here. > > http://marc.info/?l=linux-kernel&m=148940648615743&w=2 > > > > I did look at the patch you suggested for inspiration :) What I could > not understand was the part where Lars wrote about "doing a > read-modify-write cycle in a protected section." I can write a > separate function for --write_reg_8 that does not take the lock, but > do not know how to do a "read-modify-write cycle in a protected > section" :( > > Gargi Gargi - That's a great, specific question! Let's pop that back to Lars. Lars - Can you explain further or perhaps point to a driver that does something similar? alisons > > alisons > > > > > >> > >> > > >> >> mutex_lock(&st->buf_lock); > >> >> st->tx[0] = ADE7754_WRITE_REG(reg_address); > >> >> st->tx[1] = val; > >> >> @@ -430,7 +439,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, > >> >> if (!val) > >> >> return -EINVAL; > >> >> > >> >> - mutex_lock(&indio_dev->mlock); > >> >> + mutex_lock(&st->buf_lock); > >> >> > >> >> t = 26000 / val; > >> >> if (t > 0) > >> >> @@ -451,7 +460,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, > >> >> ret = ade7754_spi_write_reg_8(dev, ADE7754_WAVMODE, reg); > >> >> > >> >> out: > >> >> - mutex_unlock(&indio_dev->mlock); > >> >> + mutex_unlock(&st->buf_lock); > >> >> > >> >> return ret ? ret : len; > >> >> } > >> > >> The buf_lock inside ade7754_write_frequency() takes into account that > >> when using the function ade7754_spi_write_reg_8, lock is already held > >> and locking is no longer required inside the ade7754_spi_write_reg_8() > >> function. > >> > >> Let me know if this sounds okay, I can perhaps edit the commit log to > >> make this clearer. > >> > >> Thanks, > >> Gargi > >> > >> >> -- > >> >> 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@googlegroups.com. > >> >> To post to this group, send email to outreachy-kernel@googlegroups.com. > >> >> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1489995561-6988-1-git-send-email-gs051095%40gmail.com. > >> >> For more options, visit https://groups.google.com/d/optout. > >> > > >> > -- > >> > 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@googlegroups.com. > >> > To post to this group, send email to outreachy-kernel@googlegroups.com. > >> > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/20170321172438.GC2793%40d830.WORKGROUP. > >> > For more options, visit https://groups.google.com/d/optout. > > > > -- > > 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@googlegroups.com. > > To post to this group, send email to outreachy-kernel@googlegroups.com. > > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/20170321181207.GA10699%40d830.WORKGROUP. > > For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Outreachy kernel] [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code 2017-03-21 18:18 ` Gargi Sharma 2017-03-21 18:54 ` Alison Schofield @ 2017-03-21 20:12 ` Alison Schofield 1 sibling, 0 replies; 10+ messages in thread From: Alison Schofield @ 2017-03-21 20:12 UTC (permalink / raw) To: Gargi Sharma Cc: outreachy-kernel, linux-iio, Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler, Greg KH On Tue, Mar 21, 2017 at 11:48:27PM +0530, Gargi Sharma wrote: > On Tue, Mar 21, 2017 at 11:42 PM, Alison Schofield <amsfield22@gmail.com> wrote: > > On Tue, Mar 21, 2017 at 11:18:23PM +0530, Gargi Sharma wrote: > >> On Tue, Mar 21, 2017 at 10:54 PM, Alison Schofield <amsfield22@gmail.com> wrote: > >> > On Mon, Mar 20, 2017 at 01:09:21PM +0530, Gargi Sharma 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 buf_lock in the devices global data. > >> >> > >> >> As buf_lock already protects operations in ade7754_write_frequency, > >> >> there isn't a need to acquire the lock inside ade7754_spi_write_reg_8 > >> >> when writing to the register. > >> > > >> > Hi Gargi, > >> > > >> > Looks like something went wrong in your patch below. It doesn't do what > >> > you say it'll do...Instead of removing the lock from _write_reg_8() > >> > it inserts a bunch of code. Anyway, it seems that w_rite_reg_8() is used > >> > in multiple places, so removing that lock doesn't appear to be an > >> > option. > >> > > >> > See below... > >> > > >> > alisons > >> > > >> >> > >> >> Signed-off-by: Gargi Sharma <gs051095@gmail.com> > >> >> --- > >> >> drivers/staging/iio/meter/ade7754.c | 13 +++++++++++-- > >> >> 1 file changed, 11 insertions(+), 2 deletions(-) > >> >> > >> >> diff --git a/drivers/staging/iio/meter/ade7754.c b/drivers/staging/iio/meter/ade7754.c > >> >> index 024463a..eb03469 100644 > >> >> --- a/drivers/staging/iio/meter/ade7754.c > >> >> +++ b/drivers/staging/iio/meter/ade7754.c > >> >> @@ -29,6 +29,15 @@ static int ade7754_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val) > >> >> struct iio_dev *indio_dev = dev_to_iio_dev(dev); > >> >> struct ade7754_state *st = iio_priv(indio_dev); > >> >> > >> >> + if (reg_address == ADE7754_WAVMODE) { > >> >> + st->tx[0] = ADE7754_WRITE_REG(reg_address); > >> >> + st->tx[1] = val; > >> >> + > >> >> + ret = spi_write(st->us, st->tx, 2); > >> >> + > >> >> + return ret; > >> >> + } > >> >> + > >> > What's this? > >> > >> When the function ade_spi_write_reg_8() is called inside > >> ade7754_write_frequency(), we are writing to this( ADE7754_WAVMODE) > >> register. When writing to this register we don't need to hold the > >> buf_lock since ade7754_write_frequency() already takes care of that. > > > > Oh! I see it now. You created a special 'no lock needed' case > > inside of --write_reg_8 for writing frequency. That works, > > but it's...ummm...sneaky ;) Let's see if there's another way. > > > > Look back at Lars suggestion on a similar patch. Maybe that > > will apply here. > > http://marc.info/?l=linux-kernel&m=148940648615743&w=2 > > > > I did look at the patch you suggested for inspiration :) What I could > not understand was the part where Lars wrote about "doing a > read-modify-write cycle in a protected section." I can write a > separate function for --write_reg_8 that does not take the lock, but > do not know how to do a "read-modify-write cycle in a protected > section" :( > > Gargi Hi Gargi, The mlock wasn't really protecting the read followed by write. You'll introduce a new func that does that. It'll use the existing transaction lock so that an spi_write can't sneak in between your spi_read and write. This is going to be the same change in all the meter drivers. 3 are exactly the same, a 4th is very close. alisons > > alisons > > > > > >> > >> > > >> >> mutex_lock(&st->buf_lock); > >> >> st->tx[0] = ADE7754_WRITE_REG(reg_address); > >> >> st->tx[1] = val; > >> >> @@ -430,7 +439,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, > >> >> if (!val) > >> >> return -EINVAL; > >> >> > >> >> - mutex_lock(&indio_dev->mlock); > >> >> + mutex_lock(&st->buf_lock); > >> >> > >> >> t = 26000 / val; > >> >> if (t > 0) > >> >> @@ -451,7 +460,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, > >> >> ret = ade7754_spi_write_reg_8(dev, ADE7754_WAVMODE, reg); > >> >> > >> >> out: > >> >> - mutex_unlock(&indio_dev->mlock); > >> >> + mutex_unlock(&st->buf_lock); > >> >> > >> >> return ret ? ret : len; > >> >> } > >> > >> The buf_lock inside ade7754_write_frequency() takes into account that > >> when using the function ade7754_spi_write_reg_8, lock is already held > >> and locking is no longer required inside the ade7754_spi_write_reg_8() > >> function. > >> > >> Let me know if this sounds okay, I can perhaps edit the commit log to > >> make this clearer. > >> > >> Thanks, > >> Gargi > >> > >> >> -- > >> >> 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@googlegroups.com. > >> >> To post to this group, send email to outreachy-kernel@googlegroups.com. > >> >> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1489995561-6988-1-git-send-email-gs051095%40gmail.com. > >> >> For more options, visit https://groups.google.com/d/optout. > >> > > >> > -- > >> > 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@googlegroups.com. > >> > To post to this group, send email to outreachy-kernel@googlegroups.com. > >> > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/20170321172438.GC2793%40d830.WORKGROUP. > >> > For more options, visit https://groups.google.com/d/optout. > > > > -- > > 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@googlegroups.com. > > To post to this group, send email to outreachy-kernel@googlegroups.com. > > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/20170321181207.GA10699%40d830.WORKGROUP. > > For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code 2017-03-20 7:39 [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code Gargi Sharma 2017-03-21 17:24 ` [Outreachy kernel] " Alison Schofield @ 2017-03-21 19:45 ` Jonathan Cameron 2017-03-21 19:52 ` Gargi Sharma 1 sibling, 1 reply; 10+ messages in thread From: Jonathan Cameron @ 2017-03-21 19:45 UTC (permalink / raw) To: Gargi Sharma, outreachy-kernel Cc: linux-iio, lars, Michael.Hennerich, knaack.h, pmeerw, gregkh On 20/03/17 07:39, Gargi Sharma 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 buf_lock in the devices global data. > > As buf_lock already protects operations in ade7754_write_frequency, > there isn't a need to acquire the lock inside ade7754_spi_write_reg_8 > when writing to the register. > > Signed-off-by: Gargi Sharma <gs051095@gmail.com> Question inline. > --- > drivers/staging/iio/meter/ade7754.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/iio/meter/ade7754.c b/drivers/staging/iio/meter/ade7754.c > index 024463a..eb03469 100644 > --- a/drivers/staging/iio/meter/ade7754.c > +++ b/drivers/staging/iio/meter/ade7754.c > @@ -29,6 +29,15 @@ static int ade7754_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val) > struct iio_dev *indio_dev = dev_to_iio_dev(dev); > struct ade7754_state *st = iio_priv(indio_dev); > > + if (reg_address == ADE7754_WAVMODE) { > + st->tx[0] = ADE7754_WRITE_REG(reg_address); > + st->tx[1] = val; > + > + ret = spi_write(st->us, st->tx, 2); > + > + return ret; > + } This block doesn't fit with the description. What's going on here? > + > mutex_lock(&st->buf_lock); > st->tx[0] = ADE7754_WRITE_REG(reg_address); > st->tx[1] = val; > @@ -430,7 +439,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, > if (!val) > return -EINVAL; > > - mutex_lock(&indio_dev->mlock); > + mutex_lock(&st->buf_lock); > > t = 26000 / val; > if (t > 0) > @@ -451,7 +460,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, > ret = ade7754_spi_write_reg_8(dev, ADE7754_WAVMODE, reg); > > out: > - mutex_unlock(&indio_dev->mlock); > + mutex_unlock(&st->buf_lock); > > return ret ? ret : len; > } > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code 2017-03-21 19:45 ` Jonathan Cameron @ 2017-03-21 19:52 ` Gargi Sharma 2017-03-22 20:19 ` Jonathan Cameron 0 siblings, 1 reply; 10+ messages in thread From: Gargi Sharma @ 2017-03-21 19:52 UTC (permalink / raw) To: Jonathan Cameron Cc: outreachy-kernel, linux-iio, Lars-Peter Clausen, Michael Hennerich, Hartmut Knaack, Peter Meerwald-Stadler, Greg KH On Wed, Mar 22, 2017 at 1:15 AM, Jonathan Cameron <jic23@kernel.org> wrote: > On 20/03/17 07:39, Gargi Sharma 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 buf_lock in the devices global data. >> >> As buf_lock already protects operations in ade7754_write_frequency, >> there isn't a need to acquire the lock inside ade7754_spi_write_reg_8 >> when writing to the register. >> >> Signed-off-by: Gargi Sharma <gs051095@gmail.com> > Question inline. >> --- >> drivers/staging/iio/meter/ade7754.c | 13 +++++++++++-- >> 1 file changed, 11 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/staging/iio/meter/ade7754.c b/drivers/staging/iio/m= eter/ade7754.c >> index 024463a..eb03469 100644 >> --- a/drivers/staging/iio/meter/ade7754.c >> +++ b/drivers/staging/iio/meter/ade7754.c >> @@ -29,6 +29,15 @@ static int ade7754_spi_write_reg_8(struct device *dev= , u8 reg_address, u8 val) >> struct iio_dev *indio_dev =3D dev_to_iio_dev(dev); >> struct ade7754_state *st =3D iio_priv(indio_dev); >> >> + if (reg_address =3D=3D ADE7754_WAVMODE) { >> + st->tx[0] =3D ADE7754_WRITE_REG(reg_address); >> + st->tx[1] =3D val; >> + >> + ret =3D spi_write(st->us, st->tx, 2); >> + >> + return ret; >> + } > This block doesn't fit with the description. What's going on here? When the function ade_spi_write_reg_8() is called inside ade7754_write_frequency(), we are writing to this( ADE7754_WAVMODE) register. When writing to this register we don=E2=80=99t need to hold the buf_lock since ade7754_write_frequency() already takes care of that. This block of code does not use the buf_lock since that is taken care of by ade7754_write_frequency(). Gargi >> + >> mutex_lock(&st->buf_lock); >> st->tx[0] =3D ADE7754_WRITE_REG(reg_address); >> st->tx[1] =3D val; >> @@ -430,7 +439,7 @@ static ssize_t ade7754_write_frequency(struct device= *dev, >> if (!val) >> return -EINVAL; >> >> - mutex_lock(&indio_dev->mlock); >> + mutex_lock(&st->buf_lock); >> >> t =3D 26000 / val; >> if (t > 0) >> @@ -451,7 +460,7 @@ static ssize_t ade7754_write_frequency(struct device= *dev, >> ret =3D ade7754_spi_write_reg_8(dev, ADE7754_WAVMODE, reg); >> >> out: >> - mutex_unlock(&indio_dev->mlock); >> + mutex_unlock(&st->buf_lock); >> >> return ret ? ret : len; >> } >> > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code 2017-03-21 19:52 ` Gargi Sharma @ 2017-03-22 20:19 ` Jonathan Cameron 0 siblings, 0 replies; 10+ messages in thread From: Jonathan Cameron @ 2017-03-22 20:19 UTC (permalink / raw) To: Gargi Sharma Cc: outreachy-kernel, linux-iio, Lars-Peter Clausen, Michael Hennerich, Hartmut Knaack, Peter Meerwald-Stadler, Greg KH On 21/03/17 19:52, Gargi Sharma wrote: > On Wed, Mar 22, 2017 at 1:15 AM, Jonathan Cameron <jic23@kernel.org> wrote: >> On 20/03/17 07:39, Gargi Sharma 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 buf_lock in the devices global data. >>> >>> As buf_lock already protects operations in ade7754_write_frequency, >>> there isn't a need to acquire the lock inside ade7754_spi_write_reg_8 >>> when writing to the register. >>> >>> Signed-off-by: Gargi Sharma <gs051095@gmail.com> >> Question inline. >>> --- >>> drivers/staging/iio/meter/ade7754.c | 13 +++++++++++-- >>> 1 file changed, 11 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/staging/iio/meter/ade7754.c b/drivers/staging/iio/meter/ade7754.c >>> index 024463a..eb03469 100644 >>> --- a/drivers/staging/iio/meter/ade7754.c >>> +++ b/drivers/staging/iio/meter/ade7754.c >>> @@ -29,6 +29,15 @@ static int ade7754_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val) >>> struct iio_dev *indio_dev = dev_to_iio_dev(dev); >>> struct ade7754_state *st = iio_priv(indio_dev); >>> >>> + if (reg_address == ADE7754_WAVMODE) { >>> + st->tx[0] = ADE7754_WRITE_REG(reg_address); >>> + st->tx[1] = val; >>> + >>> + ret = spi_write(st->us, st->tx, 2); >>> + >>> + return ret; >>> + } > >> This block doesn't fit with the description. What's going on here? > > When the function ade_spi_write_reg_8() is called inside > ade7754_write_frequency(), we are writing to this( ADE7754_WAVMODE) > register. When writing to this register we don’t need to hold the > buf_lock since ade7754_write_frequency() already takes care of that. > This block of code does not use the buf_lock since that is taken care > of by ade7754_write_frequency(). This strikes me as a very fragile way of coding this. Also, unless I'm missing something, the lock taken there is still mlock... > > Gargi >>> + >>> mutex_lock(&st->buf_lock); >>> st->tx[0] = ADE7754_WRITE_REG(reg_address); >>> st->tx[1] = val; >>> @@ -430,7 +439,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, >>> if (!val) >>> return -EINVAL; >>> >>> - mutex_lock(&indio_dev->mlock); >>> + mutex_lock(&st->buf_lock); >>> >>> t = 26000 / val; >>> if (t > 0) >>> @@ -451,7 +460,7 @@ static ssize_t ade7754_write_frequency(struct device *dev, >>> ret = ade7754_spi_write_reg_8(dev, ADE7754_WAVMODE, reg); >>> >>> out: >>> - mutex_unlock(&indio_dev->mlock); >>> + mutex_unlock(&st->buf_lock); >>> >>> return ret ? ret : len; >>> } >>> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-03-22 20:19 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-03-20 7:39 [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code Gargi Sharma 2017-03-21 17:24 ` [Outreachy kernel] " Alison Schofield 2017-03-21 17:48 ` Gargi Sharma 2017-03-21 18:12 ` Alison Schofield 2017-03-21 18:18 ` Gargi Sharma 2017-03-21 18:54 ` Alison Schofield 2017-03-21 20:12 ` Alison Schofield 2017-03-21 19:45 ` Jonathan Cameron 2017-03-21 19:52 ` Gargi Sharma 2017-03-22 20:19 ` Jonathan Cameron
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).