Re: [PATCH 2/4] i2c: at91: implement i2c bus recovery

On 25/08/2020 21:28, Wolfram Sang wrote: Hi Phil, yes, this thread is old but a similar issue came up again... On Fri, Oct 25, 2019 at 09:14:00AM +0800, Phil Reid wrote: So at the beginning of a new transfer, we should check if SDA (or SCL?) is low and, if it's true, only then we should

Re: [PATCH 4.19 32/79] fpga: altera-ps-spi: Fix getting of optional confd gpio

confd gpio"); } /* Register manager with unique name */ Best regards, Pavel -- Regards Phil Reid

Re: [PATCH 4/4] iio: adc: ina2xx: Use label proper for device identification

On 26/08/2019 02:07, Jonathan Cameron wrote: On Wed, 21 Aug 2019 11:12:00 +0200 Michal Simek wrote: On 21. 08. 19 4:11, Phil Reid wrote: On 20/08/2019 22:11, Michal Simek wrote: Add support for using label property for easier device identification via iio framework. Signed-off-by: Michal

Re: iio: Is storing output values to non volatile registers something we should do automatically or leave to userspace action. [was Re: [PATCH] iio: potentiometer: max5432: update the non-volatile pos

On 19/08/2019 03:32, Jonathan Cameron wrote: On Mon, 12 Aug 2019 19:08:12 +0800 Phil Reid wrote: G'day Martin / Jonathan, On 12/08/2019 18:37, Martin Kaiser wrote: Hi Jonathan, Thus wrote Jonathan Cameron (ji...@kernel.org): The patch is fine, but I'm wondering about whether we need

Re: [PATCH 4/4] iio: adc: ina2xx: Use label proper for device identification

sonally. It'd be nice if it was a core function so it could be an opt in to any iio device. Don't know how well received that'd be thou. -- Regards Phil Reid

Re: [PATCH 2/4] iio: adc: ina2xx: Setup better name then simple ina2xx

vm_iio_kfifo_allocate(_dev->dev); -- Regards Phil Reid

Re: [PATCH 1/4] iio: adc: ina2xx: Define *device_node only once

>driver_data == ina226) { indio_dev->channels = ina226_channels; indio_dev->num_channels = ARRAY_SIZE(ina226_channels); -- Regards Phil Reid ElectroMagnetic Imaging Technology Pty Ltd Development of Geophysical Instrumentation & Software www.elect

Re: iio: Is storing output values to non volatile registers something we should do automatically or leave to userspace action. [was Re: [PATCH] iio: potentiometer: max5432: update the non-volatile pos

think it's something that userspace should initiate via an explicit command. Writing the NV for the AD5272 is something I planned to add at some stage. But so far the default factory values have worked ok. It'd be nice for cross device consistency for any interface for this. -- Regards Phil Reid

Re: [PATCH v6 19/57] iio: Remove dev_err() usage after platform_get_irq()

G'day Stephen, One comment below. On 31/07/2019 22:32, Stephen Boyd wrote: Quoting Phil Reid (2019-07-30 23:42:16) G'day Stephen, A comment unrelated to your change. On 31/07/2019 02:15, Stephen Boyd wrote: diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c index

Re: [PATCH v6 19/57] iio: Remove dev_err() usage after platform_get_irq()

return -ENODEV; Should this be returning st->irq instead of -ENODEV? eg: platform_get_irq can return -EPROBE_DEFER Pattern is repeated in a number of other places. - } res = platform_get_resource(pdev, IORESOURCE_MEM, 0); Regards Phil Reid

Re: [PATCH 1/2] [PATCH] gpio: Replace usage of bare 'unsigned' with 'unsigned int'

hip, } static int vprbrd_gpiob_direction_output(struct gpio_chip *chip, - unsigned offset, int value) + unsigned int offset, int value) { int ret; struct vprbrd_gpio *gpio = gpiochip_get_data(chip); -- Regards Phil Reid

Re: [PATCH RFC] gpio: Add Virtual Aggregator GPIO Driver

On 10/07/2019 18:21, Geert Uytterhoeven wrote: Hi Phil, On Wed, Jul 10, 2019 at 4:00 AM Phil Reid wrote: On 6/07/2019 00:05, Geert Uytterhoeven wrote: GPIO controllers are exported to userspace using /dev/gpiochip* character devices. Access control to these devices is provided by standard

Re: [PATCH 1/2] gpio: em: remove the gpiochip before removing the irq domain

_DEVICE_TABLE(of, em_gio_dt_ids); static struct platform_driver em_gio_device_driver = { .probe = em_gio_probe, - .remove = em_gio_remove, .driver = { .name = "em_gio", .of_match_table = em_gio_dt_ids, -- Regards Phil Reid

Re: [PATCH RFC] gpio: Add Virtual Aggregator GPIO Driver

static int __exit gpio_virt_agg_idr_remove(int id, void *p, void *data) +{ + struct gpio_virt_agg_entry *gva = p; + + platform_device_unregister(gva->pdev); + kfree(gva); + return 0; +} + +static void __exit gpio_virt_agg_exit(void) +{ + mutex_lock(_virt_agg_

Re: [PATCH V4 2/2] iio: light: isl29018: add optional vdd/vdda regulator operation support

On 11/12/2018 12:29 pm, Anson Huang wrote: G'day Anson, Just pulled up the datasheet for this chip. The absolute max for Vdda is speced as Vddd ±0.5 With a note that Vdda should be externally shorted to Vddd. The data sheet says vdda should be connected to vdd externally, then I think we

Re: [PATCH V4 2/2] iio: light: isl29018: add optional vdd/vdda regulator operation support

G'day Anson, Just pulled up the datasheet for this chip. The absolute max for Vdda is speced as Vddd +/-0.5 With a note that Vdda should be externally shorted to Vddd. On 11/12/2018 11:43 am, Anson Huang wrote: Hi, Phil Best Regards! Anson Huang -Original Message- From: Phil Reid

Re: [PATCH V4 2/2] iio: light: isl29018: add optional vdd/vdda regulator operation support

On 11/12/2018 11:24 am, Anson Huang wrote: The light sensor's power supply could be controlled by regulator on some platforms, such as i.MX6Q-SABRESD board, the light sensor isl29023's power supply is controlled by a GPIO fixed regulator, need to make sure the regulator is enabled before any

Re: [PATCH V2] iio: magnetometer: mag3110: add optional vdd/vddio regulator operation support

G'day Anson, On 10/12/2018 3:17 PM, Anson Huang wrote: The magnetometer's power supply could be controlled by regulator on some platforms, such as i.MX6Q-SABRESD board, the mag3110's power supply is controlled by a GPIO fixed regulator, need to make sure the regulator is enabled before any

Re: [PATCH v2] staging: iio: ad7816: Switch to the gpio descriptor interface

upport in the id table: > static const struct spi_device_id ad7816_id[] = { >{ "ad7816", 0 }, >{ "ad7817", 0 }, >{ "ad7818", 0 }, >{} > }; See: https://www.analog.com/media/en/technical-documentation/data-sheets/AD7817_7818.pdf Page 9. indio_dev->name = spi_get_device_id(spi_dev)->name; indio_dev->dev.parent = _dev->dev; Also should the pin names be documented in a device tree binding doc? -- Regards Phil Reid

Re: [PATCH v2] staging: iio: ad7816: Switch to the gpio descriptor interface

upport in the id table: > static const struct spi_device_id ad7816_id[] = { >{ "ad7816", 0 }, >{ "ad7817", 0 }, >{ "ad7818", 0 }, >{} > }; See: https://www.analog.com/media/en/technical-documentation/data-sheets/AD7817_7818.pdf Page 9. indio_dev->name = spi_get_device_id(spi_dev)->name; indio_dev->dev.parent = _dev->dev; Also should the pin names be documented in a device tree binding doc? -- Regards Phil Reid

Re: [PATCH v3 3/3] iio: magnetometer: Add driver support for PNI RM3100

PNI RM3100 3-axis magnetometer spi driver"); +MODULE_LICENSE("GPL v2"); diff --git a/drivers/iio/magnetometer/rm3100.h b/drivers/iio/magnetometer/rm3100.h new file mode 100644 index ..c3508218bc77 --- /dev/null +++ b/drivers/iio/magnetometer/rm3100.h @@ -0,0 +1,17 @@ +/* SPDX-Lice

Re: [PATCH v3 3/3] iio: magnetometer: Add driver support for PNI RM3100

PNI RM3100 3-axis magnetometer spi driver"); +MODULE_LICENSE("GPL v2"); diff --git a/drivers/iio/magnetometer/rm3100.h b/drivers/iio/magnetometer/rm3100.h new file mode 100644 index ..c3508218bc77 --- /dev/null +++ b/drivers/iio/magnetometer/rm3100.h @@ -0,0 +1,17 @@ +/* SPDX-Lice

Re: [PATCH 2/2] iio: magnetometer: Add driver support for PNI RM3100

On 26/09/2018 4:09 PM, Song Qiang wrote: On Wed, Sep 26, 2018 at 10:30:34AM +0800, Phil Reid wrote: On 26/09/2018 9:49 AM, Song Qiang wrote: On Tue, Sep 25, 2018 at 10:36:54PM +0800, Phil Reid wrote: On 25/09/2018 9:30 PM, Jonathan Cameron wrote: +static irqreturn_t rm3100_trigger_handler

Re: [PATCH 2/2] iio: magnetometer: Add driver support for PNI RM3100

On 26/09/2018 4:09 PM, Song Qiang wrote: On Wed, Sep 26, 2018 at 10:30:34AM +0800, Phil Reid wrote: On 26/09/2018 9:49 AM, Song Qiang wrote: On Tue, Sep 25, 2018 at 10:36:54PM +0800, Phil Reid wrote: On 25/09/2018 9:30 PM, Jonathan Cameron wrote: +static irqreturn_t rm3100_trigger_handler

Re: [PATCH 2/2] iio: magnetometer: Add driver support for PNI RM3100

On 26/09/2018 9:49 AM, Song Qiang wrote: On Tue, Sep 25, 2018 at 10:36:54PM +0800, Phil Reid wrote: On 25/09/2018 9:30 PM, Jonathan Cameron wrote: +static irqreturn_t rm3100_trigger_handler(int irq, void *p) +{ + struct iio_poll_func *pf = p; + struct iio_dev *indio_dev = pf

Re: [PATCH 2/2] iio: magnetometer: Add driver support for PNI RM3100

On 26/09/2018 9:49 AM, Song Qiang wrote: On Tue, Sep 25, 2018 at 10:36:54PM +0800, Phil Reid wrote: On 25/09/2018 9:30 PM, Jonathan Cameron wrote: +static irqreturn_t rm3100_trigger_handler(int irq, void *p) +{ + struct iio_poll_func *pf = p; + struct iio_dev *indio_dev = pf

Re: [PATCH 2/2] iio: magnetometer: Add driver support for PNI RM3100

should be ok. But that raises the question of does it need to be? 'buffer' could be 12 bytes long and just shuffle Z then Y. Do the unused bytes need to be zeroed? or does libiio mask them anyway? -- Regards Phil Reid

Re: [PATCH 2/2] iio: magnetometer: Add driver support for PNI RM3100

should be ok. But that raises the question of does it need to be? 'buffer' could be 12 bytes long and just shuffle Z then Y. Do the unused bytes need to be zeroed? or does libiio mask them anyway? -- Regards Phil Reid

Re: [PATCH] iio: magnetometer: Add support for PNI RM3100 9-axis magnetometer

+ struct regmap *regmap; + struct completion measuring_done; + bool use_interrupt; + + int conversion_time; + + /* To protect consistency of every measurement and sampling +* frequency change operations. +*/ + struct mutex lock; +}; + +extern const struct regmap_access_table rm3100_readable_table; +extern const struct regmap_access_table rm3100_writable_table; +extern const struct regmap_access_table rm3100_volatile_table; + +int rm3100_common_probe(struct device *dev, struct regmap *regmap, int irq); +int rm3100_common_remove(struct device *dev); + +#endif /* RM3100_CORE_H */ -- Regards Phil Reid

Re: [PATCH] iio: magnetometer: Add support for PNI RM3100 9-axis magnetometer

+ struct regmap *regmap; + struct completion measuring_done; + bool use_interrupt; + + int conversion_time; + + /* To protect consistency of every measurement and sampling +* frequency change operations. +*/ + struct mutex lock; +}; + +extern const struct regmap_access_table rm3100_readable_table; +extern const struct regmap_access_table rm3100_writable_table; +extern const struct regmap_access_table rm3100_volatile_table; + +int rm3100_common_probe(struct device *dev, struct regmap *regmap, int irq); +int rm3100_common_remove(struct device *dev); + +#endif /* RM3100_CORE_H */ -- Regards Phil Reid

Re: [PATCH] iio: magnetometer: Add support for PNI RM3100 9-axis magnetometer

On 20/09/2018 9:13 PM, Song Qiang wrote: PNI RM3100 magnetometer is a high resolution, large signal immunity magnetometer, composed of 3 single sensors and a processing chip. PNI is currently not in the vendors list, so this is also adding it. In the subject: Isn't the RM3100 a 3axis mag. The

Re: [PATCH] iio: magnetometer: Add support for PNI RM3100 9-axis magnetometer

On 20/09/2018 9:13 PM, Song Qiang wrote: PNI RM3100 magnetometer is a high resolution, large signal immunity magnetometer, composed of 3 single sensors and a processing chip. PNI is currently not in the vendors list, so this is also adding it. In the subject: Isn't the RM3100 a 3axis mag. The

Re: [PATCH/RFT 1/6] i2c: designware: use open drain for recovery GPIO

pga. In other hard configurations they may have a 'proper' GPIO available that needs to be OpenDrain. Disclaimer: I have zero experience with this core, I don't know how hard it is to modify or which versions are out there. -- Regards Phil Reid

Re: [PATCH/RFT 1/6] i2c: designware: use open drain for recovery GPIO

pga. In other hard configurations they may have a 'proper' GPIO available that needs to be OpenDrain. Disclaimer: I have zero experience with this core, I don't know how hard it is to modify or which versions are out there. -- Regards Phil Reid

Re: [PATCH/RFT 1/6] i2c: designware: use open drain for recovery GPIO

On 14/07/2018 05:09, Wolfram Sang wrote: I2C is open drain, so set up the GPIO accordingly. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-designware-master.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-designware-master.c

Re: [PATCH/RFT 1/6] i2c: designware: use open drain for recovery GPIO

On 14/07/2018 05:09, Wolfram Sang wrote: I2C is open drain, so set up the GPIO accordingly. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-designware-master.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-designware-master.c

Re: [PATCH v4 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats

Signed-off-by: Brian Norris Reviewed-by: Guenter Roeck Acked-by: Rhyland Klein Reviewed-by: Phil Reid --- v2: * don't stub out POWER_SUPPLY_PROP_PRESENT from sbs_data[] * use if/else instead of switch/case v3: * pull 'return 0' out of if/else, to satisfy braindead tooling v4: * make M

Re: [PATCH v4 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats

Signed-off-by: Brian Norris Reviewed-by: Guenter Roeck Acked-by: Rhyland Klein Reviewed-by: Phil Reid --- v2: * don't stub out POWER_SUPPLY_PROP_PRESENT from sbs_data[] * use if/else instead of switch/case v3: * pull 'return 0' out of if/else, to satisfy braindead tooling v4: * make M

Re: [PATCH v3 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats

ICE_TABLE(i2c, sbs_id); static const struct of_device_id sbs_dt_ids[] = { { .compatible = "sbs,sbs-battery" }, - { .compatible = "ti,bq20z75" }, + { + .compatible = "ti,bq20z75", + .data = (void *)SBS_FLAGS_TI_BQ20Z75, + }, { } }; MODULE_DEVICE_TABLE(of, sbs_dt_ids); -- Regards Phil Reid

Re: [PATCH v3 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats

ICE_TABLE(i2c, sbs_id); static const struct of_device_id sbs_dt_ids[] = { { .compatible = "sbs,sbs-battery" }, - { .compatible = "ti,bq20z75" }, + { + .compatible = "ti,bq20z75", + .data = (void *)SBS_FLAGS_TI_BQ20Z75, + }, { } }; MODULE_DEVICE_TABLE(of, sbs_dt_ids); -- Regards Phil Reid

Re: [PATCHv6] gpio: Remove VLA from gpiolib

ted */ WARN_ON(1); + return 0; } static inline int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce) G'day Laura, Looks good to me. Reviewed-by: Phil Reid <pr...@electromag.com.au> -- Regards Phil Reid

Re: [PATCHv6] gpio: Remove VLA from gpiolib

e int gpiod_set_raw_array_value_cansleep(unsigned int array_size, struct gpio_desc **desc_array, int *value_array) { /* GPIO can never have been requested */ WARN_ON(1); + return 0; } static inline int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce) G'day Laura, Looks good to me. Reviewed-by: Phil Reid -- Regards Phil Reid

Re: [PATCHv5] gpio: Remove VLA from gpiolib

t can accommodate NR_GPIOS bits, you have to start caring about recursion (e.g. gpio-74x164 driven from spi-gpio, where I can extend the chain to increase the level of recursion arbitrarily). I think a config option for FASTPATH_NGPIO is preferable. As I've mentioned ARCH_NR_GPIOS is much greater than any chip->ngpio on my platform. It's at least one order of magnitude, almost 2. -- Regards Phil Reid

Re: [PATCHv5] gpio: Remove VLA from gpiolib

I can extend the chain to increase the level of recursion arbitrarily). I think a config option for FASTPATH_NGPIO is preferable. As I've mentioned ARCH_NR_GPIOS is much greater than any chip->ngpio on my platform. It's at least one order of magnitude, almost 2. -- Regards Phil Reid

Re: [PATCHv5] gpio: Remove VLA from gpiolib

On 16/04/2018 13:19, Phil Reid wrote: G'day Laura, One more comment. On 16/04/2018 12:41, Phil Reid wrote: G'day Laura, On 14/04/2018 05:24, Laura Abbott wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) to eventually turn on -Wvla. Using

Re: [PATCHv5] gpio: Remove VLA from gpiolib

On 16/04/2018 13:19, Phil Reid wrote: G'day Laura, One more comment. On 16/04/2018 12:41, Phil Reid wrote: G'day Laura, On 14/04/2018 05:24, Laura Abbott wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) to eventually turn on -Wvla. Using

Re: [PATCHv5] gpio: Remove VLA from gpiolib

G'day Laura, One more comment. On 16/04/2018 12:41, Phil Reid wrote: G'day Laura, On 14/04/2018 05:24, Laura Abbott wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) to eventually turn on -Wvla. Using a kmalloc array is the easy way to fix

Re: [PATCHv5] gpio: Remove VLA from gpiolib

G'day Laura, One more comment. On 16/04/2018 12:41, Phil Reid wrote: G'day Laura, On 14/04/2018 05:24, Laura Abbott wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) to eventually turn on -Wvla. Using a kmalloc array is the easy way to fix

Re: [PATCHv5] gpio: Remove VLA from gpiolib

lue_array) { /* GPIO can never have been requested */ WARN_ON(1); + return 0; } static inline int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce) -- Regards Phil Reid ElectroMagnetic Imaging Technology Pty Ltd Development of Geophysical Instrumentation & Software www.electromag.com.au 3 The Avenue, Midland WA 6056, AUSTRALIA Ph: +61 8 9250 8100 Fax: +61 8 9250 7100 Email: pr...@electromag.com.au

Re: [PATCHv5] gpio: Remove VLA from gpiolib

piod_set_raw_array_value_cansleep(unsigned int array_size, +static inline int gpiod_set_raw_array_value_cansleep(unsigned int array_size, struct gpio_desc **desc_array, int *value_array) { /* GPIO can never have been requested */ WAR

Re: [PATCHv4] gpio: Remove VLA from gpiolib

On 14/04/2018 05:10, Laura Abbott wrote: On 04/12/2018 05:39 PM, Phil Reid wrote: On 12/04/2018 16:38, Linus Walleij wrote: On Wed, Apr 11, 2018 at 3:03 AM, Laura Abbott <labb...@redhat.com> wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3

Re: [PATCHv4] gpio: Remove VLA from gpiolib

On 14/04/2018 05:10, Laura Abbott wrote: On 04/12/2018 05:39 PM, Phil Reid wrote: On 12/04/2018 16:38, Linus Walleij wrote: On Wed, Apr 11, 2018 at 3:03 AM, Laura Abbott wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) to eventually turn

Re: [PATCHv4] gpio: Remove VLA from gpiolib

't that for total GPIO's in the system? And the arrays just need to cater for max per chip? From what I can understand of the code which is admittedly limited. -- Regards Phil Reid

Re: [PATCHv4] gpio: Remove VLA from gpiolib

can understand of the code which is admittedly limited. -- Regards Phil Reid

Re: [PATCH v2] net: dsa: b53: Using sleep-able operations in b53_switch_reset_gpio

gpio, 1); - mdelay(20); + gpio_set_value_cansleep(gpio, 1); + msleep(20); dev->current_page = 0xff; } FWIW: Reviewed-by: Phil Reid <pr...@electromag.com.au>

Re: [PATCH v2] net: dsa: b53: Using sleep-able operations in b53_switch_reset_gpio

value_cansleep(gpio, 1); + msleep(20); dev->current_page = 0xff; } FWIW: Reviewed-by: Phil Reid

Re: [PATCH] net: dsa: b53: Replace mdelay with msleep in b53_switch_reset_gpio

(gpio, 0); - mdelay(50); + msleep(50); gpio_set_value(gpio, 1); - mdelay(20); + msleep(20); dev->current_page = 0xff; } Would that also imply gpio_set_value could be gpio_set_value_cansleep? -- Regards Phil Reid

Re: [PATCH] net: dsa: b53: Replace mdelay with msleep in b53_switch_reset_gpio

50); + msleep(50); gpio_set_value(gpio, 1); - mdelay(20); + msleep(20); dev->current_page = 0xff; } Would that also imply gpio_set_value could be gpio_set_value_cansleep? -- Regards Phil Reid

Re: [PATCH v3] gpio: Remove VLA from stmpe driver

e->num_gpios > MAX_GPIOS) { + dev_err(>dev, "Need to increase maximum GPIO number\n"); + return -EINVAL; + } + stmpe_gpio = kzalloc(sizeof(*stmpe_gpio), GFP_KERNEL); if (!stmpe_gpio) return -ENOMEM;

Re: [PATCH v3] gpio: Remove VLA from stmpe driver

t; MAX_GPIOS) { + dev_err(>dev, "Need to increase maximum GPIO number\n"); + return -EINVAL; + } + stmpe_gpio = kzalloc(sizeof(*stmpe_gpio), GFP_KERNEL); if (!stmpe_gpio) return -ENOMEM; FWIW Reviewed-by: Phil Reid -- Regards Phil Reid

Re: [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter

a DAC voltage to set output current is also a distinct possibility. -- Regards Phil Reid

Re: [PATCH 2/3] dt-bindings: iio: wrapper: add io-channel-unit-converter

a DAC voltage to set output current is also a distinct possibility. -- Regards Phil Reid

Re: [PATCHv2 4/4] gpio: Remove VLA from stmpe driver

On 23/03/2018 05:43, Laura Abbott wrote: On 03/18/2018 06:29 PM, Phil Reid wrote: On 16/03/2018 02:00, Laura Abbott wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) This patch replaces a VLA with an appropriate call to kmalloc_array. Signed

Re: [PATCHv2 4/4] gpio: Remove VLA from stmpe driver

On 23/03/2018 05:43, Laura Abbott wrote: On 03/18/2018 06:29 PM, Phil Reid wrote: On 16/03/2018 02:00, Laura Abbott wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) This patch replaces a VLA with an appropriate call to kmalloc_array. Signed

Re: [RESEND PATCH v1 6/6] i2c: i2c-stm32f7: Implement I2C recovery mechanism

On 12/03/2018 18:53, Pierre-Yves MORDRET wrote: Feature prevents I2C lock-ups. Mechanism resets I2C state machine and releases SCL/SDA signals but preserves I2C registers. Signed-off-by: Pierre-Yves MORDRET --- Version history: v1: * Initial --- ---

Re: [RESEND PATCH v1 6/6] i2c: i2c-stm32f7: Implement I2C recovery mechanism

On 12/03/2018 18:53, Pierre-Yves MORDRET wrote: Feature prevents I2C lock-ups. Mechanism resets I2C state machine and releases SCL/SDA signals but preserves I2C registers. Signed-off-by: Pierre-Yves MORDRET --- Version history: v1: * Initial --- ---

Re: [PATCHv2 4/4] gpio: Remove VLA from stmpe driver

nt irq, void *dev) } } + kfree(status); return IRQ_HANDLED; } -- Regards Phil Reid

Re: [PATCHv2 4/4] gpio: Remove VLA from stmpe driver

d *dev) } } + kfree(status); return IRQ_HANDLED; } -- Regards Phil Reid

Re: [PATCH 4/4] gpio: Remove VLA from stmpe driver

On 14/03/2018 09:16, Laura Abbott wrote: On 03/13/2018 05:18 PM, Laura Abbott wrote: On 03/13/2018 02:13 AM, Phil Reid wrote: On 10/03/2018 08:10, Laura Abbott wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) This patch replaces a VLA

Re: [PATCH 4/4] gpio: Remove VLA from stmpe driver

On 14/03/2018 09:16, Laura Abbott wrote: On 03/13/2018 05:18 PM, Laura Abbott wrote: On 03/13/2018 02:13 AM, Phil Reid wrote: On 10/03/2018 08:10, Laura Abbott wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) This patch replaces a VLA

Re: [PATCH 4/4] gpio: Remove VLA from stmpe driver

q, void *dev) } } + kfree(status); return IRQ_HANDLED; } Doing this in an irq handler seems wrong. Perhaps better if a buffer is pre-allocated in stmpe_gpio -- Regards Phil Reid

Re: [PATCH 4/4] gpio: Remove VLA from stmpe driver

status); return IRQ_HANDLED; } Doing this in an irq handler seems wrong. Perhaps better if a buffer is pre-allocated in stmpe_gpio -- Regards Phil Reid

Re: [PATCH 3/3] i2c: xlp9xx: Add support for SMBAlert

robe(struct platform_device *pdev) if (err) return err; + err = xlp9xx_i2c_smbus_setup(priv, pdev); + if (err) + dev_info(>dev, "No active SMBus alert %d\n", err); + platform_set_drvdata(pdev, priv); dev_dbg(>dev, "I2C bus:%d added\n", priv->adapter.nr); -- 2.1.4 -- Regards Phil Reid

Re: [PATCH 3/3] i2c: xlp9xx: Add support for SMBAlert

return err; + err = xlp9xx_i2c_smbus_setup(priv, pdev); + if (err) + dev_info(>dev, "No active SMBus alert %d\n", err); + platform_set_drvdata(pdev, priv); dev_dbg(>dev, "I2C bus:%d added\n", priv->adapter.nr); -- 2.1.4 -- Regards Phil Reid

Re: [PATCH v2] iio:dummy: Replace S_IWUSR by 0200

on it in great detail, but isn't there a more specific macro that doesn't need a permission argument at all? Probably thinking of IIO_DEVICE_ATTR_RO / IIO_DEVICE_ATTR_WO But they don't provide flexibility for the show / store method. -- Regards Phil Reid

Re: [PATCH v2] iio:dummy: Replace S_IWUSR by 0200

on it in great detail, but isn't there a more specific macro that doesn't need a permission argument at all? Probably thinking of IIO_DEVICE_ATTR_RO / IIO_DEVICE_ATTR_WO But they don't provide flexibility for the show / store method. -- Regards Phil Reid

Re: [PATCH 0/2] net: dsa: lan9303: check error value from devm_gpiod_get_optional()

On 7/01/2018 00:54, Egil Hjelmeland wrote: Den 13. nov. 2017 09:07, skrev Phil Reid: Replaces Pan Bian <bianpan2...@163.com> patch "net: dsa: lan9303: correctly check return value of devm_gpiod_get_optional" Errors need to be prograted back from probe. Note: I have onl

Re: [PATCH 0/2] net: dsa: lan9303: check error value from devm_gpiod_get_optional()

On 7/01/2018 00:54, Egil Hjelmeland wrote: Den 13. nov. 2017 09:07, skrev Phil Reid: Replaces Pan Bian patch "net: dsa: lan9303: correctly check return value of devm_gpiod_get_optional" Errors need to be prograted back from probe. Note: I have only compile tested the code as I

Re: [PATCH] pinctrl: mcp23s08: fix irq setup order

e of ordering for irq setup and devm_gpiochip_add_data() calls. But should probably go into stable if it is the fix. -- Regards Phil Reid

Re: [PATCH] pinctrl: mcp23s08: fix irq setup order

ta() calls. But should probably go into stable if it is the fix. -- Regards Phil Reid

Re: [PATCH v4] iio : Add cm3218 smbus ara and acpi support

On 25/11/2017 21:57, Jonathan Cameron wrote: On Tue, 21 Nov 2017 09:22:16 +0800 Phil Reid <pr...@electromag.com.au> wrote: On 20/11/2017 18:57, Mika Westerberg wrote: +Jarkko On Sun, Nov 19, 2017 at 04:35:51PM +, Jonathan Cameron wrote: On Thu, 2 Nov 2017 16:04:07 +0100 Wolfram S

Re: [PATCH v4] iio : Add cm3218 smbus ara and acpi support

On 25/11/2017 21:57, Jonathan Cameron wrote: On Tue, 21 Nov 2017 09:22:16 +0800 Phil Reid wrote: On 20/11/2017 18:57, Mika Westerberg wrote: +Jarkko On Sun, Nov 19, 2017 at 04:35:51PM +, Jonathan Cameron wrote: On Thu, 2 Nov 2017 16:04:07 +0100 Wolfram Sang wrote: On Thu, Nov 02

Re: [PATCH v4] iio : Add cm3218 smbus ara and acpi support

8 driver doesn't appear to be using the alert callback in strcut i2c_driver. So the smbus_alert driver is not going to notifiy the cm3218 driver. Are there more than one alert/ara capable devices on the bus? Perhaps a workaround in this case is if that acpi entry is defined the cm3218 driver handles tha

Re: [PATCH v4] iio : Add cm3218 smbus ara and acpi support

e cm3218 driver. Are there more than one alert/ara capable devices on the bus? Perhaps a workaround in this case is if that acpi entry is defined the cm3218 driver handles that ara request directly to clear the interrupt. -- Regards Phil Reid

[PATCH 2/2] net: dsa: lan9303: check error value from devm_gpiod_get_optional()

devm_gpiod_get_optional() can return an error in addition to a NULL ptr. Check for error and propagate that to the probe function. Check return value in probe. This will now handle EPROBE_DEFER for the reset gpio. Signed-off-by: Phil Reid <pr...@electromag.com.au> --- drivers/net/dsa/l

[PATCH 2/2] net: dsa: lan9303: check error value from devm_gpiod_get_optional()

devm_gpiod_get_optional() can return an error in addition to a NULL ptr. Check for error and propagate that to the probe function. Check return value in probe. This will now handle EPROBE_DEFER for the reset gpio. Signed-off-by: Phil Reid --- drivers/net/dsa/lan9303-core.c | 13 ++--- 1

[PATCH 1/2] net: dsa: lan9303: make lan9303_handle_reset() a void function

lan9303_handle_reset never returns anything other than success. So there's not need for it to return an error code. Signed-off-by: Phil Reid <pr...@electromag.com.au> --- drivers/net/dsa/lan9303-core.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/n

[PATCH 1/2] net: dsa: lan9303: make lan9303_handle_reset() a void function

lan9303_handle_reset never returns anything other than success. So there's not need for it to return an error code. Signed-off-by: Phil Reid --- drivers/net/dsa/lan9303-core.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/net/dsa/lan9303-core.c b/drivers

[PATCH 0/2] net: dsa: lan9303: check error value from devm_gpiod_get_optional()

Replaces Pan Bian <bianpan2...@163.com> patch "net: dsa: lan9303: correctly check return value of devm_gpiod_get_optional" Errors need to be prograted back from probe. Note: I have only compile tested the code as I don't have the hardware. Phil Reid (2): net: ds

[PATCH 0/2] net: dsa: lan9303: check error value from devm_gpiod_get_optional()

Replaces Pan Bian patch "net: dsa: lan9303: correctly check return value of devm_gpiod_get_optional" Errors need to be prograted back from probe. Note: I have only compile tested the code as I don't have the hardware. Phil Reid (2): net: dsa: lan9303: make lan9303_handle_rese

Re: [PATCH] net: dsa: lan9303: correctly check return value of devm_gpiod_get_optional

) always returns 0. lan9303_probe checks lan9303_handle_reset() return value. Probably should be checking lan9303_probe_reset_gpio() instead. -- Regards Phil Reid

Re: [PATCH] net: dsa: lan9303: correctly check return value of devm_gpiod_get_optional

ecks lan9303_handle_reset() return value. Probably should be checking lan9303_probe_reset_gpio() instead. -- Regards Phil Reid

Re: [PATCH v4] iio : Add cm3218 smbus ara and acpi support

ith smbalert support https://www.spinics.net/lists/devicetree/msg191947.html Cleans up the smbus_alert driver a bit. note: alert_edge_triggered was removed. And for OF systems core creates the ara device. -- Regards Phil Reid

Re: [PATCH v4] iio : Add cm3218 smbus ara and acpi support

/msg191947.html Cleans up the smbus_alert driver a bit. note: alert_edge_triggered was removed. And for OF systems core creates the ara device. -- Regards Phil Reid

Re: [PATCH] i2c-designware: add i2c gpio recovery option

ull I don't know what the intents are, so don't know if its a "bug" or by design. -- Regards Phil Reid

Re: [PATCH] i2c-designware: add i2c gpio recovery option

ull I don't know what the intents are, so don't know if its a "bug" or by design. -- Regards Phil Reid

Re: [PATCH] i2c-designware: add i2c gpio recovery option

G'day Andy, Thanks for the review. On 10/05/2017 21:13, Andy Shevchenko wrote: On Wed, 2017-05-10 at 13:57 +0200, Tim Sander wrote: This patch contains much input from Phil Reid and has been tested on Intel/Altera Cyclone V SOC Hardware with Altera GPIO's for the SCL and SDA GPIO's. I am

Re: [PATCH] i2c-designware: add i2c gpio recovery option

G'day Andy, Thanks for the review. On 10/05/2017 21:13, Andy Shevchenko wrote: On Wed, 2017-05-10 at 13:57 +0200, Tim Sander wrote: This patch contains much input from Phil Reid and has been tested on Intel/Altera Cyclone V SOC Hardware with Altera GPIO's for the SCL and SDA GPIO's. I am

Re: RFC: i2c designware gpio recovery

could be done in i2c_init_recovery to allow: rinfo->recover_bus == i2c_generic_scl_recovery when scl_gpio is also set and fallback to using the core set / get scl / sda calls Which would remove the need for the above i2c_dw_* functions. I wouldn't think that would cause any p

Re: RFC: i2c designware gpio recovery

could be done in i2c_init_recovery to allow: rinfo->recover_bus == i2c_generic_scl_recovery when scl_gpio is also set and fallback to using the core set / get scl / sda calls Which would remove the need for the above i2c_dw_* functions. I wouldn't think that would cause any p

  1   2   >