--- /dev/null
+From a6fb92e500bed170bb4e0717f4da58e6d7b1ae22 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <misono.tomohiro@jp.fujitsu.com>
+
+[ 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 <misono.tomohiro@jp.fujitsu.com>
+Link: https://lore.kernel.org/r/20200625043242.31175-1-misono.tomohiro@jp.fujitsu.com
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From cb28e64f2b783fb7bd4c39ba233379f2db112f53 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 23 Jun 2020 22:13:08 +0000
+Subject: hwmon: (max6697) Make sure the OVERT mask is set correctly
+
+From: Chu Lin <linchuyuan@google.com>
+
+[ 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 <linchuyuan@google.com>
+Fixes: 5372d2d71c46e ("hwmon: Driver for Maxim MAX6697 and compatibles")
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 7a436f4d9497b14cee3d39654a6abba35926b1fd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <chris.packham@alliedtelesis.co.nz>
+
+[ 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 <chris.packham@alliedtelesis.co.nz>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
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
--- /dev/null
+From 6d3e9ccc8817f46d67bfe253a1341e7a8ecf5d44 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 15 Jun 2020 12:14:59 +0800
+Subject: virtio-blk: free vblk-vqs in error path of virtblk_probe()
+
+From: Hou Tao <houtao1@huawei.com>
+
+[ 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 <houtao1@huawei.com>
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
+Reviewed-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
