From 7b5309ee9421c8019a191b83c39ba65a02848042 Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Sun, 5 Jul 2020 23:38:58 -0400 Subject: [PATCH] Fixes for 4.4 Signed-off-by: Sasha Levin --- ..._meter-fix-potential-memory-leak-in-.patch | 47 +++++++++++++ ...ke-sure-the-overt-mask-is-set-correc.patch | 67 +++++++++++++++++++ ...-0x78-as-scl-stuck-low-status-for-pc.patch | 43 ++++++++++++ queue-4.4/series | 4 ++ ...vblk-vqs-in-error-path-of-virtblk_pr.patch | 36 ++++++++++ 5 files changed, 197 insertions(+) create mode 100644 queue-4.4/hwmon-acpi_power_meter-fix-potential-memory-leak-in-.patch create mode 100644 queue-4.4/hwmon-max6697-make-sure-the-overt-mask-is-set-correc.patch create mode 100644 queue-4.4/i2c-algo-pca-add-0x78-as-scl-stuck-low-status-for-pc.patch create mode 100644 queue-4.4/virtio-blk-free-vblk-vqs-in-error-path-of-virtblk_pr.patch diff --git a/queue-4.4/hwmon-acpi_power_meter-fix-potential-memory-leak-in-.patch b/queue-4.4/hwmon-acpi_power_meter-fix-potential-memory-leak-in-.patch new file mode 100644 index 00000000000..bc5e507c04b --- /dev/null +++ b/queue-4.4/hwmon-acpi_power_meter-fix-potential-memory-leak-in-.patch @@ -0,0 +1,47 @@ +From a6fb92e500bed170bb4e0717f4da58e6d7b1ae22 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 25 Jun 2020 13:32:42 +0900 +Subject: hwmon: (acpi_power_meter) Fix potential memory leak in + acpi_power_meter_add() + +From: Misono Tomohiro + +[ Upstream commit 8b97f9922211c44a739c5cbd9502ecbb9f17f6d1 ] + +Although it rarely happens, we should call free_capabilities() +if error happens after read_capabilities() to free allocated strings. + +Fixes: de584afa5e188 ("hwmon driver for ACPI 4.0 power meters") +Signed-off-by: Misono Tomohiro +Link: https://lore.kernel.org/r/20200625043242.31175-1-misono.tomohiro@jp.fujitsu.com +Signed-off-by: Guenter Roeck +Signed-off-by: Sasha Levin +--- + drivers/hwmon/acpi_power_meter.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/drivers/hwmon/acpi_power_meter.c b/drivers/hwmon/acpi_power_meter.c +index e27f7e12c05bb..9b4ad6c74041e 100644 +--- a/drivers/hwmon/acpi_power_meter.c ++++ b/drivers/hwmon/acpi_power_meter.c +@@ -895,7 +895,7 @@ static int acpi_power_meter_add(struct acpi_device *device) + + res = setup_attrs(resource); + if (res) +- goto exit_free; ++ goto exit_free_capability; + + resource->hwmon_dev = hwmon_device_register(&device->dev); + if (IS_ERR(resource->hwmon_dev)) { +@@ -908,6 +908,8 @@ static int acpi_power_meter_add(struct acpi_device *device) + + exit_remove: + remove_attrs(resource); ++exit_free_capability: ++ free_capabilities(resource); + exit_free: + kfree(resource); + exit: +-- +2.25.1 + diff --git a/queue-4.4/hwmon-max6697-make-sure-the-overt-mask-is-set-correc.patch b/queue-4.4/hwmon-max6697-make-sure-the-overt-mask-is-set-correc.patch new file mode 100644 index 00000000000..1be11b76570 --- /dev/null +++ b/queue-4.4/hwmon-max6697-make-sure-the-overt-mask-is-set-correc.patch @@ -0,0 +1,67 @@ +From cb28e64f2b783fb7bd4c39ba233379f2db112f53 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 23 Jun 2020 22:13:08 +0000 +Subject: hwmon: (max6697) Make sure the OVERT mask is set correctly + +From: Chu Lin + +[ Upstream commit 016983d138cbe99a5c0aaae0103ee88f5300beb3 ] + +Per the datasheet for max6697, OVERT mask and ALERT mask are different. +For example, the 7th bit of OVERT is the local channel but for alert +mask, the 6th bit is the local channel. Therefore, we can't apply the +same mask for both registers. In addition to that, the max6697 driver +is supposed to be compatibale with different models. I manually went over +all the listed chips and made sure all chip types have the same layout. + +Testing; + mask value of 0x9 should map to 0x44 for ALERT and 0x84 for OVERT. + I used iotool to read the reg value back to verify. I only tested this + change on max6581. + +Reference: +https://datasheets.maximintegrated.com/en/ds/MAX6581.pdf +https://datasheets.maximintegrated.com/en/ds/MAX6697.pdf +https://datasheets.maximintegrated.com/en/ds/MAX6699.pdf + +Signed-off-by: Chu Lin +Fixes: 5372d2d71c46e ("hwmon: Driver for Maxim MAX6697 and compatibles") +Signed-off-by: Guenter Roeck +Signed-off-by: Sasha Levin +--- + drivers/hwmon/max6697.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +diff --git a/drivers/hwmon/max6697.c b/drivers/hwmon/max6697.c +index f03a71722849a..d4bb3d6aaf18c 100644 +--- a/drivers/hwmon/max6697.c ++++ b/drivers/hwmon/max6697.c +@@ -46,8 +46,9 @@ static const u8 MAX6697_REG_CRIT[] = { + * Map device tree / platform data register bit map to chip bit map. + * Applies to alert register and over-temperature register. + */ +-#define MAX6697_MAP_BITS(reg) ((((reg) & 0x7e) >> 1) | \ ++#define MAX6697_ALERT_MAP_BITS(reg) ((((reg) & 0x7e) >> 1) | \ + (((reg) & 0x01) << 6) | ((reg) & 0x80)) ++#define MAX6697_OVERT_MAP_BITS(reg) (((reg) >> 1) | (((reg) & 0x01) << 7)) + + #define MAX6697_REG_STAT(n) (0x44 + (n)) + +@@ -586,12 +587,12 @@ static int max6697_init_chip(struct max6697_data *data, + return ret; + + ret = i2c_smbus_write_byte_data(client, MAX6697_REG_ALERT_MASK, +- MAX6697_MAP_BITS(pdata->alert_mask)); ++ MAX6697_ALERT_MAP_BITS(pdata->alert_mask)); + if (ret < 0) + return ret; + + ret = i2c_smbus_write_byte_data(client, MAX6697_REG_OVERT_MASK, +- MAX6697_MAP_BITS(pdata->over_temperature_mask)); ++ MAX6697_OVERT_MAP_BITS(pdata->over_temperature_mask)); + if (ret < 0) + return ret; + +-- +2.25.1 + diff --git a/queue-4.4/i2c-algo-pca-add-0x78-as-scl-stuck-low-status-for-pc.patch b/queue-4.4/i2c-algo-pca-add-0x78-as-scl-stuck-low-status-for-pc.patch new file mode 100644 index 00000000000..ceb1a199d4a --- /dev/null +++ b/queue-4.4/i2c-algo-pca-add-0x78-as-scl-stuck-low-status-for-pc.patch @@ -0,0 +1,43 @@ +From 7a436f4d9497b14cee3d39654a6abba35926b1fd Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 2 Jul 2020 10:39:11 +1200 +Subject: i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665 + +From: Chris Packham + +[ Upstream commit cd217f2300793a106b49c7dfcbfb26e348bc7593 ] + +The PCA9665 datasheet says that I2CSTA = 78h indicates that SCL is stuck +low, this differs to the PCA9564 which uses 90h for this indication. +Treat either 0x78 or 0x90 as an indication that the SCL line is stuck. + +Based on looking through the PCA9564 and PCA9665 datasheets this should +be safe for both chips. The PCA9564 should not return 0x78 for any valid +state and the PCA9665 should not return 0x90. + +Fixes: eff9ec95efaa ("i2c-algo-pca: Add PCA9665 support") +Signed-off-by: Chris Packham +Reviewed-by: Andy Shevchenko +Signed-off-by: Wolfram Sang +Signed-off-by: Sasha Levin +--- + drivers/i2c/algos/i2c-algo-pca.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/i2c/algos/i2c-algo-pca.c b/drivers/i2c/algos/i2c-algo-pca.c +index e370804ec8bc6..3a9db4626cb60 100644 +--- a/drivers/i2c/algos/i2c-algo-pca.c ++++ b/drivers/i2c/algos/i2c-algo-pca.c +@@ -326,7 +326,8 @@ static int pca_xfer(struct i2c_adapter *i2c_adap, + DEB2("BUS ERROR - SDA Stuck low\n"); + pca_reset(adap); + goto out; +- case 0x90: /* Bus error - SCL stuck low */ ++ case 0x78: /* Bus error - SCL stuck low (PCA9665) */ ++ case 0x90: /* Bus error - SCL stuck low (PCA9564) */ + DEB2("BUS ERROR - SCL Stuck low\n"); + pca_reset(adap); + goto out; +-- +2.25.1 + diff --git a/queue-4.4/series b/queue-4.4/series index 021b454d24e..6fd097b34c8 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -8,3 +8,7 @@ kgdb-avoid-suspicious-rcu-usage-warning.patch tpm_tis-remove-the-hid-ifx0102.patch crypto-af_alg-fix-use-after-free-in-af_alg_accept-due-to-bh_lock_sock.patch sched-rt-show-the-sched_rr_timeslice-sched_rr-timesl.patch +hwmon-max6697-make-sure-the-overt-mask-is-set-correc.patch +hwmon-acpi_power_meter-fix-potential-memory-leak-in-.patch +virtio-blk-free-vblk-vqs-in-error-path-of-virtblk_pr.patch +i2c-algo-pca-add-0x78-as-scl-stuck-low-status-for-pc.patch diff --git a/queue-4.4/virtio-blk-free-vblk-vqs-in-error-path-of-virtblk_pr.patch b/queue-4.4/virtio-blk-free-vblk-vqs-in-error-path-of-virtblk_pr.patch new file mode 100644 index 00000000000..f38c8acaa98 --- /dev/null +++ b/queue-4.4/virtio-blk-free-vblk-vqs-in-error-path-of-virtblk_pr.patch @@ -0,0 +1,36 @@ +From 6d3e9ccc8817f46d67bfe253a1341e7a8ecf5d44 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 15 Jun 2020 12:14:59 +0800 +Subject: virtio-blk: free vblk-vqs in error path of virtblk_probe() + +From: Hou Tao + +[ Upstream commit e7eea44eefbdd5f0345a0a8b80a3ca1c21030d06 ] + +Else there will be memory leak if alloc_disk() fails. + +Fixes: 6a27b656fc02 ("block: virtio-blk: support multi virt queues per virtio-blk device") +Signed-off-by: Hou Tao +Reviewed-by: Stefano Garzarella +Reviewed-by: Ming Lei +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + drivers/block/virtio_blk.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c +index 1e5cd39d0cc2f..bdc3efacd0d25 100644 +--- a/drivers/block/virtio_blk.c ++++ b/drivers/block/virtio_blk.c +@@ -757,6 +757,7 @@ static int virtblk_probe(struct virtio_device *vdev) + put_disk(vblk->disk); + out_free_vq: + vdev->config->del_vqs(vdev); ++ kfree(vblk->vqs); + out_free_vblk: + kfree(vblk); + out_free_index: +-- +2.25.1 + -- 2.47.3