--- /dev/null
+From b93dfa6bda4d4e88e5386490f2b277a26958f9d3 Mon Sep 17 00:00:00 2001
+From: Dan Williams <dan.j.williams@intel.com>
+Date: Wed, 11 Aug 2021 11:53:37 -0700
+Subject: ACPI: NFIT: Fix support for virtual SPA ranges
+
+From: Dan Williams <dan.j.williams@intel.com>
+
+commit b93dfa6bda4d4e88e5386490f2b277a26958f9d3 upstream.
+
+Fix the NFIT parsing code to treat a 0 index in a SPA Range Structure as
+a special case and not match Region Mapping Structures that use 0 to
+indicate that they are not mapped. Without this fix some platform BIOS
+descriptions of "virtual disk" ranges do not result in the pmem driver
+attaching to the range.
+
+Details:
+In addition to typical persistent memory ranges, the ACPI NFIT may also
+convey "virtual" ranges. These ranges are indicated by a UUID in the SPA
+Range Structure of UUID_VOLATILE_VIRTUAL_DISK, UUID_VOLATILE_VIRTUAL_CD,
+UUID_PERSISTENT_VIRTUAL_DISK, or UUID_PERSISTENT_VIRTUAL_CD. The
+critical difference between virtual ranges and UUID_PERSISTENT_MEMORY,
+is that virtual do not support associations with Region Mapping
+Structures. For this reason the "index" value of virtual SPA Range
+Structures is allowed to be 0. If a platform BIOS decides to represent
+NVDIMMs with disconnected "Region Mapping Structures" (range-index ==
+0), the kernel may falsely associate them with standalone ranges where
+the "SPA Range Structure Index" is also zero. When this happens the
+driver may falsely require labels where "virtual disks" are expected to
+be label-less. I.e. "label-less" is where the namespace-range ==
+region-range and the pmem driver attaches with no user action to create
+a namespace.
+
+Cc: Jacek Zloch <jacek.zloch@intel.com>
+Cc: Lukasz Sobieraj <lukasz.sobieraj@intel.com>
+Cc: "Lee, Chun-Yi" <jlee@suse.com>
+Cc: <stable@vger.kernel.org>
+Fixes: c2f32acdf848 ("acpi, nfit: treat virtual ramdisk SPA as pmem region")
+Reported-by: Krzysztof Rusocki <krzysztof.rusocki@intel.com>
+Reported-by: Damian Bassa <damian.bassa@intel.com>
+Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
+Link: https://lore.kernel.org/r/162870796589.2521182.1240403310175570220.stgit@dwillia2-desk3.amr.corp.intel.com
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/nfit/core.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/acpi/nfit/core.c
++++ b/drivers/acpi/nfit/core.c
+@@ -2834,6 +2834,9 @@ static int acpi_nfit_register_region(str
+ struct acpi_nfit_memory_map *memdev = nfit_memdev->memdev;
+ struct nd_mapping_desc *mapping;
+
++ /* range index 0 == unmapped in SPA or invalid-SPA */
++ if (memdev->range_index == 0 || spa->range_index == 0)
++ continue;
+ if (memdev->range_index != spa->range_index)
+ continue;
+ if (count >= ND_MAX_MAPPINGS) {
--- /dev/null
+From 2e6b836312a477d647a7920b56810a5a25f6c856 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 28 Jul 2021 13:23:50 +0200
+Subject: ASoC: intel: atom: Fix reference to PCM buffer address
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 2e6b836312a477d647a7920b56810a5a25f6c856 upstream.
+
+PCM buffers might be allocated dynamically when the buffer
+preallocation failed or a larger buffer is requested, and it's not
+guaranteed that substream->dma_buffer points to the actually used
+buffer. The address should be retrieved from runtime->dma_addr,
+instead of substream->dma_buffer (and shouldn't use virt_to_phys).
+
+Also, remove the line overriding runtime->dma_area superfluously,
+which was already set up at the PCM buffer allocation.
+
+Cc: Cezary Rojewski <cezary.rojewski@intel.com>
+Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://lore.kernel.org/r/20210728112353.6675-3-tiwai@suse.de
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/intel/atom/sst-mfld-platform-pcm.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
++++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
+@@ -135,7 +135,7 @@ static void sst_fill_alloc_params(struct
+ snd_pcm_uframes_t period_size;
+ ssize_t periodbytes;
+ ssize_t buffer_bytes = snd_pcm_lib_buffer_bytes(substream);
+- u32 buffer_addr = virt_to_phys(substream->dma_buffer.area);
++ u32 buffer_addr = substream->runtime->dma_addr;
+
+ channels = substream->runtime->channels;
+ period_size = substream->runtime->period_size;
+@@ -241,7 +241,6 @@ static int sst_platform_alloc_stream(str
+ /* set codec params and inform SST driver the same */
+ sst_fill_pcm_params(substream, ¶m);
+ sst_fill_alloc_params(substream, &alloc_params);
+- substream->runtime->dma_area = substream->dma_buffer.area;
+ str_params.sparams = param;
+ str_params.aparams = alloc_params;
+ str_params.codec = SST_CODEC_TYPE_PCM;
--- /dev/null
+From 86ff25ed6cd8240d18df58930bd8848b19fce308 Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Thu, 29 Jul 2021 16:35:32 +0200
+Subject: i2c: dev: zero out array used for i2c reads from userspace
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit 86ff25ed6cd8240d18df58930bd8848b19fce308 upstream.
+
+If an i2c driver happens to not provide the full amount of data that a
+user asks for, it is possible that some uninitialized data could be sent
+to userspace. While all in-kernel drivers look to be safe, just be sure
+by initializing the buffer to zero before it is passed to the i2c driver
+so that any future drivers will not have this issue.
+
+Also properly copy the amount of data recvieved to the userspace buffer,
+as pointed out by Dan Carpenter.
+
+Reported-by: Eric Dumazet <edumazet@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/i2c-dev.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/i2c/i2c-dev.c
++++ b/drivers/i2c/i2c-dev.c
+@@ -149,7 +149,7 @@ static ssize_t i2cdev_read(struct file *
+ if (count > 8192)
+ count = 8192;
+
+- tmp = kmalloc(count, GFP_KERNEL);
++ tmp = kzalloc(count, GFP_KERNEL);
+ if (tmp == NULL)
+ return -ENOMEM;
+
+@@ -158,7 +158,8 @@ static ssize_t i2cdev_read(struct file *
+
+ ret = i2c_master_recv(client, tmp, count);
+ if (ret >= 0)
+- ret = copy_to_user(buf, tmp, count) ? -EFAULT : ret;
++ if (copy_to_user(buf, tmp, ret))
++ ret = -EFAULT;
+ kfree(tmp);
+ return ret;
+ }
--- /dev/null
+From 5afc1540f13804a31bb704b763308e17688369c5 Mon Sep 17 00:00:00 2001
+From: Colin Ian King <colin.king@canonical.com>
+Date: Fri, 30 Jul 2021 08:16:51 +0100
+Subject: iio: adc: Fix incorrect exit of for-loop
+
+From: Colin Ian King <colin.king@canonical.com>
+
+commit 5afc1540f13804a31bb704b763308e17688369c5 upstream.
+
+Currently the for-loop that scans for the optimial adc_period iterates
+through all the possible adc_period levels because the exit logic in
+the loop is inverted. I believe the comparison should be swapped and
+the continue replaced with a break to exit the loop at the correct
+point.
+
+Addresses-Coverity: ("Continue has no effect")
+Fixes: e08e19c331fb ("iio:adc: add iio driver for Palmas (twl6035/7) gpadc")
+Signed-off-by: Colin Ian King <colin.king@canonical.com>
+Link: https://lore.kernel.org/r/20210730071651.17394-1-colin.king@canonical.com
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/palmas_gpadc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/adc/palmas_gpadc.c
++++ b/drivers/iio/adc/palmas_gpadc.c
+@@ -659,8 +659,8 @@ static int palmas_adc_wakeup_configure(s
+
+ adc_period = adc->auto_conversion_period;
+ for (i = 0; i < 16; ++i) {
+- if (((1000 * (1 << i)) / 32) < adc_period)
+- continue;
++ if (((1000 * (1 << i)) / 32) >= adc_period)
++ break;
+ }
+ if (i > 0)
+ i--;
--- /dev/null
+From 84edec86f449adea9ee0b4912a79ab8d9d65abb7 Mon Sep 17 00:00:00 2001
+From: Chris Lesiak <chris.lesiak@licor.com>
+Date: Mon, 14 Jun 2021 09:18:20 -0500
+Subject: iio: humidity: hdc100x: Add margin to the conversion time
+
+From: Chris Lesiak <chris.lesiak@licor.com>
+
+commit 84edec86f449adea9ee0b4912a79ab8d9d65abb7 upstream.
+
+The datasheets have the following note for the conversion time
+specification: "This parameter is specified by design and/or
+characterization and it is not tested in production."
+
+Parts have been seen that require more time to do 14-bit conversions for
+the relative humidity channel. The result is ENXIO due to the address
+phase of a transfer not getting an ACK.
+
+Delay an additional 1 ms per conversion to allow for additional margin.
+
+Fixes: 4839367d99e3 ("iio: humidity: add HDC100x support")
+Signed-off-by: Chris Lesiak <chris.lesiak@licor.com>
+Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
+Link: https://lore.kernel.org/r/20210614141820.2034827-1-chris.lesiak@licor.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/humidity/hdc100x.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/humidity/hdc100x.c
++++ b/drivers/iio/humidity/hdc100x.c
+@@ -24,6 +24,8 @@
+ #include <linux/iio/trigger_consumer.h>
+ #include <linux/iio/triggered_buffer.h>
+
++#include <linux/time.h>
++
+ #define HDC100X_REG_TEMP 0x00
+ #define HDC100X_REG_HUMIDITY 0x01
+
+@@ -165,7 +167,7 @@ static int hdc100x_get_measurement(struc
+ struct iio_chan_spec const *chan)
+ {
+ struct i2c_client *client = data->client;
+- int delay = data->adc_int_us[chan->address];
++ int delay = data->adc_int_us[chan->address] + 1*USEC_PER_MSEC;
+ int ret;
+ __be16 val;
+
+@@ -322,7 +324,7 @@ static irqreturn_t hdc100x_trigger_handl
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct hdc100x_data *data = iio_priv(indio_dev);
+ struct i2c_client *client = data->client;
+- int delay = data->adc_int_us[0] + data->adc_int_us[1];
++ int delay = data->adc_int_us[0] + data->adc_int_us[1] + 2*USEC_PER_MSEC;
+ int ret;
+
+ /* dual read starts at temp register */
--- /dev/null
+iio-humidity-hdc100x-add-margin-to-the-conversion-time.patch
+iio-adc-fix-incorrect-exit-of-for-loop.patch
+asoc-intel-atom-fix-reference-to-pcm-buffer-address.patch
+i2c-dev-zero-out-array-used-for-i2c-reads-from-userspace.patch
+acpi-nfit-fix-support-for-virtual-spa-ranges.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
