June 2021 - Linux-stable-mirror

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

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-testing 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 be merged to the staging-next branch sometime soon, after it passes testing, and the merge window is open. 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-testing

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-testing 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 be merged to the staging-next branch sometime soon, after it passes testing, and the merge window is open. 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-testing

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-testing 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 be merged to the staging-next branch sometime soon, after it passes testing, and the merge window is open. 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-testing

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-testing 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 be merged to the staging-next branch sometime soon, after it passes testing, and the merge window is open. 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-testing

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-testing 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 be merged to the staging-next branch sometime soon, after it passes testing, and the merge window is open. 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-testing

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-testing 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 be merged to the staging-next branch sometime soon, after it passes testing, and the merge window is open. 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-testing

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-testing 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 be merged to the staging-next branch sometime soon, after it passes testing, and the merge window is open. 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-testing

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-testing 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 be merged to the staging-next branch sometime soon, after it passes testing, and the merge window is open. 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 4/4] xhci: solve a double free problem while doing s4

by Mathias Nyman

From: "Zhangjiantao (Kirin, nanjing)" <water.zhangjiantao(a)huawei.com> when system is doing s4, the process of xhci_resume may be as below: 1、xhci_mem_cleanup 2、xhci_init->xhci_mem_init->xhci_mem_cleanup(when memory is not enough). xhci_mem_cleanup will be executed twice when system is out of memory. xhci->port_caps is freed in xhci_mem_cleanup,but it isn't set to NULL. It will be freed twice when xhci_mem_cleanup is called the second time. We got following bug when system resumes from s4: kernel BUG at mm/slub.c:309! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP CPU: 0 PID: 5929 Tainted: G S W 5.4.96-arm64-desktop #1 pc : __slab_free+0x5c/0x424 lr : kfree+0x30c/0x32c Call trace: __slab_free+0x5c/0x424 kfree+0x30c/0x32c xhci_mem_cleanup+0x394/0x3cc xhci_mem_init+0x9ac/0x1070 xhci_init+0x8c/0x1d0 xhci_resume+0x1cc/0x5fc xhci_plat_resume+0x64/0x70 platform_pm_thaw+0x28/0x60 dpm_run_callback+0x54/0x24c device_resume+0xd0/0x200 async_resume+0x24/0x60 async_run_entry_fn+0x44/0x110 process_one_work+0x1f0/0x490 worker_thread+0x5c/0x450 kthread+0x158/0x160 ret_from_fork+0x10/0x24 Original patch that caused this issue was backported to 4.4 stable, so this should be backported to 4.4 stabe as well. Fixes: cf0ee7c60c89 ("xhci: Fix memory leak when caching protocol extended capability PSI tables - take 2") Cc: stable(a)vger.kernel.org # v4.4+ Signed-off-by: Jiantao Zhang <water.zhangjiantao(a)huawei.com> Signed-off-by: Tao Xue <xuetao09(a)huawei.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-mem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index 2f6da35e7977..0e312066c5c6 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -1924,6 +1924,7 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci) xhci->hw_ports = NULL; xhci->rh_bw = NULL; xhci->ext_caps = NULL; + xhci->port_caps = NULL; xhci->page_size = 0; xhci->page_shift = 0; -- 2.25.1

3 years, 4 months

1
0
0 0

[PATCH] ext4: return error code when ext4_fill_flex_info() fails

by Yang Yingliang

I got a null-ptr-deref when doing fuzz test: [ 148.490559] EXT4-fs (loop0): not enough memory for 1 flex group pointers [ 148.491529] EXT4-fs (loop0): unable to initialize flex_bg meta info! [ 148.492759] EXT4-fs (loop0): mount failed [ 148.495070] general protection fault, probably for non-canonical address 0xdffffc000000001c: 0000 [#1] SMP KASAN PTI [ 148.496560] KASAN: null-ptr-deref in range [0x00000000000000e0-0x00000000000000e7] [ 148.497611] CPU: 1 PID: 2575 Comm: mount Tainted: G W 5.13.0-rc1 #109 [ 148.498687] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 148.499968] RIP: 0010:legacy_get_tree+0x12d/0x200 [ 148.500651] Code: 66 02 48 89 c5 48 3d 00 f0 ff ff 77 73 e8 9b 1f c5 ff 48 8d bd e0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 bd 00 00 00 48 83 bd e0 00 00 00 00 74 49 e8 6a [ 148.503325] RSP: 0018:ffff88810bfe7d00 EFLAGS: 00010202 [ 148.504159] RAX: dffffc0000000000 RBX: ffff88810d44d800 RCX: ffffffff8999b945 [ 148.505271] RDX: 000000000000001c RSI: 0000000000000000 RDI: 00000000000000e0 [ 148.506469] RBP: 0000000000000000 R08: 0000000000000001 R09: fffffbfff1d1ab98 [ 148.507592] R10: 0000000000000001 R11: fffffbfff1d1ab97 R12: ffff88811490c480 [ 148.508820] R13: ffffffff89c30260 R14: ffff888100f14260 R15: ffff88810d44d800 [ 148.510160] FS: 00007fe977c1d080(0000) GS:ffff88811ae80000(0000) knlGS:0000000000000000 [ 148.511678] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 148.512773] CR2: 000055b8ff4ec018 CR3: 000000010d24a005 CR4: 0000000000770ee0 [ 148.514078] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 148.515374] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 148.516678] PKRU: 55555554 [ 148.517231] Call Trace: [ 148.517665] vfs_get_tree+0x8c/0x2d0 [ 148.518383] path_mount+0x4bf/0x19d0 [ 148.519058] ? finish_automount+0x850/0x850 [ 148.519821] ? getname_flags+0x232/0x560 [ 148.520587] do_mount+0xe8/0x100 [ 148.521180] ? path_mount+0x19d0/0x19d0 [ 148.521875] ? _copy_from_user+0xcb/0x110 [ 148.522602] ? memdup_user+0x68/0xa0 [ 148.523261] __x64_sys_mount+0x19c/0x1e0 [ 148.524028] do_syscall_64+0x3c/0x80 [ 148.524685] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 148.525646] RIP: 0033:0x7fe9774dd3ca [ 148.526325] Code: 48 8b 0d c1 8a 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8e 8a 2c 00 f7 d8 64 89 01 48 [ 148.529779] RSP: 002b:00007fff2fbf37b8 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 [ 148.531225] RAX: ffffffffffffffda RBX: 000055b8ff4dca50 RCX: 00007fe9774dd3ca [ 148.532595] RDX: 000055b8ff4e59b0 RSI: 000055b8ff4dcc90 RDI: 000055b8ff4e5990 [ 148.533907] RBP: 0000000000000000 R08: 0000000000000000 R09: 000055b8ff4dcc50 [ 148.535204] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 000055b8ff4e5990 [ 148.536496] R13: 000055b8ff4e59b0 R14: 0000000000000000 R15: 00007fe9779fe8a4 [ 148.537755] Modules linked in: [ 148.538366] Dumping ftrace buffer: [ 148.539002] (ftrace buffer empty) [ 148.539861] ---[ end trace 4e7a13bbcda00a47 ]--- After commit c89128a00838 ("ext4: handle errors on ext4_commit_super"), 'ret' may be set to 0 before calling ext4_fill_flex_info(), if ext4_fill_flex_info() fails ext4_mount() doesn't return error code, it makes 'root' is null which causes crash in legacy_get_tree(). Fixes: c89128a00838 ("ext4: handle errors on ext4_commit_super") Reported-by: Hulk Robot <hulkci(a)huawei.com> Cc: <stable(a)vger.kernel.org> # v4.18+ Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- fs/ext4/super.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 7dc94f3e18e6..6cb76a44b184 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -5052,6 +5052,7 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) ext4_msg(sb, KERN_ERR, "unable to initialize " "flex_bg meta info!"); + ret = -ENOMEM; goto failed_mount6; } -- 2.25.1

3 years, 4 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2021