Re: [PATCH] iio: humidity: Replace older GPIO APIs with GPIO Consumer APIs for the dht11 sensor

inux/of_gpio.h" > > Signed-off-by: Shobhit Kukreti Acked-by: Harald Geyer > --- > drivers/iio/humidity/dht11.c | 28 ++-- > 1 file changed, 10 insertions(+), 18 deletions(-) > > diff --git a/drivers/iio/humidity/dht11.c b/drivers/iio/humidity/dht

Re: [PATCHv2 5/5] arm64: allwinner: a64: Add support for TERES-I laptop

Maxime Ripard writes: > On Thu, Mar 15, 2018 at 04:25:10PM +0000, Harald Geyer wrote: > > + leds { > > + compatible = "gpio-leds"; > > + > > + capslock { > > + label = "leds:green:capslock"; > > The

Re: [PATCHv2 5/5] arm64: allwinner: a64: Add support for TERES-I laptop

Maxime Ripard writes: > On Thu, Mar 15, 2018 at 04:25:10PM +0000, Harald Geyer wrote: > > + leds { > > + compatible = "gpio-leds"; > > + > > + capslock { > > + label = "leds:green:capslock"; > > The

Re: arm64: allwinner: Add support for TERES I laptop

Hi, afzal mohammed writes: > On Mon, Mar 12, 2018 at 04:10:45PM +0000, Harald Geyer wrote: > > This series adds support for the TERES I open hardware laptop produced > > by olimex. With these patches and a bootloader capable of setting up > > simple framebuffer the la

Re: arm64: allwinner: Add support for TERES I laptop

Hi, afzal mohammed writes: > On Mon, Mar 12, 2018 at 04:10:45PM +0000, Harald Geyer wrote: > > This series adds support for the TERES I open hardware laptop produced > > by olimex. With these patches and a bootloader capable of setting up > > simple framebuffer the la

[PATCHv2 0/5] arm64: allwinner: Add support for TERES-I laptop

. Patch 5 finally adds the board dts itself. Changes to the previous version are listed along the individual patches. best regards, Harald Harald Geyer (5): arm64: dts: allwinner: a64: Add i2c0 pins arm64: dts: allwinner: a64: Add watchdog arm64: dts: allwinner: a64: add simplefb for A64 SoC

[PATCHv2 0/5] arm64: allwinner: Add support for TERES-I laptop

. Patch 5 finally adds the board dts itself. Changes to the previous version are listed along the individual patches. best regards, Harald Harald Geyer (5): arm64: dts: allwinner: a64: Add i2c0 pins arm64: dts: allwinner: a64: Add watchdog arm64: dts: allwinner: a64: add simplefb for A64 SoC

[PATCHv2 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

The A64 SoC features two display pipelines, one has a LCD output, the other has a HDMI output. Add support for simplefb for the LCD output. Tested on Teres I. This patch was inspired by work of Icenowy Zheng. Signed-off-by: Harald Geyer <har...@ccbib.org> --- changes since v1: none arch

[PATCHv2 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

The A64 SoC features two display pipelines, one has a LCD output, the other has a HDMI output. Add support for simplefb for the LCD output. Tested on Teres I. This patch was inspired by work of Icenowy Zheng. Signed-off-by: Harald Geyer --- changes since v1: none arch/arm64/boot/dts

[PATCHv2 4/5] arm64: dts: allwinner: a64: Add pwm device

This device is compatible with A13, so no new driver is needed. A new compatible string is reserved in the binding documentation, to be used together with the proper fall back. Tested on Teres-I. Signed-off-by: Harald Geyer <har...@ccbib.org> --- changes since v1: * add and use an A64 sp

[PATCHv2 4/5] arm64: dts: allwinner: a64: Add pwm device

This device is compatible with A13, so no new driver is needed. A new compatible string is reserved in the binding documentation, to be used together with the proper fall back. Tested on Teres-I. Signed-off-by: Harald Geyer --- changes since v1: * add and use an A64 specific compatible string

[PATCHv2 1/5] arm64: dts: allwinner: a64: Add i2c0 pins

Add the proper pin group node to reference in board files. Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Signed-off-by: Harald Geyer <har...@ccbib.org> --- changes since v1: none arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 + 1 file changed, 5 insertions(+) diff

[PATCHv2 5/5] arm64: allwinner: a64: Add support for TERES-I laptop

The TERES-I is an open hardware laptop built by Olimex using the Allwinner A64 SoC. Add the board specific .dts file, which includes the A64 .dtsi and enables the peripherals that we support so far. Signed-off-by: Harald Geyer <har...@ccbib.org> --- changes since v1: * use SPDX header i

[PATCHv2 1/5] arm64: dts: allwinner: a64: Add i2c0 pins

Add the proper pin group node to reference in board files. Reviewed-by: Andre Przywara Signed-off-by: Harald Geyer --- changes since v1: none arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b

[PATCHv2 5/5] arm64: allwinner: a64: Add support for TERES-I laptop

The TERES-I is an open hardware laptop built by Olimex using the Allwinner A64 SoC. Add the board specific .dts file, which includes the A64 .dtsi and enables the peripherals that we support so far. Signed-off-by: Harald Geyer --- changes since v1: * use SPDX header instead of license text

[PATCHv2 2/5] arm64: dts: allwinner: a64: Add watchdog

Add a watchdog node for the A64, automatically enabled on all boards. Since the device is compatible with an existing driver, we only reserve a new compatible string to be used together with the fall back. Tested on Olimex Teres-I. Signed-off-by: Harald Geyer <har...@ccbib.org> --- changes

[PATCHv2 2/5] arm64: dts: allwinner: a64: Add watchdog

Add a watchdog node for the A64, automatically enabled on all boards. Since the device is compatible with an existing driver, we only reserve a new compatible string to be used together with the fall back. Tested on Olimex Teres-I. Signed-off-by: Harald Geyer --- changes since v1: * add and use

Re: [PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

Maxime Ripard writes: > Hi, > > On Tue, Mar 13, 2018 at 10:18:22AM +0100, Harald Geyer wrote: >> Maxime Ripard writes: >>> On Mon, Mar 12, 2018 at 04:10:48PM +, Harald Geyer wrote: >>>> The A64 SoC features two display pipelines, one has a LCD outp

Re: [PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

Maxime Ripard writes: > Hi, > > On Tue, Mar 13, 2018 at 10:18:22AM +0100, Harald Geyer wrote: >> Maxime Ripard writes: >>> On Mon, Mar 12, 2018 at 04:10:48PM +, Harald Geyer wrote: >>>> The A64 SoC features two display pipelines, one has a LCD outp

Re: [PATCH 5/5] arm64: allwinner: a64: Add support for TERES I laptop

Hi, > Maxime Ripard writes: > > Hi, > > On Mon, Mar 12, 2018 at 04:10:50PM +0000, Harald Geyer wrote: >> The TERES I is an open hardware laptop built by Olimex using the >> Allwinner A64 SoC. >> >> Add the board specific .dts file, which includes the A

Re: [PATCH 5/5] arm64: allwinner: a64: Add support for TERES I laptop

Hi, > Maxime Ripard writes: > > Hi, > > On Mon, Mar 12, 2018 at 04:10:50PM +0000, Harald Geyer wrote: >> The TERES I is an open hardware laptop built by Olimex using the >> Allwinner A64 SoC. >> >> Add the board specific .dts file, which includes the A

Re: [PATCH 2/5] arm64: dts: allwinner: a64: Add watchdog

Hi, André Przywara writes: > On 12/03/18 16:10, Harald Geyer wrote: > > Add a watchdog node for the A64, automatically enabled on all boards. > > Tested on Olimex Teres I. > > > > Signed-off-by: Harald Geyer <har...@ccbib.org> > > --- > > arch

Re: [PATCH 2/5] arm64: dts: allwinner: a64: Add watchdog

Hi, André Przywara writes: > On 12/03/18 16:10, Harald Geyer wrote: > > Add a watchdog node for the A64, automatically enabled on all boards. > > Tested on Olimex Teres I. > > > > Signed-off-by: Harald Geyer > > --- > > arch/arm64/boot/dts/allwinner

Re: [PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

Maxime Ripard writes: > On Mon, Mar 12, 2018 at 04:10:48PM +0000, Harald Geyer wrote: >> The A64 SoC features two display pipelines, one has a LCD output, the >> other has a HDMI output. >> >> Add support for simplefb for the LCD output. Tested on Teres I. >> &

Re: [PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

Maxime Ripard writes: > On Mon, Mar 12, 2018 at 04:10:48PM +0000, Harald Geyer wrote: >> The A64 SoC features two display pipelines, one has a LCD output, the >> other has a HDMI output. >> >> Add support for simplefb for the LCD output. Tested on Teres I. >> &

Re: [PATCH 1/5] arm64: dts: allwinner: a64: Add i2c0 pins

André Przywara writes: > On 12/03/18 16:10, Harald Geyer wrote: > > Add the proper pin group node to reference in board files. > > > > Signed-off-by: Harald Geyer <har...@ccbib.org> > > That looks correct to me, so: > > Reviewed-by: Andre Przywar

Re: [PATCH 1/5] arm64: dts: allwinner: a64: Add i2c0 pins

André Przywara writes: > On 12/03/18 16:10, Harald Geyer wrote: > > Add the proper pin group node to reference in board files. > > > > Signed-off-by: Harald Geyer > > That looks correct to me, so: > > Reviewed-by: Andre Przywara > > But out of curiosity

[PATCH 2/5] arm64: dts: allwinner: a64: Add watchdog

Add a watchdog node for the A64, automatically enabled on all boards. Tested on Olimex Teres I. Signed-off-by: Harald Geyer <har...@ccbib.org> --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a6

[PATCH 2/5] arm64: dts: allwinner: a64: Add watchdog

Add a watchdog node for the A64, automatically enabled on all boards. Tested on Olimex Teres I. Signed-off-by: Harald Geyer --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64

arm64: allwinner: Add support for TERES I laptop

. Patch 5 finally adds the board dts itself. best regards, Harald Harald Geyer (5): arm64: dts: allwinner: a64: Add i2c0 pins arm64: dts: allwinner: a64: Add watchdog arm64: dts: allwinner: a64: add simplefb for A64 SoC arm64: dts: allwinner: a64: Add pwm device arm64: allwinner: a64: Add

arm64: allwinner: Add support for TERES I laptop

. Patch 5 finally adds the board dts itself. best regards, Harald Harald Geyer (5): arm64: dts: allwinner: a64: Add i2c0 pins arm64: dts: allwinner: a64: Add watchdog arm64: dts: allwinner: a64: add simplefb for A64 SoC arm64: dts: allwinner: a64: Add pwm device arm64: allwinner: a64: Add

[PATCH 1/5] arm64: dts: allwinner: a64: Add i2c0 pins

Add the proper pin group node to reference in board files. Signed-off-by: Harald Geyer <har...@ccbib.org> --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/all

[PATCH 4/5] arm64: dts: allwinner: a64: Add pwm device

This device is compatible with A13, so no new driver is needed. Signed-off-by: Harald Geyer <har...@ccbib.org> --- I saw that Andre Przywara has been working on A64 pwm too and has submitted some patches a few days ago. I think his patches are functionally equivalent to this one here, but

[PATCH 1/5] arm64: dts: allwinner: a64: Add i2c0 pins

Add the proper pin group node to reference in board files. Signed-off-by: Harald Geyer --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index

[PATCH 4/5] arm64: dts: allwinner: a64: Add pwm device

This device is compatible with A13, so no new driver is needed. Signed-off-by: Harald Geyer --- I saw that Andre Przywara has been working on A64 pwm too and has submitted some patches a few days ago. I think his patches are functionally equivalent to this one here, but clean up things a bit

[PATCH 5/5] arm64: allwinner: a64: Add support for TERES I laptop

The TERES I is an open hardware laptop built by Olimex using the Allwinner A64 SoC. Add the board specific .dts file, which includes the A64 .dtsi and enables the peripherals that we support so far. Signed-off-by: Harald Geyer <har...@ccbib.org> --- arch/arm64/boot/dts/allwinner/Ma

[PATCH 5/5] arm64: allwinner: a64: Add support for TERES I laptop

The TERES I is an open hardware laptop built by Olimex using the Allwinner A64 SoC. Add the board specific .dts file, which includes the A64 .dtsi and enables the peripherals that we support so far. Signed-off-by: Harald Geyer --- arch/arm64/boot/dts/allwinner/Makefile | 1

[PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

The A64 SoC features two display pipelines, one has a LCD output, the other has a HDMI output. Add support for simplefb for the LCD output. Tested on Teres I. This patch was inspired by work of Icenowy Zheng. Signed-off-by: Harald Geyer <har...@ccbib.org> --- arch/arm64/boot/dts/all

[PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC

The A64 SoC features two display pipelines, one has a LCD output, the other has a HDMI output. Add support for simplefb for the LCD output. Tested on Teres I. This patch was inspired by work of Icenowy Zheng. Signed-off-by: Harald Geyer --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20

Re: [PATCH,RESEND2] regulator: fixed, gpio: dt: regulator-name is required property

Mark Brown writes: > On Tue, Feb 13, 2018 at 02:43:08PM +0000, Harald Geyer wrote: > > > BTW, it took me a bit to figure out that by "content free ping" you are > > refering to the quoting of the patch. Maybe you can reword your canned > > respon

Re: [PATCH,RESEND2] regulator: fixed, gpio: dt: regulator-name is required property

Mark Brown writes: > On Tue, Feb 13, 2018 at 02:43:08PM +0000, Harald Geyer wrote: > > > BTW, it took me a bit to figure out that by "content free ping" you are > > refering to the quoting of the patch. Maybe you can reword your canned > > respon

[PATCH,RESEND2] regulator: fixed, gpio: dt: regulator-name is required property

These two drivers fail to probe if no name is provided. For details see: https://www.spinics.net/lists/kernel/msg2457515.html Signed-off-by: Harald Geyer <har...@ccbib.org> Acked-by: Rob Herring <r...@kernel.org> --- This is already the second resend for this trivial device pro

[PATCH,RESEND2] regulator: fixed, gpio: dt: regulator-name is required property

These two drivers fail to probe if no name is provided. For details see: https://www.spinics.net/lists/kernel/msg2457515.html Signed-off-by: Harald Geyer Acked-by: Rob Herring --- This is already the second resend for this trivial device probing bug fix. It was written to your specification

Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

Mark Brown writes: > On Mon, Feb 27, 2017 at 08:17:10PM +0100, Harald Geyer wrote: > > Mark Brown writes: > > > > I'd need to figure out exactly what the restrictions are and like I say > > > the name of the function itself is confusing, I suspect because it > >

Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

Mark Brown writes: > On Mon, Feb 27, 2017 at 08:17:10PM +0100, Harald Geyer wrote: > > Mark Brown writes: > > > > I'd need to figure out exactly what the restrictions are and like I say > > > the name of the function itself is confusing, I suspect because it > >

Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

On 06.03.2017 23:22, Tejun Heo wrote: I don't think it's a matter of "fixing" the existing mod_delayed_work(). What the new function is implementing wouldn't fit use cases where the timeout should only be shortened (IIRC, writeback code does that). I'm not against adding new interface to

Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

On 06.03.2017 23:22, Tejun Heo wrote: I don't think it's a matter of "fixing" the existing mod_delayed_work(). What the new function is implementing wouldn't fit use cases where the timeout should only be shortened (IIRC, writeback code does that). I'm not against adding new interface to

[bug] regulator: fixed, gpio: probe fails on unset regulator-name

Hi! Documentation/devicetree/bindings/regulator/regulator.txt says that the regulator-name property is optional. However fixed and gpio regulators fail in probe with the following message, if the property is not present: | reg-fixed-voltage regulators:sensor_supply: Failed to allocate supply

[bug] regulator: fixed, gpio: probe fails on unset regulator-name

Hi! Documentation/devicetree/bindings/regulator/regulator.txt says that the regulator-name property is optional. However fixed and gpio regulators fail in probe with the following message, if the property is not present: | reg-fixed-voltage regulators:sensor_supply: Failed to allocate supply

Re: [PATCH v14 3/5] input: touchscreen: mxs-lradc: Add support for touchscreen

Hi Ksenija! Ksenija Stanojevic writes: > +static int mxs_lradc_ts_register(struct mxs_lradc_ts *ts) > +{ > + struct input_dev *input = ts->ts_input; > + struct device *dev = ts->dev; > + > + input = devm_input_allocate_device(dev); > + if (!input) > + return -ENOMEM; >

Re: [PATCH v14 3/5] input: touchscreen: mxs-lradc: Add support for touchscreen

Hi Ksenija! Ksenija Stanojevic writes: > +static int mxs_lradc_ts_register(struct mxs_lradc_ts *ts) > +{ > + struct input_dev *input = ts->ts_input; > + struct device *dev = ts->dev; > + > + input = devm_input_allocate_device(dev); > + if (!input) > + return -ENOMEM; >

Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

Mark Brown writes: > On Fri, Feb 24, 2017 at 12:22:37AM +0100, Harald Geyer wrote: > > Mark Brown writes: > > > > detail. I'd expect to see some words describing the situations where it > > > can be used or something, both the name and the lack of any information &

Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

Mark Brown writes: > On Fri, Feb 24, 2017 at 12:22:37AM +0100, Harald Geyer wrote: > > Mark Brown writes: > > > > detail. I'd expect to see some words describing the situations where it > > > can be used or something, both the name and the lack of any information &

Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

Mark Brown writes: > > > The obvious question here, especially in the case of > > > mod_delayed_work(), is why not fix the existing functions to have > > > the expected behaviour? > > > AFAICS the existing functions behave as documented. I don't feel > > to be an authority to decide that the

Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

Mark Brown writes: > > > The obvious question here, especially in the case of > > > mod_delayed_work(), is why not fix the existing functions to have > > > the expected behaviour? > > > AFAICS the existing functions behave as documented. I don't feel > > to be an authority to decide that the

Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

Mark Brown writes: > On Wed, Feb 22, 2017 at 05:41:24PM +0000, Harald Geyer wrote: > > Drivers calling queue_delayed_work() or mod_delayed_work() multiple times > > on the same work without coordination get undefined behaviour. Add a new > > function, which is easier to

Re: [PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

Mark Brown writes: > On Wed, Feb 22, 2017 at 05:41:24PM +0000, Harald Geyer wrote: > > Drivers calling queue_delayed_work() or mod_delayed_work() multiple times > > on the same work without coordination get undefined behaviour. Add a new > > function, which is easier to

[PATCH 2/2] regulator: core: Fix race on multiple calls to regulator_disable_deferred()

, the timer isn't reset. Both issues can cause the regulator to get disabled early. Signed-off-by: Harald Geyer <har...@ccbib.org> --- drivers/regulator/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index c

[PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

Drivers calling queue_delayed_work() or mod_delayed_work() multiple times on the same work without coordination get undefined behaviour. Add a new function, which is easier to use. Signed-off-by: Harald Geyer <har...@ccbib.org> --- include/linux/workqueue.h | 17 +

[PATCH 2/2] regulator: core: Fix race on multiple calls to regulator_disable_deferred()

, the timer isn't reset. Both issues can cause the regulator to get disabled early. Signed-off-by: Harald Geyer --- drivers/regulator/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index cc68604..ce4923b 100644

[PATCH 1/2] workqueue: Add new function mod_fwd_delayed_work()

Drivers calling queue_delayed_work() or mod_delayed_work() multiple times on the same work without coordination get undefined behaviour. Add a new function, which is easier to use. Signed-off-by: Harald Geyer --- include/linux/workqueue.h | 17 + kernel/workqueue.c| 41

Re: Question about regulator API

Mark Brown writes: > On Fri, Dec 16, 2016 at 02:41:42PM +0100, Harald Geyer wrote: > > Mark Brown writes: > > > On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote: > > > > This doesn't feel like a regulator API problem exactly, a lot of what > > &g

Re: Question about regulator API

Mark Brown writes: > On Fri, Dec 16, 2016 at 02:41:42PM +0100, Harald Geyer wrote: > > Mark Brown writes: > > > On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote: > > > > This doesn't feel like a regulator API problem exactly, a lot of what > > &g

Re: Question about regulator API

Mark Brown writes: > On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote: > > > Thus the following constraints should be met: > > * When user space asks > > the driver to read a device, it needs to "claim" the supply and > > ensure that it h

Re: Question about regulator API

Mark Brown writes: > On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote: > > > Thus the following constraints should be met: > > * When user space asks > > the driver to read a device, it needs to "claim" the supply and > > ensure that it h

Question about regulator API

Hi all! I have a quite complex situation with regulator consumers, which I'm not sure how to handle best. Suppose there is some quirky HW that after some random time crashes - i.e. it doesn't respond to requests anymore at all. The driver can detect this situation and the only way to fix it is

Question about regulator API

Hi all! I have a quite complex situation with regulator consumers, which I'm not sure how to handle best. Suppose there is some quirky HW that after some random time crashes - i.e. it doesn't respond to requests anymore at all. The driver can detect this situation and the only way to fix it is

Re: [PATCH v3 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

Hi Ksenija! Ksenija Stanojević writes: > On Tue, Jun 28, 2016 at 6:28 PM, Lee Jones wrote: > >> +static int mxs_lradc_add_device(struct platform_device *pdev, > >> + struct mxs_lradc *lradc, char *name, int i) > >> +{ > >> + struct mfd_cell

Re: [PATCH v3 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

Hi Ksenija! Ksenija Stanojević writes: > On Tue, Jun 28, 2016 at 6:28 PM, Lee Jones wrote: > >> +static int mxs_lradc_add_device(struct platform_device *pdev, > >> + struct mxs_lradc *lradc, char *name, int i) > >> +{ > >> + struct mfd_cell *cell; > >> + > >> +

Re: [PATCH 1/3] mfd: mxs-lradc: Add support for mxs-lradc MFD

Hi Ksenija, thanks for working on this. A bit of nit picking inline. On 29.04.2016 13:47, Ksenija Stanojevic wrote: Add core files for mxs-lradc MFD driver. Signed-off-by: Ksenija Stanojevic --- drivers/mfd/Kconfig | 33 +-- drivers/mfd/Makefile

Re: [PATCH 1/3] mfd: mxs-lradc: Add support for mxs-lradc MFD

Hi Ksenija, thanks for working on this. A bit of nit picking inline. On 29.04.2016 13:47, Ksenija Stanojevic wrote: Add core files for mxs-lradc MFD driver. Signed-off-by: Ksenija Stanojevic --- drivers/mfd/Kconfig | 33 +-- drivers/mfd/Makefile | 1 +

Re: [PATCH 1/2] regulator: gpio: Avoid unnecessarily copying data structures in probe()

Mark Brown writes: > On Thu, Jan 28, 2016 at 07:55:17PM +0000, Harald Geyer wrote: > > The data structures either have been copied in > > of_get_gpio_regulator_config() already or are part of platform data, > > which we keep a pointer to for the life time of the device a

Re: [PATCH 1/2] regulator: gpio: Avoid unnecessarily copying data structures in probe()

Mark Brown writes: > On Thu, Jan 28, 2016 at 07:55:17PM +0000, Harald Geyer wrote: > > The data structures either have been copied in > > of_get_gpio_regulator_config() already or are part of platform data, > > which we keep a pointer to for the life time of the device a

[PATCH 0/2] regulator: gpio: fix error paths in probe()

zeroed) to of_get_gpio_regulator_config() - I don't know if this is ok. * I'm not sure if copying config->supply_name is actually necessary, so I left that one in. Harald Geyer (2): regulator: gpio: Avoid unnecessarily copying data structures in probe() regulator: gpio: Move last remaini

[PATCH 1/2] regulator: gpio: Avoid unnecessarily copying data structures in probe()

The data structures either have been copied in of_get_gpio_regulator_config() already or are part of platform data, which we keep a pointer to for the life time of the device anyway. As a side effect this fixes the cleanup pathes if probe() fails. Signed-off-by: Harald Geyer --- drivers

[PATCH 2/2] regulator: gpio: Move last remaining memory allocation to devres

Simple cleanup without functional changes. Signed-off-by: Harald Geyer --- drivers/regulator/gpio-regulator.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/drivers/regulator/gpio-regulator.c b/drivers/regulator/gpio-regulator.c index 5e2e14d..5fe4921 100644

[PATCH 2/2] regulator: gpio: Move last remaining memory allocation to devres

Simple cleanup without functional changes. Signed-off-by: Harald Geyer <har...@ccbib.org> --- drivers/regulator/gpio-regulator.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/drivers/regulator/gpio-regulator.c b/drivers/regulator/gpio-regulator.c

[PATCH 1/2] regulator: gpio: Avoid unnecessarily copying data structures in probe()

The data structures either have been copied in of_get_gpio_regulator_config() already or are part of platform data, which we keep a pointer to for the life time of the device anyway. As a side effect this fixes the cleanup pathes if probe() fails. Signed-off-by: Harald Geyer <har...@ccbib.

[PATCH 0/2] regulator: gpio: fix error paths in probe()

zeroed) to of_get_gpio_regulator_config() - I don't know if this is ok. * I'm not sure if copying config->supply_name is actually necessary, so I left that one in. Harald Geyer (2): regulator: gpio: Avoid unnecessarily copying data structures in probe() regulator: gpio: Move last remaini

Re: [PATCH 2/7] timekeeping: Provide new API to get the current time resolution

John Stultz writes: > > I was thinking that the variable hrtimer_resolution, that Thomas > > introduced in > > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/include/linux/hrtimer.h?h=timers/wip=03eeacdb07e2fdfc4ef311c2593286c92eba609c > > is meant to provide the same information.

Re: [PATCH 2/7] timekeeping: Provide new API to get the current time resolution

Hi John, John Stultz writes: > From: Harald Geyer > > This patch series introduces a new function > u32 ktime_get_resolution_ns(void) > which allows to clean up some driver code. thanks for keeping track of this, but is this patch still useful? I was thinking th

Re: [PATCH 2/7] timekeeping: Provide new API to get the current time resolution

Hi John, John Stultz writes: From: Harald Geyer har...@ccbib.org This patch series introduces a new function u32 ktime_get_resolution_ns(void) which allows to clean up some driver code. thanks for keeping track of this, but is this patch still useful? I was thinking that the variable

Re: [PATCH 2/7] timekeeping: Provide new API to get the current time resolution

John Stultz writes: I was thinking that the variable hrtimer_resolution, that Thomas introduced in https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/include/linux/hrtimer.h?h=timers/wipid=03eeacdb07e2fdfc4ef311c2593286c92eba609c is meant to provide the same information. I

[PATCHv2 2/2] iio: dht11: Use new function ktime_get_resolution_ns()

. There is no ECLOCKTOOSLOW error code. Signed-off-by: Harald Geyer --- changes since V1: call ktime_get_xxx() functions directly instead of using the wrappers of the iio subsystem. drivers/iio/humidity/dht11.c | 42 ++ 1 files changed, 22 insertions(+), 20 deletions

[PATCHv2 1/2] timekeeping: Provide new API to get the current time resolution

the resolution in a rather messy and convoluted way. We can do much better with the new code. This API is not designed to be exposed to user space. This has been tested on i386, sunxi and mxs. Signed-off-by: Harald Geyer --- changes since V1: Improved commit message. include/linux/timekeeping.h |1

[PATCHv2 0/2] Provide new API to get the current time resolution

with more cleanup patches to dth11.c later -- the main goal for now is, to get the new code for timekeeping reviewed and merged. changes since V1: * dropped patch for adding wrapper code to the iio framework * improved commit messages Harald Geyer (2): timekeeping: Provide new API to get

[PATCHv2 0/2] Provide new API to get the current time resolution

with more cleanup patches to dth11.c later -- the main goal for now is, to get the new code for timekeeping reviewed and merged. changes since V1: * dropped patch for adding wrapper code to the iio framework * improved commit messages Harald Geyer (2): timekeeping: Provide new API to get

[PATCHv2 1/2] timekeeping: Provide new API to get the current time resolution

the resolution in a rather messy and convoluted way. We can do much better with the new code. This API is not designed to be exposed to user space. This has been tested on i386, sunxi and mxs. Signed-off-by: Harald Geyer har...@ccbib.org --- changes since V1: Improved commit message. include/linux

[PATCHv2 2/2] iio: dht11: Use new function ktime_get_resolution_ns()

. There is no ECLOCKTOOSLOW error code. Signed-off-by: Harald Geyer har...@ccbib.org --- changes since V1: call ktime_get_xxx() functions directly instead of using the wrappers of the iio subsystem. drivers/iio/humidity/dht11.c | 42 ++ 1 files changed, 22 insertions

Re: [PATCHv2 1/3,RESEND] iio: dht11: Fix out-of-bounds read

Richard Weinberger writes: > Am 10.01.2015 um 12:14 schrieb Jonathan Cameron: > > On 07/01/15 12:15, Harald Geyer wrote: > >> As we access i-1 we must not start with i=0. > >> > >> From: Richard Weinberger > >> Signed-off-by: Richard Weinberg

Re: [PATCHv2 1/3,RESEND] iio: dht11: Fix out-of-bounds read

Richard Weinberger writes: Am 10.01.2015 um 12:14 schrieb Jonathan Cameron: On 07/01/15 12:15, Harald Geyer wrote: As we access i-1 we must not start with i=0. From: Richard Weinberger rich...@nod.at Signed-off-by: Richard Weinberger rich...@nod.at Acked-by: Hartmut Knaack knaac

[PATCHv2 3/3,RESEND] iio: dht11: IRQ fixes

Signed-off-by: Richard Weinberger Signed-off-by: Harald Geyer --- Resending to get the metadata right. changes since v1: Reduce the expected number of edges per data transmission, since we won't see the edges we generate ourselves. drivers/iio/humidity/dht11.c | 62

[PATCHv2 2/3,RESEND] iio: dht11: Add locking

Make sure that the read function is not interrupted... From: Richard Weinberger Signed-off-by: Richard Weinberger Acked-by: Harald Geyer Reviewed-by: Sanjeev Sharma --- Resending again to get the metadata right. No Signed-off-by from me, because I didn't contribute anything. No changes since

[PATCHv2 1/3,RESEND] iio: dht11: Fix out-of-bounds read

As we access i-1 we must not start with i=0. From: Richard Weinberger Signed-off-by: Richard Weinberger Acked-by: Hartmut Knaack Acked-by: Harald Geyer Reviewed-by: Sanjeev Sharma --- Resending again to get the metadata right. No Signed-off-by from me, because I didn't contribute anything

[PATCHv2 3/3,RESEND] iio: dht11: IRQ fixes

...@nod.at Signed-off-by: Richard Weinberger rich...@nod.at Signed-off-by: Harald Geyer har...@ccbib.org --- Resending to get the metadata right. changes since v1: Reduce the expected number of edges per data transmission, since we won't see the edges we generate ourselves. drivers/iio/humidity

[PATCHv2 1/3,RESEND] iio: dht11: Fix out-of-bounds read

As we access i-1 we must not start with i=0. From: Richard Weinberger rich...@nod.at Signed-off-by: Richard Weinberger rich...@nod.at Acked-by: Hartmut Knaack knaac...@gmx.de Acked-by: Harald Geyer har...@ccbib.org Reviewed-by: Sanjeev Sharma sanjeev_sha...@mentor.com --- Resending again to get

[PATCHv2 2/3,RESEND] iio: dht11: Add locking

Make sure that the read function is not interrupted... From: Richard Weinberger rich...@nod.at Signed-off-by: Richard Weinberger rich...@nod.at Acked-by: Harald Geyer har...@ccbib.org Reviewed-by: Sanjeev Sharma sanjeev_sha...@mentor.com --- Resending again to get the metadata right. No Signed

Re: [PATCHv2 3/3] iio: dht11: IRQ fixes

Weinberger Signed-off-by: Harald Geyer --- changes since v1: Reduce the expected number of edges per data transmission, since we won't see the edges we generate ourselves. drivers/iio/humidity/dht11.c | 62 +++-- 1 files changed, 35 insertions(+), 27 deletions

Re: [PATCHv2 2/3] iio: dht11: Add locking

Make sure that the read function is not interrupted... Signed-off-by: Richard Weinberger Acked-by: Harald Geyer --- Resending for Richard Weinberger. No changes since v1 except reordering. drivers/iio/humidity/dht11.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git

[PATCHv2 1/3] iio: dht11: Fix out-of-bounds read

As we access i-1 we must not start with i=0. Signed-off-by: Richard Weinberger Acked-by: Hartmut Knaack Acked-by: Harald Geyer --- Resending for Richard Weinberger. No changes since v1 except reordering. drivers/iio/humidity/dht11.c |2 +- 1 files changed, 1 insertions(+), 1 deletions

  1   2   >