Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

On 11/12/2016 03:24 PM, Jonathan Cameron wrote: > On 11/11/16 14:18, Lars-Peter Clausen wrote: >> On 11/11/2016 07:34 AM, Eva Rachel Retuya wrote: >>> Eliminate the non-standard attribute in_voltage_range and move its >>> functionality under the scale attribute. rea

Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

On 11/12/2016 03:22 PM, Eva Rachel Retuya wrote: > Hello, > > Thanks for explaining it. Now I understand better why read_raw is > formatted in that manner. I have some questions in-line: > > On Fri, Nov 11, 2016 at 03:18:37PM +0100, Lars-Peter Clausen wrote: >> On

Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

On 11/12/2016 03:22 PM, Eva Rachel Retuya wrote: > Hello, > > Thanks for explaining it. Now I understand better why read_raw is > formatted in that manner. I have some questions in-line: > > On Fri, Nov 11, 2016 at 03:18:37PM +0100, Lars-Peter Clausen wrote: >> On

Re: [PATCH 2/2] staging: iio: ad7606: move out of staging

On 11/11/2016 07:34 AM, Eva Rachel Retuya wrote: > Move the ad7606 driver from staging/iio/adc to iio/adc. Also, update the > corresponding Makefile and Kconfig associated with the change. This is obviously OK, but when you generate a patch that moves files use `git format-patch -M ...`. This

Re: [PATCH 2/2] staging: iio: ad7606: move out of staging

On 11/11/2016 07:34 AM, Eva Rachel Retuya wrote: > Move the ad7606 driver from staging/iio/adc to iio/adc. Also, update the > corresponding Makefile and Kconfig associated with the change. This is obviously OK, but when you generate a patch that moves files use `git format-patch -M ...`. This

Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

e the attribute in_voltage_range_available into > in_voltage_scale_available. > > Suggested-by: Lars-Peter Clausen <l...@metafoo.de> > Signed-off-by: Eva Rachel Retuya <eraret...@gmail.com> Hi, Thanks for the patch. Unfortunately this is not quite this straight forward. The scale i

Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale

e the attribute in_voltage_range_available into > in_voltage_scale_available. > > Suggested-by: Lars-Peter Clausen > Signed-off-by: Eva Rachel Retuya Hi, Thanks for the patch. Unfortunately this is not quite this straight forward. The scale is what you multiply the raw with to get the value in t

Re: [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus

On 11/09/2016 10:27 PM, Robert Jarzmik wrote: [...] > +int snd_ac97_codec_driver_register(struct ac97_codec_driver *drv) > +{ > + int ret; > + > + drv->driver.bus = _bus_type; > + > + ret = driver_register(>driver); > + if (!ret) > +

Re: [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus

On 11/09/2016 10:27 PM, Robert Jarzmik wrote: [...] > +int snd_ac97_codec_driver_register(struct ac97_codec_driver *drv) > +{ > + int ret; > + > + drv->driver.bus = _bus_type; > + > + ret = driver_register(>driver); > + if (!ret) > +

Re: [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus

On 11/08/2016 10:18 PM, Robert Jarzmik wrote: [...] >>> +/** >>> + * struct ac97_controller - The AC97 controller of the AC-Link >>> + * @ops: the AC97 operations. >>> + * @controllers: linked list of all existing controllers. >>> + * @dev: the device providing the AC97

Re: [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus

On 11/08/2016 10:18 PM, Robert Jarzmik wrote: [...] >>> +/** >>> + * struct ac97_controller - The AC97 controller of the AC-Link >>> + * @ops: the AC97 operations. >>> + * @controllers: linked list of all existing controllers. >>> + * @dev: the device providing the AC97

Re: [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus

On 10/26/2016 09:41 PM, Robert Jarzmik wrote: > AC97 is a bus for sound usage. It enables for a AC97 AC-Link to link one > controller to 0 to 4 AC97 codecs. > > The goal of this new implementation is to implement a device/driver > model for AC97, with an automatic scan of the bus and automatic >

Re: [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus

On 10/26/2016 09:41 PM, Robert Jarzmik wrote: > AC97 is a bus for sound usage. It enables for a AC97 AC-Link to link one > controller to 0 to 4 AC97 codecs. > > The goal of this new implementation is to implement a device/driver > model for AC97, with an automatic scan of the bus and automatic >

Re: [PATCH 1/6] staging: iio: set proper supply name to devm_regulator_get()

On 11/01/2016 05:03 AM, Matt Ranostay wrote: > On Mon, Oct 31, 2016 at 10:04 AM, Eva Rachel Retuya > wrote: >> The name passed to devm_regulator_get() should match the name of the >> supply as specified in the device datasheet. This makes it clear what >> power supply is

Re: [PATCH 1/6] staging: iio: set proper supply name to devm_regulator_get()

On 11/01/2016 05:03 AM, Matt Ranostay wrote: > On Mon, Oct 31, 2016 at 10:04 AM, Eva Rachel Retuya > wrote: >> The name passed to devm_regulator_get() should match the name of the >> supply as specified in the device datasheet. This makes it clear what >> power supply is being referred to in

Re: [PATCH v3] staging: iio: cdc: ad7746: add additional config defines

off-by: Eva Rachel Retuya <eraret...@gmail.com> > Looks good to me. > > Lars could you sanity check this one as well? Acked-by: Lars-Peter Clausen <l...@metafoo.de>

Re: [PATCH v3] staging: iio: cdc: ad7746: add additional config defines

ff-by: Eva Rachel Retuya > Looks good to me. > > Lars could you sanity check this one as well? Acked-by: Lars-Peter Clausen

Re: [PATCH] iio: maxim_thermocouple: return -EINVAL on invalid read size

On 10/25/2016 09:04 PM, Colin King wrote: > From: Colin Ian King > > In the case that the read size is not 2 or 4 bytes > then maxim_thermocouple_read is not initializing ret and > hence may return early with a bogus error return or > just through to return with a bogos

Re: [PATCH] iio: maxim_thermocouple: return -EINVAL on invalid read size

On 10/25/2016 09:04 PM, Colin King wrote: > From: Colin Ian King > > In the case that the read size is not 2 or 4 bytes > then maxim_thermocouple_read is not initializing ret and > hence may return early with a bogus error return or > just through to return with a bogos unread value in *val. >

Re: [PATCH] staging: iio: cdc: ad7746: set ret on IIO_VOLTAGE case

On 10/25/2016 08:44 PM, Colin King wrote: > From: Colin Ian King > > For a IIO_VOLTAGE case, ret is not being set causing an > uninitialized value being returned by ad7746_read_raw. Fix > this by setting ret to IIO_VAL_INT for this specific case. > > Signed-off-by:

Re: [PATCH] staging: iio: cdc: ad7746: set ret on IIO_VOLTAGE case

On 10/25/2016 08:44 PM, Colin King wrote: > From: Colin Ian King > > For a IIO_VOLTAGE case, ret is not being set causing an > uninitialized value being returned by ad7746_read_raw. Fix > this by setting ret to IIO_VAL_INT for this specific case. > > Signed-off-by: Colin Ian King Arnd did

Re: [PATCH] [v2] staging: iio: ad5933: avoid uninitialized variable in error case

Wmaybe-uninitialized] >> >> This adds minimal error handling so we only evaluate the >> data if it was correctly read. >> >> Link: https://patchwork.kernel.org/patch/8110281/ >> Signed-off-by: Arnd Bergmann <a...@arndb.de> > Looks good to me. > > Lars? > Looks good, thanks. Acked-by: Lars-Peter Clausen <l...@metafoo.de>

Re: [PATCH] [v2] staging: iio: ad5933: avoid uninitialized variable in error case

Wmaybe-uninitialized] >> >> This adds minimal error handling so we only evaluate the >> data if it was correctly read. >> >> Link: https://patchwork.kernel.org/patch/8110281/ >> Signed-off-by: Arnd Bergmann > Looks good to me. > > Lars? > Looks good, thanks. Acked-by: Lars-Peter Clausen

Re: [PATCH] clk: keystone: Fix an error checking

On 10/24/2016 12:36 PM, Dan Carpenter wrote: > On Sun, Oct 23, 2016 at 10:12:49AM +0200, Christophe JAILLET wrote: >> clk_register_pll() can return ERR_PTR(-ENOMEM) so here the check against >> NULL only is not correct. >> > > Change the ERR_PTR(-ENOMEM) to a NULL instead. In this particular

Re: [PATCH] clk: keystone: Fix an error checking

On 10/24/2016 12:36 PM, Dan Carpenter wrote: > On Sun, Oct 23, 2016 at 10:12:49AM +0200, Christophe JAILLET wrote: >> clk_register_pll() can return ERR_PTR(-ENOMEM) so here the check against >> NULL only is not correct. >> > > Change the ERR_PTR(-ENOMEM) to a NULL instead. In this particular

Re: [PATCH 0/4] IIO wrapper drivers, dpot-dac and envelope-detector

On 10/20/2016 04:53 PM, Peter Rosin wrote: [...] > Good idea! Then the "envelope-detector,inverted" bool can go, and be > implied by the compatible string. If some way to rebind the irq trigger > is later discovered that can be added as a channel attr without > deprecating any dt bindings stuff.

Re: [PATCH 0/4] IIO wrapper drivers, dpot-dac and envelope-detector

On 10/20/2016 04:53 PM, Peter Rosin wrote: [...] > Good idea! Then the "envelope-detector,inverted" bool can go, and be > implied by the compatible string. If some way to rebind the irq trigger > is later discovered that can be added as a channel attr without > deprecating any dt bindings stuff.

Re: [PATCH 0/4] IIO wrapper drivers, dpot-dac and envelope-detector

On 10/20/2016 11:25 AM, Peter Rosin wrote: > Hi! > > These two drivers share the fact that they wrap another iio channel, > and I use the first in combination with the second, which is why I'm > submitting them as a pair. > > The first driver is a simple wrapper converting an iio dpot into an >

Re: [PATCH 0/4] IIO wrapper drivers, dpot-dac and envelope-detector

On 10/20/2016 11:25 AM, Peter Rosin wrote: > Hi! > > These two drivers share the fact that they wrap another iio channel, > and I use the first in combination with the second, which is why I'm > submitting them as a pair. > > The first driver is a simple wrapper converting an iio dpot into an >

Re: [PATCH] rtc: cmos: remove all __exit_p annotations

> -static void __exit cmos_exit(void) > +static void cmos_exit(void) This annotation is correct and should stay. > { > #ifdef CONFIG_PNP > if (pnp_driver_registered) >

Re: [PATCH] rtc: cmos: remove all __exit_p annotations

> -static void __exit cmos_exit(void) > +static void cmos_exit(void) This annotation is correct and should stay. > { > #ifdef CONFIG_PNP > if (pnp_driver_registered) >

Re: [PATCH] Coccinelle: misc: Improve the script for more accurate results

On 10/13/2016 07:01 PM, Vaishali Thakkar wrote: > > > On Thursday 13 October 2016 09:45 PM, Julia Lawall wrote: >> >> >> On Thu, 13 Oct 2016, Vaishali Thakkar wrote: >> >>> Currently because of the left associativity of the operators, >>> pattern IRQF_ONESHOT | flags does not match with the

Re: [PATCH] Coccinelle: misc: Improve the script for more accurate results

On 10/13/2016 07:01 PM, Vaishali Thakkar wrote: > > > On Thursday 13 October 2016 09:45 PM, Julia Lawall wrote: >> >> >> On Thu, 13 Oct 2016, Vaishali Thakkar wrote: >> >>> Currently because of the left associativity of the operators, >>> pattern IRQF_ONESHOT | flags does not match with the

Re: [PATCH 1/2 v3] drm/bridge: adv7511: Add Audio support.

On 09/07/2016 01:22 AM, John Stultz wrote: > This patch adds support to Audio for both adv7511 and adv7533 > bridge chips. > > This patch was originally from [1] by Lars-Peter Clausen <l...@metafoo.de> > and was adapted by Archit Taneja <arch...@codeaurora.org>

Re: [PATCH 1/2 v3] drm/bridge: adv7511: Add Audio support.

On 09/07/2016 01:22 AM, John Stultz wrote: > This patch adds support to Audio for both adv7511 and adv7533 > bridge chips. > > This patch was originally from [1] by Lars-Peter Clausen > and was adapted by Archit Taneja and > Srinivas Kandagatla . > > Then I heavily rew

Re: [PATCH] iio: light: acpi-als: Add a tuning parameter interface.

On 09/06/2016 12:25 PM, Enric Balletbo i Serra wrote: > From: Bryan Freed > > Add IIO_CHAN_INFO_CALIBSCALE to the channel to scale up or down > the raw measurements through the IIO framework. > > Add IIO_CHAN_INFO_PROCESSED to provide the interface to read the > scaled

Re: [PATCH] iio: light: acpi-als: Add a tuning parameter interface.

On 09/06/2016 12:25 PM, Enric Balletbo i Serra wrote: > From: Bryan Freed > > Add IIO_CHAN_INFO_CALIBSCALE to the channel to scale up or down > the raw measurements through the IIO framework. > > Add IIO_CHAN_INFO_PROCESSED to provide the interface to read the > scaled measurements through the

Re: [Patch v3 07/11] MIPS: Xilfpga: Add DT node for AXI I2C

On 08/31/2016 06:35 PM, Zubair Lutfullah Kakakhel wrote: [..] > + ad7420@4B { > + compatible = "adt7420"; "adi,adt7420" > + reg = <0x4B>; > + }; > + } ; > };

Re: [Patch v3 07/11] MIPS: Xilfpga: Add DT node for AXI I2C

On 08/31/2016 06:35 PM, Zubair Lutfullah Kakakhel wrote: [..] > + ad7420@4B { > + compatible = "adt7420"; "adi,adt7420" > + reg = <0x4B>; > + }; > + } ; > };

Re: [PATCH 1/2] sdhci-of-arasan: Add quirk and device tree parameter to fake CD bit

On 08/25/2016 05:10 PM, Sören Brinkmann wrote: > On Wed, 2016-08-24 at 18:23:03 -0500, Zach Brown wrote: >> The sdhci controller on xilinx zynq devices will not function unless >> the cd bit is provided. http://www.xilinx.com/support/answers/61064.html >> In cases where it is impossible to provide

Re: [PATCH 1/2] sdhci-of-arasan: Add quirk and device tree parameter to fake CD bit

On 08/25/2016 05:29 PM, Sören Brinkmann wrote: > On Thu, 2016-08-25 at 17:23:47 +0200, Lars-Peter Clausen wrote: >> On 08/25/2016 05:10 PM, Sören Brinkmann wrote: >>> On Wed, 2016-08-24 at 18:23:03 -0500, Zach Brown wrote: >>>> The sdhci controller on xilinx zynq de

Re: [PATCH 1/2] sdhci-of-arasan: Add quirk and device tree parameter to fake CD bit

On 08/25/2016 05:10 PM, Sören Brinkmann wrote: > On Wed, 2016-08-24 at 18:23:03 -0500, Zach Brown wrote: >> The sdhci controller on xilinx zynq devices will not function unless >> the cd bit is provided. http://www.xilinx.com/support/answers/61064.html >> In cases where it is impossible to provide

Re: [PATCH 1/2] sdhci-of-arasan: Add quirk and device tree parameter to fake CD bit

On 08/25/2016 05:29 PM, Sören Brinkmann wrote: > On Thu, 2016-08-25 at 17:23:47 +0200, Lars-Peter Clausen wrote: >> On 08/25/2016 05:10 PM, Sören Brinkmann wrote: >>> On Wed, 2016-08-24 at 18:23:03 -0500, Zach Brown wrote: >>>> The sdhci controller on xilinx zynq de

Re: [PATCH 2/2] sdhci-of-arasan: Add quirk and device tree parameter to fake CD bit

On 08/25/2016 01:23 AM, Zach Brown wrote: > The sdhci controller on xilinx zynq devices will not function unless > the cd bit is provided. http://www.xilinx.com/support/answers/61064.html > In cases where it is impossible to provide the cd bit in hardware, > setting the controller to test mode and

Re: [PATCH 2/2] sdhci-of-arasan: Add quirk and device tree parameter to fake CD bit

On 08/25/2016 01:23 AM, Zach Brown wrote: > The sdhci controller on xilinx zynq devices will not function unless > the cd bit is provided. http://www.xilinx.com/support/answers/61064.html > In cases where it is impossible to provide the cd bit in hardware, > setting the controller to test mode and

Re: [PATCH] iio: ad5755: fix off-by-one on devnr limit check

On 08/21/2016 09:30 PM, Jonathan Cameron wrote: > On 25/07/16 23:40, Colin King wrote: >> From: Colin Ian King >> >> The comparison for devnr limits is off-by-one, the current check >> allows 0 to AD5755_NUM_CHANNELS and the limit should be in fact >> 0 to

Re: [PATCH] iio: ad5755: fix off-by-one on devnr limit check

On 08/21/2016 09:30 PM, Jonathan Cameron wrote: > On 25/07/16 23:40, Colin King wrote: >> From: Colin Ian King >> >> The comparison for devnr limits is off-by-one, the current check >> allows 0 to AD5755_NUM_CHANNELS and the limit should be in fact >> 0 to AD5755_NUM_CHANNELS - 1. This can lead

Re: [PATCH v2] iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING"

On 08/21/2016 01:21 PM, Jonathan Cameron wrote: [...] > I've applied to this to the fixes-togreg branch of iio.git > > For now I haven't marked it for stable, purely because I'm not sure > when the first 'problem' usage was introduced. I'm happy to explicitly > send a request for stable

Re: [PATCH v2] iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING"

On 08/21/2016 01:21 PM, Jonathan Cameron wrote: [...] > I've applied to this to the fixes-togreg branch of iio.git > > For now I haven't marked it for stable, purely because I'm not sure > when the first 'problem' usage was introduced. I'm happy to explicitly > send a request for stable

Re: [PATCH v4 1/8] media: adv7180: fix field type

or explicitly setting the field > mode via I2P, set the field mode to V4L2_FIELD_ALTERNATE. > > Signed-off-by: Steve Longerbeam <steve_longerb...@mentor.com> > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> Acked-by: Lars-Peter Clausen <l...@metafoo.de> Thanks.

Re: [PATCH v4 1/8] media: adv7180: fix field type

ield > mode via I2P, set the field mode to V4L2_FIELD_ALTERNATE. > > Signed-off-by: Steve Longerbeam > Signed-off-by: Niklas Söderlund Acked-by: Lars-Peter Clausen Thanks.

Re: [PATCH v2] iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING"

ticles/628628/) use the >> wait_woken() function, which avoids the nested sleeping while still >> handling races between waiting / wake-events. >> >> Signed-off-by: Brian Norris <briannor...@chromium.org> > Looks good to me, but given Lars' involvement in the discussion I'd > like his review before applying this. Looks good. Thanks Brian for fixing this. Reviewed-by: Lars-Peter Clausen <l...@metafoo.de>

Re: [PATCH v2] iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING"

ticles/628628/) use the >> wait_woken() function, which avoids the nested sleeping while still >> handling races between waiting / wake-events. >> >> Signed-off-by: Brian Norris > Looks good to me, but given Lars' involvement in the discussion I'd > like his review before applying this. Looks good. Thanks Brian for fixing this. Reviewed-by: Lars-Peter Clausen

Re: [PATCH 1/3] dt/bindings: arm-pl330: add description of arm,pl330-periph-burst

On 08/05/2016 09:25 AM, Shawn Lin wrote: > Hi Vinod, > > 在 2016/8/5 11:34, Vinod Koul 写道: >> On Fri, Aug 05, 2016 at 10:53:20AM +0800, Shawn Lin wrote: >>> This patch adds the "arm,pl330-periph-burst" for arm-pl330 to >>> support busrt mode. >> >> why should this be DT property. Only reason I can

Re: [PATCH 1/3] dt/bindings: arm-pl330: add description of arm,pl330-periph-burst

On 08/05/2016 09:25 AM, Shawn Lin wrote: > Hi Vinod, > > 在 2016/8/5 11:34, Vinod Koul 写道: >> On Fri, Aug 05, 2016 at 10:53:20AM +0800, Shawn Lin wrote: >>> This patch adds the "arm,pl330-periph-burst" for arm-pl330 to >>> support busrt mode. >> >> why should this be DT property. Only reason I can

Re: [PATCH] iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING"

On 08/09/2016 12:23 AM, Brian Norris wrote: > Hi Lars, > > On Thu, Aug 04, 2016 at 12:21:08PM +0200, Lars-Peter Clausen wrote: >> And then also drop the if (!indio_dev->info) at the beginning of the >> function. > > I was poking through the usage of this ->inf

Re: [PATCH] iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING"

On 08/09/2016 12:23 AM, Brian Norris wrote: > Hi Lars, > > On Thu, Aug 04, 2016 at 12:21:08PM +0200, Lars-Peter Clausen wrote: >> And then also drop the if (!indio_dev->info) at the beginning of the >> function. > > I was poking through the usage of this ->inf

Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback

On 08/08/2016 11:08 AM, Vinod Koul wrote: > On Thu, Aug 04, 2016 at 05:59:30PM +0200, Lars-Peter Clausen wrote: >> On 08/04/2016 05:38 PM, Russell King - ARM Linux wrote: >> [...] >>> What you instead need to do is to find some way to record in your >>> driver th

Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback

On 08/08/2016 11:08 AM, Vinod Koul wrote: > On Thu, Aug 04, 2016 at 05:59:30PM +0200, Lars-Peter Clausen wrote: >> On 08/04/2016 05:38 PM, Russell King - ARM Linux wrote: >> [...] >>> What you instead need to do is to find some way to record in your >>> driver th

Re: [PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

On 08/05/2016 01:37 AM, Alison Schofield wrote: [...] > > No, that's not what this bug & patch is about. > > This patch is about the fact that we are reading the temp & > humid data registers incorrectly in the current driver and > we are exposing incorrect numbers via sysfs raw reads. > > I

Re: [PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

On 08/05/2016 01:37 AM, Alison Schofield wrote: [...] > > No, that's not what this bug & patch is about. > > This patch is about the fact that we are reading the temp & > humid data registers incorrectly in the current driver and > we are exposing incorrect numbers via sysfs raw reads. > > I

Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback

On 08/05/2016 08:32 AM, Robert Jarzmik wrote: > Lars-Peter Clausen <l...@metafoo.de> writes: > >> On 08/04/2016 06:08 PM, Sinan Kaya wrote: >> [...] >>> The other way is I can feed this information to what Dave just introduced >>> as part of the callba

Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback

On 08/05/2016 08:32 AM, Robert Jarzmik wrote: > Lars-Peter Clausen writes: > >> On 08/04/2016 06:08 PM, Sinan Kaya wrote: >> [...] >>> The other way is I can feed this information to what Dave just introduced >>> as part of the callback mechanism and no

Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback

On 08/04/2016 06:08 PM, Sinan Kaya wrote: [...] > The other way is I can feed this information to what Dave just introduced > as part of the callback mechanism and not touch this. Use the callback mechanism. It is a lot easier to implement correctly than the tx_status() mechanism. > The main

Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback

On 08/04/2016 06:08 PM, Sinan Kaya wrote: [...] > The other way is I can feed this information to what Dave just introduced > as part of the callback mechanism and not touch this. Use the callback mechanism. It is a lot easier to implement correctly than the tx_status() mechanism. > The main

Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback

On 08/04/2016 05:38 PM, Russell King - ARM Linux wrote: [...] > What you instead need to do is to find some way to record in your > driver that transaction 2 failed, and when dma_cookie_status() says > that a transaction has DMA_COMPLETE status, you need to look up to > see whether it failed. In

Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback

On 08/04/2016 05:38 PM, Russell King - ARM Linux wrote: [...] > What you instead need to do is to find some way to record in your > driver that transaction 2 failed, and when dma_cookie_status() says > that a transaction has DMA_COMPLETE status, you need to look up to > see whether it failed. In

Re: [PATCH 1/2] regmap: Add a function to check if a regmap register is cached

On 08/04/2016 04:55 PM, Cristian Birsan wrote: > Add a function to check if a regmap register is cached. This will be used > in debugfs to dump the cached values of write only registers. > > Signed-off-by: Cristian Birsan > --- > drivers/base/regmap/internal.h |

Re: [PATCH 1/2] regmap: Add a function to check if a regmap register is cached

On 08/04/2016 04:55 PM, Cristian Birsan wrote: > Add a function to check if a regmap register is cached. This will be used > in debugfs to dump the cached values of write only registers. > > Signed-off-by: Cristian Birsan > --- > drivers/base/regmap/internal.h | 1 + >

[PATCH] regmap: rbtree: Avoid overlapping nodes

Fixes: 6399aea629b0 ("regmap: rbtree: When adding a reg do a bsearch for target node") Signed-off-by: Lars-Peter Clausen <l...@metafoo.de> --- drivers/base/regmap/regcache-rbtree.c | 38 ++- 1 file changed, 28 insertions(+), 10 deletions(-) diff

[PATCH] regmap: rbtree: Avoid overlapping nodes

Fixes: 6399aea629b0 ("regmap: rbtree: When adding a reg do a bsearch for target node") Signed-off-by: Lars-Peter Clausen --- drivers/base/regmap/regcache-rbtree.c | 38 ++- 1 file changed, 28 insertions(+), 10 deletions(-) diff --git a/drivers/base/regma

Re: [PATCH] iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING"

On 08/04/2016 11:41 AM, Brian Norris wrote: > On Thu, Aug 04, 2016 at 10:45:39AM +0200, Lars-Peter Clausen wrote: >>> @@ -132,10 +133,13 @@ ssize_t iio_buffer_read_first_n_outer(struct file >>> *filp, char __user *buf, >>> to_wait = min_t(size_t,

Re: [PATCH] iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING"

On 08/04/2016 11:41 AM, Brian Norris wrote: > On Thu, Aug 04, 2016 at 10:45:39AM +0200, Lars-Peter Clausen wrote: >>> @@ -132,10 +133,13 @@ ssize_t iio_buffer_read_first_n_outer(struct file >>> *filp, char __user *buf, >>> to_wait = min_t(size_t,

Re: [PATCH] iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING"

On 08/04/2016 10:26 AM, Brian Norris wrote: > When using CONFIG_DEBUG_ATOMIC_SLEEP, the scheduler nicely points out > that we're calling sleeping primitives within the wait_event loop, which > means we might clobber the task state: > > [ 10.831289] do not call blocking ops when !TASK_RUNNING;

Re: [PATCH] iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING"

On 08/04/2016 10:26 AM, Brian Norris wrote: > When using CONFIG_DEBUG_ATOMIC_SLEEP, the scheduler nicely points out > that we're calling sleeping primitives within the wait_event loop, which > means we might clobber the task state: > > [ 10.831289] do not call blocking ops when !TASK_RUNNING;

Re: [PATCH 1/1] Fix NULL pointer dereference in imx serial driver DMA callback

On 08/03/2016 12:59 PM, Fabien Lahoudere wrote: > From: Hannu Koivisto > > dma_rx_callback() may see NULL dma_chan_rx if DMA interrupt [1] occurs a > moment[2] before imx_uart_dma_exit() sets it to NULL. imx_uart_dma_exit() > calls dmaengine_terminate_all() and

Re: [PATCH 1/1] Fix NULL pointer dereference in imx serial driver DMA callback

On 08/03/2016 12:59 PM, Fabien Lahoudere wrote: > From: Hannu Koivisto > > dma_rx_callback() may see NULL dma_chan_rx if DMA interrupt [1] occurs a > moment[2] before imx_uart_dma_exit() sets it to NULL. imx_uart_dma_exit() > calls dmaengine_terminate_all() and dma_release_channel() but neither

Re: [PATCH 1/1] Fix NULL pointer dereference in imx serial driver DMA callback

On 08/03/2016 01:19 PM, Lars-Peter Clausen wrote: > On 08/03/2016 12:59 PM, Fabien Lahoudere wrote: >> From: Hannu Koivisto <hannu.koivi...@vincit.fi> >> >> dma_rx_callback() may see NULL dma_chan_rx if DMA interrupt [1] occurs a >> moment[2] before im

Re: [PATCH 1/1] Fix NULL pointer dereference in imx serial driver DMA callback

On 08/03/2016 01:19 PM, Lars-Peter Clausen wrote: > On 08/03/2016 12:59 PM, Fabien Lahoudere wrote: >> From: Hannu Koivisto >> >> dma_rx_callback() may see NULL dma_chan_rx if DMA interrupt [1] occurs a >> moment[2] before imx_uart_dma_exit() sets it to NULL. i

Re: iio: WARNING at kernel/sched/core.c:7630: do not call blocking ops when !TASK_RUNNING

On 08/02/2016 06:57 PM, Brian Norris wrote: > Hi Lars, > > On Tue, Aug 02, 2016 at 03:06:39PM +0200, Lars-Peter Clausen wrote: >> On 08/02/2016 03:12 AM, Brian Norris wrote: >>> I'm seeing the following warnings when I read from an IIO char device, >>> with

Re: iio: WARNING at kernel/sched/core.c:7630: do not call blocking ops when !TASK_RUNNING

On 08/02/2016 06:57 PM, Brian Norris wrote: > Hi Lars, > > On Tue, Aug 02, 2016 at 03:06:39PM +0200, Lars-Peter Clausen wrote: >> On 08/02/2016 03:12 AM, Brian Norris wrote: >>> I'm seeing the following warnings when I read from an IIO char device, >>> with

Re: iio: WARNING at kernel/sched/core.c:7630: do not call blocking ops when !TASK_RUNNING

On 08/02/2016 03:12 AM, Brian Norris wrote: > Hi all, > > I'm seeing the following warnings when I read from an IIO char device, > with CONFIG_DEBUG_ATOMIC_SLEEP=y. I'm testing a v4.4 kernel, but AFAICT, > nothing too relevant has changed between that and v4.7: [...] > Have any of you seen this

Re: iio: WARNING at kernel/sched/core.c:7630: do not call blocking ops when !TASK_RUNNING

On 08/02/2016 03:12 AM, Brian Norris wrote: > Hi all, > > I'm seeing the following warnings when I read from an IIO char device, > with CONFIG_DEBUG_ATOMIC_SLEEP=y. I'm testing a v4.4 kernel, but AFAICT, > nothing too relevant has changed between that and v4.7: [...] > Have any of you seen this

Re: [alsa-devel] [PATCH] ASoC: rt5659: Add mclk controls

> + /* Check if MCLK provided */ > + rt5659->mclk = devm_clk_get(>dev, "mclk"); > + if (IS_ERR(rt5659->mclk)) { > + if (PTR_ERR(rt5659->mclk) == -EPROBE_DEFER) > + return -EPROBE_DEFER; The correct thing to do here is to check if != -ENOENT and then

Re: [alsa-devel] [PATCH] ASoC: rt5659: Add mclk controls

> + /* Check if MCLK provided */ > + rt5659->mclk = devm_clk_get(>dev, "mclk"); > + if (IS_ERR(rt5659->mclk)) { > + if (PTR_ERR(rt5659->mclk) == -EPROBE_DEFER) > + return -EPROBE_DEFER; The correct thing to do here is to check if != -ENOENT and then

Re: [PATCH v2 03/10] media: adv7180: define more registers

On 07/20/2016 02:03 AM, Steve Longerbeam wrote: > Replace hard-coded addresses with new register macro defines. No > functional changes. > > Signed-off-by: Steve Longerbeam <steve_longerb...@mentor.com> Acked-by: Lars-Peter Clausen <l...@metafoo.de>

Re: [PATCH v2 03/10] media: adv7180: define more registers

On 07/20/2016 02:03 AM, Steve Longerbeam wrote: > Replace hard-coded addresses with new register macro defines. No > functional changes. > > Signed-off-by: Steve Longerbeam Acked-by: Lars-Peter Clausen

Re: [PATCH v2 05/10] media: adv7180: add power pin control

eworks.com> > Acked-by: Tim Harvey <thar...@gateworks.com> > Cc: Lars-Peter Clausen <l...@metafoo.de> Looks good, thanks. Acked-by: Lars-Peter Clausen <l...@metafoo.de>

Re: [PATCH v2 05/10] media: adv7180: add power pin control

On 07/20/2016 02:03 AM, Steve Longerbeam wrote: > Some targets control the ADV7180 power pin via a gpio, so add > optional support for "powerdown" pin control. > > Signed-off-by: Steve Longerbeam > Tested-by: Tim Harvey > Acked-by: Tim Harvey > Cc: Lars-Pet

Re: [PATCH] iio: ad5380: Fix probe failure when no external reference is supplied

gned-off-by: Paweł Grudziński <pgrudzin...@openmailbox.org> Looks good, thanks. But there is a way to improve on it even more, see comments inline. Up to you whether you want to do this or not. Either way. Acked-by: Lars-Peter Clausen <l...@metafoo.de> > --- > There are couple more

Re: [PATCH] iio: ad5380: Fix probe failure when no external reference is supplied

good, thanks. But there is a way to improve on it even more, see comments inline. Up to you whether you want to do this or not. Either way. Acked-by: Lars-Peter Clausen > --- > There are couple more places where I suspect similar issue with devices > having integrated reference, but I am s

Re: [PATCH 2/2] i2c-dev: Don't block the adapter from unregistering

On 07/06/2016 04:33 PM, Viresh Kumar wrote: > On 06-07-16, 10:22, Peter Rosin wrote: >> On 2016-07-06 04:57, Viresh Kumar wrote: >>> The i2c-dev calls i2c_get_adapter() from the .open() callback, which >>> doesn't let the adapter device unregister unless the .close() callback >>> is called. >>>

Re: [PATCH 2/2] i2c-dev: Don't block the adapter from unregistering

On 07/06/2016 04:33 PM, Viresh Kumar wrote: > On 06-07-16, 10:22, Peter Rosin wrote: >> On 2016-07-06 04:57, Viresh Kumar wrote: >>> The i2c-dev calls i2c_get_adapter() from the .open() callback, which >>> doesn't let the adapter device unregister unless the .close() callback >>> is called. >>>

Re: [PATCH 0/2] i2c-dev: Don't let userspace block adapter

On 07/06/2016 04:57 AM, Viresh Kumar wrote: > Hi Wolfram/Jean, > > I am part of the kernel team for Google's projectara [1], where we are > building a module smart phone. > > This series tries to fix one of the problems we hit on our system as we > are required to hotplug pretty much every thing

Re: [PATCH 0/2] i2c-dev: Don't let userspace block adapter

On 07/06/2016 04:57 AM, Viresh Kumar wrote: > Hi Wolfram/Jean, > > I am part of the kernel team for Google's projectara [1], where we are > building a module smart phone. > > This series tries to fix one of the problems we hit on our system as we > are required to hotplug pretty much every thing

Re: [PATCH 1/3] mfd: add support for Allwinner SoCs ADC

On 07/03/2016 01:17 PM, Jonathan Cameron wrote: > On 28/06/16 09:18, Quentin Schulz wrote: >> The Allwinner SoCs all have an ADC that can also act as a touchscreen >> controller and a thermal sensor. For now, only the ADC and the thermal >> sensor drivers are probed by the MFD, the touchscreen

Re: [PATCH 1/3] mfd: add support for Allwinner SoCs ADC

On 07/03/2016 01:17 PM, Jonathan Cameron wrote: > On 28/06/16 09:18, Quentin Schulz wrote: >> The Allwinner SoCs all have an ADC that can also act as a touchscreen >> controller and a thermal sensor. For now, only the ADC and the thermal >> sensor drivers are probed by the MFD, the touchscreen

Re: [3/3] hwmon: iio_hwmon: defer probe when no channel is found

On 06/30/2016 03:59 PM, Jonathan Cameron wrote: > > > On 30 June 2016 04:47:25 BST, Guenter Roeck wrote: >> On Tue, Jun 28, 2016 at 10:18:17AM +0200, Quentin Schulz wrote: >>> iio_channel_get_all returns -ENODEV when it cannot find either >> phandles and >>> properties in

Re: [3/3] hwmon: iio_hwmon: defer probe when no channel is found

On 06/30/2016 03:59 PM, Jonathan Cameron wrote: > > > On 30 June 2016 04:47:25 BST, Guenter Roeck wrote: >> On Tue, Jun 28, 2016 at 10:18:17AM +0200, Quentin Schulz wrote: >>> iio_channel_get_all returns -ENODEV when it cannot find either >> phandles and >>> properties in the Device Tree or

Re: [PATCH v2 4/5] ASoC: tpa6130a2: Add DAPM support

> + /* before widget power up */ > + if (SND_SOC_DAPM_EVENT_ON(event)) { > + /* Turn on the chip */ > + tpa6130a2_power(data, true); > + /* Sync the registers */ > + ret = regcache_sync(data->regmap); > + if (ret < 0) { > +

<    1   2   3   4   5   6   7   8   9   10   >