June 2021 - Linux-stable-mirror

patch "iio: light: tcs3472: do not free unallocated IRQ" added to staging-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: light: tcs3472: do not free unallocated IRQ to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 7cd04c863f9e1655d607705455e7714f24451984 Mon Sep 17 00:00:00 2001 From: frank zago <frank(a)zago.net> Date: Mon, 26 Apr 2021 21:20:17 -0500 Subject: iio: light: tcs3472: do not free unallocated IRQ Allocating an IRQ is conditional to the IRQ existence, but freeing it was not. If no IRQ was allocate, the driver would still try to free IRQ 0. Add the missing checks. This fixes the following trace when the driver is removed: [ 100.667788] Trying to free already-free IRQ 0 [ 100.667793] WARNING: CPU: 0 PID: 2315 at kernel/irq/manage.c:1826 free_irq+0x1fd/0x370 ... [ 100.667914] Call Trace: [ 100.667920] tcs3472_remove+0x3a/0x90 [tcs3472] [ 100.667927] i2c_device_remove+0x2b/0xa0 Signed-off-by: frank zago <frank(a)zago.net> Link: https://lore.kernel.org/r/20210427022017.19314-2-frank@zago.net Fixes: 9d2f715d592e ("iio: light: tcs3472: support out-of-threshold events") Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/light/tcs3472.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/iio/light/tcs3472.c b/drivers/iio/light/tcs3472.c index 90dc3fef59e6..371c6a39a165 100644 --- a/drivers/iio/light/tcs3472.c +++ b/drivers/iio/light/tcs3472.c @@ -535,7 +535,8 @@ static int tcs3472_probe(struct i2c_client *client, return 0; free_irq: - free_irq(client->irq, indio_dev); + if (client->irq) + free_irq(client->irq, indio_dev); buffer_cleanup: iio_triggered_buffer_cleanup(indio_dev); return ret; @@ -563,7 +564,8 @@ static int tcs3472_remove(struct i2c_client *client) struct iio_dev *indio_dev = i2c_get_clientdata(client); iio_device_unregister(indio_dev); - free_irq(client->irq, indio_dev); + if (client->irq) + free_irq(client->irq, indio_dev); iio_triggered_buffer_cleanup(indio_dev); tcs3472_powerdown(iio_priv(indio_dev)); -- 2.32.0

3 years, 4 months

1
0
0 0

patch "iio: ltr501: ltr501_read_ps(): add missing endianness conversion" added to staging-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: ltr501: ltr501_read_ps(): add missing endianness conversion to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 71b33f6f93ef9462c84560e2236ed22209d26a58 Mon Sep 17 00:00:00 2001 From: Oliver Lang <Oliver.Lang(a)gossenmetrawatt.com> Date: Thu, 10 Jun 2021 15:46:18 +0200 Subject: iio: ltr501: ltr501_read_ps(): add missing endianness conversion The PS ADC Channel data is spread over 2 registers in little-endian form. This patch adds the missing endianness conversion. Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver") Signed-off-by: Oliver Lang <Oliver.Lang(a)gossenmetrawatt.com> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Tested-by: Nikita Travkin <nikita(a)trvn.ru> # ltr559 Link: https://lore.kernel.org/r/20210610134619.2101372-4-mkl@pengutronix.de Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/light/ltr501.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c index 79898b72fe73..74ed2d88a3ed 100644 --- a/drivers/iio/light/ltr501.c +++ b/drivers/iio/light/ltr501.c @@ -409,18 +409,19 @@ static int ltr501_read_als(const struct ltr501_data *data, __le16 buf[2]) static int ltr501_read_ps(const struct ltr501_data *data) { - int ret, status; + __le16 status; + int ret; ret = ltr501_drdy(data, LTR501_STATUS_PS_RDY); if (ret < 0) return ret; ret = regmap_bulk_read(data->regmap, LTR501_PS_DATA, - &status, 2); + &status, sizeof(status)); if (ret < 0) return ret; - return status; + return le16_to_cpu(status); } static int ltr501_read_intr_prst(const struct ltr501_data *data, -- 2.32.0

3 years, 4 months

1
0
0 0

patch "iio: ltr501: mark register holding upper 8 bits of ALS_DATA{0, 1} and" added to staging-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: ltr501: mark register holding upper 8 bits of ALS_DATA{0,1} and to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 2ac0b029a04b673ce83b5089368f467c5dca720c Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde <mkl(a)pengutronix.de> Date: Thu, 10 Jun 2021 15:46:16 +0200 Subject: iio: ltr501: mark register holding upper 8 bits of ALS_DATA{0,1} and PS_DATA as volatile, too The regmap is configured for 8 bit registers, uses a RB-Tree cache and marks several registers as volatile (i.e. do not cache). The ALS and PS data registers in the chip are 16 bit wide and spans two regmap registers. In the current driver only the base register is marked as volatile, resulting in the upper register only read once. Further the data sheet notes: | When the I2C read operation starts, all four ALS data registers are | locked until the I2C read operation of register 0x8B is completed. Which results in the registers never update after the 2nd read. This patch fixes the problem by marking the upper 8 bits of the ALS and PS registers as volatile, too. Fixes: 2f2c96338afc ("iio: ltr501: Add regmap support.") Reported-by: Oliver Lang <Oliver.Lang(a)gossenmetrawatt.com> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Tested-by: Nikita Travkin <nikita(a)trvn.ru> # ltr559 Link: https://lore.kernel.org/r/20210610134619.2101372-2-mkl@pengutronix.de Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/light/ltr501.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c index b4323d2db0b1..0ed3392a33cf 100644 --- a/drivers/iio/light/ltr501.c +++ b/drivers/iio/light/ltr501.c @@ -32,9 +32,12 @@ #define LTR501_PART_ID 0x86 #define LTR501_MANUFAC_ID 0x87 #define LTR501_ALS_DATA1 0x88 /* 16-bit, little endian */ +#define LTR501_ALS_DATA1_UPPER 0x89 /* upper 8 bits of LTR501_ALS_DATA1 */ #define LTR501_ALS_DATA0 0x8a /* 16-bit, little endian */ +#define LTR501_ALS_DATA0_UPPER 0x8b /* upper 8 bits of LTR501_ALS_DATA0 */ #define LTR501_ALS_PS_STATUS 0x8c #define LTR501_PS_DATA 0x8d /* 16-bit, little endian */ +#define LTR501_PS_DATA_UPPER 0x8e /* upper 8 bits of LTR501_PS_DATA */ #define LTR501_INTR 0x8f /* output mode, polarity, mode */ #define LTR501_PS_THRESH_UP 0x90 /* 11 bit, ps upper threshold */ #define LTR501_PS_THRESH_LOW 0x92 /* 11 bit, ps lower threshold */ @@ -1354,9 +1357,12 @@ static bool ltr501_is_volatile_reg(struct device *dev, unsigned int reg) { switch (reg) { case LTR501_ALS_DATA1: + case LTR501_ALS_DATA1_UPPER: case LTR501_ALS_DATA0: + case LTR501_ALS_DATA0_UPPER: case LTR501_ALS_PS_STATUS: case LTR501_PS_DATA: + case LTR501_PS_DATA_UPPER: return true; default: return false; -- 2.32.0

3 years, 4 months

1
0
0 0

patch "iio: ltr501: ltr559: fix initialization of LTR501_ALS_CONTR" added to staging-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: ltr501: ltr559: fix initialization of LTR501_ALS_CONTR to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 421a26f3d7a7c3ca43f3a9dc0f3cb0f562d5bd95 Mon Sep 17 00:00:00 2001 From: Oliver Lang <Oliver.Lang(a)gossenmetrawatt.com> Date: Thu, 10 Jun 2021 15:46:17 +0200 Subject: iio: ltr501: ltr559: fix initialization of LTR501_ALS_CONTR The ltr559 chip uses only the lowest bit of the ALS_CONTR register to configure between active and stand-by mode. In the original driver BIT(1) is used, which does a software reset instead. This patch fixes the problem by using BIT(0) as als_mode_active for the ltr559 chip. Fixes: 8592a7eefa54 ("iio: ltr501: Add support for ltr559 chip") Signed-off-by: Oliver Lang <Oliver.Lang(a)gossenmetrawatt.com> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Tested-by: Nikita Travkin <nikita(a)trvn.ru> # ltr559 Link: https://lore.kernel.org/r/20210610134619.2101372-3-mkl@pengutronix.de Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/light/ltr501.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c index 0ed3392a33cf..79898b72fe73 100644 --- a/drivers/iio/light/ltr501.c +++ b/drivers/iio/light/ltr501.c @@ -1208,7 +1208,7 @@ static struct ltr501_chip_info ltr501_chip_info_tbl[] = { .als_gain_tbl_size = ARRAY_SIZE(ltr559_als_gain_tbl), .ps_gain = ltr559_ps_gain_tbl, .ps_gain_tbl_size = ARRAY_SIZE(ltr559_ps_gain_tbl), - .als_mode_active = BIT(1), + .als_mode_active = BIT(0), .als_gain_mask = BIT(2) | BIT(3) | BIT(4), .als_gain_shift = 2, .info = &ltr501_info, -- 2.32.0

3 years, 4 months

1
0
0 0

patch "iio: accel: bmc150: Fix bma222 scale unit" added to staging-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: accel: bmc150: Fix bma222 scale unit to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 6e2a90af0b8d757e850cc023d761ee9a9492e2fe Mon Sep 17 00:00:00 2001 From: Stephan Gerhold <stephan(a)gerhold.net> Date: Fri, 11 Jun 2021 10:08:54 +0200 Subject: iio: accel: bmc150: Fix bma222 scale unit According to sysfs-bus-iio documentation the unit for accelerometer values after applying scale/offset should be m/s^2, not g, which explains why the scale values for the other variants in bmc150-accel do not match exactly the values given in the datasheet. To get the correct values, we need to multiply the BMA222 scale values by g = 9.80665 m/s^2. Fixes: a1a210bf29a1 ("iio: accel: bmc150-accel: Add support for BMA222") Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Stephan Gerhold <stephan(a)gerhold.net> Link: https://lore.kernel.org/r/20210611080903.14384-2-stephan@gerhold.net Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/accel/bmc150-accel-core.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c index a3d08d713362..a80ee0fdabc5 100644 --- a/drivers/iio/accel/bmc150-accel-core.c +++ b/drivers/iio/accel/bmc150-accel-core.c @@ -1145,11 +1145,12 @@ static const struct bmc150_accel_chip_info bmc150_accel_chip_info_tbl[] = { /* * The datasheet page 17 says: * 15.6, 31.3, 62.5 and 125 mg per LSB. + * IIO unit is m/s^2 so multiply by g = 9.80665 m/s^2. */ - .scale_table = { {156000, BMC150_ACCEL_DEF_RANGE_2G}, - {313000, BMC150_ACCEL_DEF_RANGE_4G}, - {625000, BMC150_ACCEL_DEF_RANGE_8G}, - {1250000, BMC150_ACCEL_DEF_RANGE_16G} }, + .scale_table = { {152984, BMC150_ACCEL_DEF_RANGE_2G}, + {306948, BMC150_ACCEL_DEF_RANGE_4G}, + {612916, BMC150_ACCEL_DEF_RANGE_8G}, + {1225831, BMC150_ACCEL_DEF_RANGE_16G} }, }, [bma222e] = { .name = "BMA222E", -- 2.32.0

3 years, 4 months

1
0
0 0

patch "iio: accel: bma180: Fix BMA25x bandwidth register values" added to staging-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: accel: bma180: Fix BMA25x bandwidth register values to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 8090d67421ddab0ae932abab5a60200598bf0bbb Mon Sep 17 00:00:00 2001 From: Stephan Gerhold <stephan(a)gerhold.net> Date: Wed, 26 May 2021 11:44:07 +0200 Subject: iio: accel: bma180: Fix BMA25x bandwidth register values MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit According to the BMA253 datasheet [1] and BMA250 datasheet [2] the bandwidth value for BMA25x should be set as 01xxx: "Settings 00xxx result in a bandwidth of 7.81 Hz; [...] It is recommended [...] to use the range from ´01000b´ to ´01111b´ only in order to be compatible with future products." However, at the moment the drivers sets bandwidth values from 0 to 6, which is not recommended and always results into 7.81 Hz bandwidth according to the datasheet. Fix this by introducing a bw_offset = 8 = 01000b for BMA25x, so the additional bit is always set for BMA25x. [1]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/b… [2]: https://datasheet.octopart.com/BMA250-Bosch-datasheet-15540103.pdf Cc: Peter Meerwald <pmeerw(a)pmeerw.net> Fixes: 2017cff24cc0 ("iio:bma180: Add BMA250 chip support") Signed-off-by: Stephan Gerhold <stephan(a)gerhold.net> Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Link: https://lore.kernel.org/r/20210526094408.34298-2-stephan@gerhold.net Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/accel/bma180.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c index 4a07e60c0e21..e7c6b3096cb7 100644 --- a/drivers/iio/accel/bma180.c +++ b/drivers/iio/accel/bma180.c @@ -55,7 +55,7 @@ struct bma180_part_info { u8 int_reset_reg, int_reset_mask; u8 sleep_reg, sleep_mask; - u8 bw_reg, bw_mask; + u8 bw_reg, bw_mask, bw_offset; u8 scale_reg, scale_mask; u8 power_reg, power_mask, lowpower_val; u8 int_enable_reg, int_enable_mask; @@ -127,6 +127,7 @@ struct bma180_part_info { #define BMA250_RANGE_MASK GENMASK(3, 0) /* Range of accel values */ #define BMA250_BW_MASK GENMASK(4, 0) /* Accel bandwidth */ +#define BMA250_BW_OFFSET 8 #define BMA250_SUSPEND_MASK BIT(7) /* chip will sleep */ #define BMA250_LOWPOWER_MASK BIT(6) #define BMA250_DATA_INTEN_MASK BIT(4) @@ -143,6 +144,7 @@ struct bma180_part_info { #define BMA254_RANGE_MASK GENMASK(3, 0) /* Range of accel values */ #define BMA254_BW_MASK GENMASK(4, 0) /* Accel bandwidth */ +#define BMA254_BW_OFFSET 8 #define BMA254_SUSPEND_MASK BIT(7) /* chip will sleep */ #define BMA254_LOWPOWER_MASK BIT(6) #define BMA254_DATA_INTEN_MASK BIT(4) @@ -287,7 +289,8 @@ static int bma180_set_bw(struct bma180_data *data, int val) for (i = 0; i < data->part_info->num_bw; ++i) { if (data->part_info->bw_table[i] == val) { ret = bma180_set_bits(data, data->part_info->bw_reg, - data->part_info->bw_mask, i); + data->part_info->bw_mask, + i + data->part_info->bw_offset); if (ret) { dev_err(&data->client->dev, "failed to set bandwidth\n"); @@ -880,6 +883,7 @@ static const struct bma180_part_info bma180_part_info[] = { .sleep_mask = BMA250_SUSPEND_MASK, .bw_reg = BMA250_BW_REG, .bw_mask = BMA250_BW_MASK, + .bw_offset = BMA250_BW_OFFSET, .scale_reg = BMA250_RANGE_REG, .scale_mask = BMA250_RANGE_MASK, .power_reg = BMA250_POWER_REG, @@ -909,6 +913,7 @@ static const struct bma180_part_info bma180_part_info[] = { .sleep_mask = BMA254_SUSPEND_MASK, .bw_reg = BMA254_BW_REG, .bw_mask = BMA254_BW_MASK, + .bw_offset = BMA254_BW_OFFSET, .scale_reg = BMA254_RANGE_REG, .scale_mask = BMA254_RANGE_MASK, .power_reg = BMA254_POWER_REG, -- 2.32.0

3 years, 4 months

1
0
0 0

patch "iio: frequency: adf4350: disable reg and clk on error in" added to staging-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: frequency: adf4350: disable reg and clk on error in to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From c8cc4cf60b000fb9f4b29bed131fb6cf1fe42d67 Mon Sep 17 00:00:00 2001 From: Yang Yingliang <yangyingliang(a)huawei.com> Date: Tue, 1 Jun 2021 22:26:05 +0800 Subject: iio: frequency: adf4350: disable reg and clk on error in adf4350_probe() Disable reg and clk when devm_gpiod_get_optional() fails in adf4350_probe(). Fixes:4a89d2f47ccd ("iio: adf4350: Convert to use GPIO descriptor") Reported-by: Hulk Robot <hulkci(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Link: https://lore.kernel.org/r/20210601142605.3613605-1-yangyingliang@huawei.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/frequency/adf4350.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/iio/frequency/adf4350.c b/drivers/iio/frequency/adf4350.c index 1462a6a5bc6d..3d9eba716b69 100644 --- a/drivers/iio/frequency/adf4350.c +++ b/drivers/iio/frequency/adf4350.c @@ -563,8 +563,10 @@ static int adf4350_probe(struct spi_device *spi) st->lock_detect_gpiod = devm_gpiod_get_optional(&spi->dev, NULL, GPIOD_IN); - if (IS_ERR(st->lock_detect_gpiod)) - return PTR_ERR(st->lock_detect_gpiod); + if (IS_ERR(st->lock_detect_gpiod)) { + ret = PTR_ERR(st->lock_detect_gpiod); + goto error_disable_reg; + } if (pdata->power_up_frequency) { ret = adf4350_set_freq(st, pdata->power_up_frequency); -- 2.32.0

3 years, 4 months

1
0
0 0

patch "iio: accel: bmc150: Don't make the remove function of the second" added to staging-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: accel: bmc150: Don't make the remove function of the second to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From f407e2dca0f559621114eeaf657880d83f237fbd Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sun, 23 May 2021 19:00:56 +0200 Subject: iio: accel: bmc150: Don't make the remove function of the second accelerometer unregister itself On machines with dual accelerometers described in a single ACPI fwnode, the bmc150_accel_probe() instantiates a second i2c-client for the second accelerometer. A pointer to this manually instantiated second i2c-client is stored inside the iio_dev's private-data through bmc150_set_second_device(), so that the i2c-client can be unregistered from bmc150_accel_remove(). Before this commit bmc150_set_second_device() took only 1 argument so it would store the pointer in private-data of the iio_dev belonging to the manually instantiated i2c-client, leading to the bmc150_accel_remove() call for the second_dev trying to unregister *itself* while it was being removed, leading to a deadlock and rmmod hanging. Change bmc150_set_second_device() to take 2 arguments: 1. The i2c-client which is instantiating the second i2c-client for the 2nd accelerometer and 2. The second-device pointer itself (which also is an i2c-client). This will store the second_device pointer in the private data of the iio_dev belonging to the (ACPI instantiated) i2c-client for the first accelerometer and will make bmc150_accel_remove() unregister the second_device i2c-client when called for the first client, avoiding the deadlock. Fixes: 5bfb3a4bd8f6 ("iio: accel: bmc150: Check for a second ACPI device for BOSC0200") Cc: Jeremy Cline <jeremy(a)jcline.org> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/accel/bmc150-accel-core.c | 4 ++-- drivers/iio/accel/bmc150-accel-i2c.c | 2 +- drivers/iio/accel/bmc150-accel.h | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c index c526d83f14d5..1aec873bee03 100644 --- a/drivers/iio/accel/bmc150-accel-core.c +++ b/drivers/iio/accel/bmc150-accel-core.c @@ -1811,11 +1811,11 @@ struct i2c_client *bmc150_get_second_device(struct i2c_client *client) } EXPORT_SYMBOL_GPL(bmc150_get_second_device); -void bmc150_set_second_device(struct i2c_client *client) +void bmc150_set_second_device(struct i2c_client *client, struct i2c_client *second_dev) { struct bmc150_accel_data *data = iio_priv(i2c_get_clientdata(client)); - data->second_device = client; + data->second_device = second_dev; } EXPORT_SYMBOL_GPL(bmc150_set_second_device); diff --git a/drivers/iio/accel/bmc150-accel-i2c.c b/drivers/iio/accel/bmc150-accel-i2c.c index 69f709319484..2afaae0294ee 100644 --- a/drivers/iio/accel/bmc150-accel-i2c.c +++ b/drivers/iio/accel/bmc150-accel-i2c.c @@ -70,7 +70,7 @@ static int bmc150_accel_probe(struct i2c_client *client, second_dev = i2c_acpi_new_device(&client->dev, 1, &board_info); if (!IS_ERR(second_dev)) - bmc150_set_second_device(second_dev); + bmc150_set_second_device(client, second_dev); } #endif diff --git a/drivers/iio/accel/bmc150-accel.h b/drivers/iio/accel/bmc150-accel.h index 6024f15b9700..e30c1698f6fb 100644 --- a/drivers/iio/accel/bmc150-accel.h +++ b/drivers/iio/accel/bmc150-accel.h @@ -18,7 +18,7 @@ int bmc150_accel_core_probe(struct device *dev, struct regmap *regmap, int irq, const char *name, bool block_supported); int bmc150_accel_core_remove(struct device *dev); struct i2c_client *bmc150_get_second_device(struct i2c_client *second_device); -void bmc150_set_second_device(struct i2c_client *second_device); +void bmc150_set_second_device(struct i2c_client *client, struct i2c_client *second_dev); extern const struct dev_pm_ops bmc150_accel_pm_ops; extern const struct regmap_config bmc150_regmap_conf; -- 2.32.0

3 years, 4 months

1
0
0 0

patch "iio: accel: bmc150: Fix dereferencing the wrong pointer in" added to staging-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: accel: bmc150: Fix dereferencing the wrong pointer in to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From f2bf22dc9ea8ead180fc0221874bd556bf1d2685 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sun, 23 May 2021 19:00:55 +0200 Subject: iio: accel: bmc150: Fix dereferencing the wrong pointer in bmc150_get/set_second_device The drvdata for iio-parent devices points to the struct iio_dev for the iio-device. So by directly casting the return from i2c_get_clientdata() to struct bmc150_accel_data * the code was ending up storing the second_dev pointer in (and retrieving it from) some semi-random offset inside struct iio_dev, rather then storing it in the second_dev member of the bmc150_accel_data struct. Fix the code to get the struct bmc150_accel_data * pointer to call iio_priv() on the struct iio_dev * returned by i2c_get_clientdata(), so that the correct pointer gets dereferenced. This fixes the following oops on rmmod, caused by trying to dereference the wrong return of bmc150_get_second_device(): [ 238.980737] BUG: unable to handle page fault for address: 0000000000004710 [ 238.980755] #PF: supervisor read access in kernel mode [ 238.980760] #PF: error_code(0x0000) - not-present page ... [ 238.980841] i2c_unregister_device.part.0+0x19/0x60 [ 238.980856] 0xffffffffc0815016 [ 238.980863] i2c_device_remove+0x25/0xb0 [ 238.980869] __device_release_driver+0x180/0x240 [ 238.980876] driver_detach+0xd4/0x120 [ 238.980882] bus_remove_driver+0x5b/0xd0 [ 238.980888] i2c_del_driver+0x44/0x70 While at it also remove the now no longer sensible checks for data being NULL, iio_priv never returns NULL for an iio_dev with non 0 sized private-data. Fixes: 5bfb3a4bd8f6 ("iio: accel: bmc150: Check for a second ACPI device for BOSC0200") Cc: Jeremy Cline <jeremy(a)jcline.org> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/accel/bmc150-accel-core.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c index 46ab7675186c..c526d83f14d5 100644 --- a/drivers/iio/accel/bmc150-accel-core.c +++ b/drivers/iio/accel/bmc150-accel-core.c @@ -1805,10 +1805,7 @@ EXPORT_SYMBOL_GPL(bmc150_accel_core_probe); struct i2c_client *bmc150_get_second_device(struct i2c_client *client) { - struct bmc150_accel_data *data = i2c_get_clientdata(client); - - if (!data) - return NULL; + struct bmc150_accel_data *data = iio_priv(i2c_get_clientdata(client)); return data->second_device; } @@ -1816,10 +1813,9 @@ EXPORT_SYMBOL_GPL(bmc150_get_second_device); void bmc150_set_second_device(struct i2c_client *client) { - struct bmc150_accel_data *data = i2c_get_clientdata(client); + struct bmc150_accel_data *data = iio_priv(i2c_get_clientdata(client)); - if (data) - data->second_device = client; + data->second_device = client; } EXPORT_SYMBOL_GPL(bmc150_set_second_device); -- 2.32.0

3 years, 4 months

1
0
0 0

patch "usb: typec: Add the missed altmode_id_remove() in" added to usb-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: typec: Add the missed altmode_id_remove() in to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 03026197bb657d784220b040c6173267a0375741 Mon Sep 17 00:00:00 2001 From: Jing Xiangfeng <jingxiangfeng(a)huawei.com> Date: Thu, 17 Jun 2021 15:32:26 +0800 Subject: usb: typec: Add the missed altmode_id_remove() in typec_register_altmode() typec_register_altmode() misses to call altmode_id_remove() in an error path. Add the missed function call to fix it. Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes") Cc: stable <stable(a)vger.kernel.org> Acked-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Signed-off-by: Jing Xiangfeng <jingxiangfeng(a)huawei.com> Link: https://lore.kernel.org/r/20210617073226.47599-1-jingxiangfeng@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/typec/class.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c index b9429c9f65f6..aeef453aa658 100644 --- a/drivers/usb/typec/class.c +++ b/drivers/usb/typec/class.c @@ -517,8 +517,10 @@ typec_register_altmode(struct device *parent, int ret; alt = kzalloc(sizeof(*alt), GFP_KERNEL); - if (!alt) + if (!alt) { + altmode_id_remove(parent, id); return ERR_PTR(-ENOMEM); + } alt->adev.svid = desc->svid; alt->adev.mode = desc->mode; -- 2.32.0

3 years, 4 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2021