--- /dev/null
+From c0dd5e136332962a909d69d6eb413dd275eafd6e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 30 Sep 2019 14:45:22 -0700
+Subject: firmware: google: increment VPD key_len properly
+
+From: Brian Norris <briannorris@chromium.org>
+
+[ Upstream commit 442f1e746e8187b9deb1590176f6b0ff19686b11 ]
+
+Commit 4b708b7b1a2c ("firmware: google: check if size is valid when
+decoding VPD data") adds length checks, but the new vpd_decode_entry()
+function botched the logic -- it adds the key length twice, instead of
+adding the key and value lengths separately.
+
+On my local system, this means vpd.c's vpd_section_create_attribs() hits
+an error case after the first attribute it parses, since it's no longer
+looking at the correct offset. With this patch, I'm back to seeing all
+the correct attributes in /sys/firmware/vpd/...
+
+Fixes: 4b708b7b1a2c ("firmware: google: check if size is valid when decoding VPD data")
+Cc: <stable@vger.kernel.org>
+Cc: Hung-Te Lin <hungte@chromium.org>
+Signed-off-by: Brian Norris <briannorris@chromium.org>
+Reviewed-by: Stephen Boyd <swboyd@chromium.org>
+Reviewed-by: Guenter Roeck <groeck@chromium.org>
+Link: https://lore.kernel.org/r/20190930214522.240680-1-briannorris@chromium.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/firmware/google/vpd_decode.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/firmware/google/vpd_decode.c b/drivers/firmware/google/vpd_decode.c
+index e75abe9fa122c..6c7ab2ba85d2f 100644
+--- a/drivers/firmware/google/vpd_decode.c
++++ b/drivers/firmware/google/vpd_decode.c
+@@ -62,7 +62,7 @@ static int vpd_decode_entry(const u32 max_len, const u8 *input_buf,
+ if (max_len - consumed < *entry_len)
+ return VPD_FAIL;
+
+- consumed += decoded_len;
++ consumed += *entry_len;
+ *_consumed = consumed;
+ return VPD_OK;
+ }
+--
+2.20.1
+
--- /dev/null
+From 38c62fcef2ce06129c39be503dc83ada2ce1f979 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Oct 2019 18:10:24 +0200
+Subject: gpiolib: don't clear FLAG_IS_OUT when emulating
+ open-drain/open-source
+
+From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+
+[ Upstream commit e735244e2cf068f98b6384681a38993e0517a838 ]
+
+When emulating open-drain/open-source by not actively driving the output
+lines - we're simply changing their mode to input. This is wrong as it
+will then make it impossible to change the value of such line - it's now
+considered to actually be in input mode. If we want to still use the
+direction_input() callback for simplicity then we need to set FLAG_IS_OUT
+manually in gpiod_direction_output() and not clear it in
+gpio_set_open_drain_value_commit() and
+gpio_set_open_source_value_commit().
+
+Fixes: c663e5f56737 ("gpio: support native single-ended hardware drivers")
+Cc: stable@vger.kernel.org
+Reported-by: Kent Gibson <warthog618@gmail.com>
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+[Bartosz: backported to v4.14]
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpio/gpiolib.c | 27 +++++++++++++++++++--------
+ 1 file changed, 19 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
+index f1809a54fceeb..c7f5f0be2d749 100644
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -2329,8 +2329,10 @@ static int _gpiod_direction_output_raw(struct gpio_desc *desc, int value)
+ if (!ret)
+ goto set_output_value;
+ /* Emulate open drain by not actively driving the line high */
+- if (val)
+- return gpiod_direction_input(desc);
++ if (val) {
++ ret = gpiod_direction_input(desc);
++ goto set_output_flag;
++ }
+ }
+ else if (test_bit(FLAG_OPEN_SOURCE, &desc->flags)) {
+ ret = gpio_set_drive_single_ended(gc, gpio_chip_hwgpio(desc),
+@@ -2338,8 +2340,10 @@ static int _gpiod_direction_output_raw(struct gpio_desc *desc, int value)
+ if (!ret)
+ goto set_output_value;
+ /* Emulate open source by not actively driving the line low */
+- if (!val)
+- return gpiod_direction_input(desc);
++ if (!val) {
++ ret = gpiod_direction_input(desc);
++ goto set_output_flag;
++ }
+ } else {
+ gpio_set_drive_single_ended(gc, gpio_chip_hwgpio(desc),
+ PIN_CONFIG_DRIVE_PUSH_PULL);
+@@ -2359,6 +2363,17 @@ static int _gpiod_direction_output_raw(struct gpio_desc *desc, int value)
+ trace_gpio_value(desc_to_gpio(desc), 0, val);
+ trace_gpio_direction(desc_to_gpio(desc), 0, ret);
+ return ret;
++
++set_output_flag:
++ /*
++ * When emulating open-source or open-drain functionalities by not
++ * actively driving the line (setting mode to input) we still need to
++ * set the IS_OUT flag or otherwise we won't be able to set the line
++ * value anymore.
++ */
++ if (ret == 0)
++ set_bit(FLAG_IS_OUT, &desc->flags);
++ return ret;
+ }
+
+ /**
+@@ -2540,8 +2555,6 @@ static void _gpio_set_open_drain_value(struct gpio_desc *desc, bool value)
+
+ if (value) {
+ err = chip->direction_input(chip, offset);
+- if (!err)
+- clear_bit(FLAG_IS_OUT, &desc->flags);
+ } else {
+ err = chip->direction_output(chip, offset, 0);
+ if (!err)
+@@ -2571,8 +2584,6 @@ static void _gpio_set_open_source_value(struct gpio_desc *desc, bool value)
+ set_bit(FLAG_IS_OUT, &desc->flags);
+ } else {
+ err = chip->direction_input(chip, offset);
+- if (!err)
+- clear_bit(FLAG_IS_OUT, &desc->flags);
+ }
+ trace_gpio_direction(desc_to_gpio(desc), !value, err);
+ if (err < 0)
+--
+2.20.1
+
--- /dev/null
+From 5ecb5d2020567ae790d8f13669686b0e171173ee Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 9 Sep 2019 14:37:21 +0200
+Subject: iio: adc: hx711: fix bug in sampling of data
+
+From: Andreas Klinger <ak@it-klinger.de>
+
+[ Upstream commit 4043ecfb5fc4355a090111e14faf7945ff0fdbd5 ]
+
+Fix bug in sampling function hx711_cycle() when interrupt occures while
+PD_SCK is high. If PD_SCK is high for at least 60 us power down mode of
+the sensor is entered which in turn leads to a wrong measurement.
+
+Switch off interrupts during a PD_SCK high period and move query of DOUT
+to the latest point of time which is at the end of PD_SCK low period.
+
+This bug exists in the driver since it's initial addition. The more
+interrupts on the system the higher is the probability that it happens.
+
+Fixes: c3b2fdd0ea7e ("iio: adc: hx711: Add IIO driver for AVIA HX711")
+Signed-off-by: Andreas Klinger <ak@it-klinger.de>
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/iio/adc/hx711.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
+index 8eb3f1bbe332b..0dec733471d56 100644
+--- a/drivers/iio/adc/hx711.c
++++ b/drivers/iio/adc/hx711.c
+@@ -101,14 +101,14 @@ struct hx711_data {
+
+ static int hx711_cycle(struct hx711_data *hx711_data)
+ {
+- int val;
++ unsigned long flags;
+
+ /*
+ * if preempted for more then 60us while PD_SCK is high:
+ * hx711 is going in reset
+ * ==> measuring is false
+ */
+- preempt_disable();
++ local_irq_save(flags);
+ gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
+
+ /*
+@@ -118,7 +118,6 @@ static int hx711_cycle(struct hx711_data *hx711_data)
+ */
+ ndelay(hx711_data->data_ready_delay_ns);
+
+- val = gpiod_get_value(hx711_data->gpiod_dout);
+ /*
+ * here we are not waiting for 0.2 us as suggested by the datasheet,
+ * because the oscilloscope showed in a test scenario
+@@ -126,7 +125,7 @@ static int hx711_cycle(struct hx711_data *hx711_data)
+ * and 0.56 us for PD_SCK low on TI Sitara with 800 MHz
+ */
+ gpiod_set_value(hx711_data->gpiod_pd_sck, 0);
+- preempt_enable();
++ local_irq_restore(flags);
+
+ /*
+ * make it a square wave for addressing cases with capacitance on
+@@ -134,7 +133,8 @@ static int hx711_cycle(struct hx711_data *hx711_data)
+ */
+ ndelay(hx711_data->data_ready_delay_ns);
+
+- return val;
++ /* sample as late as possible */
++ return gpiod_get_value(hx711_data->gpiod_dout);
+ }
+
+ static int hx711_read(struct hx711_data *hx711_data)
+--
+2.20.1
+
--- /dev/null
+From 3f8f6437a4c87e9243bafa8272a8d548097d304b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Jul 2018 20:19:03 +0200
+Subject: iio: hx711: add delay until DOUT is ready
+
+From: Andreas Klinger <ak@it-klinger.de>
+
+[ Upstream commit 461631face58054c72b1f1453f2d66d71b1974e7 ]
+
+On a system with parasitic capacitance it turned out that DOUT is not ready
+after 100 ns after PD_SCK has raised. A measurement showed almost 1000 ns
+until DOUT has reached its correct value.
+
+With this patch its now possible to wait until data is ready.
+
+The wait time should not be higher than the maximum PD_SCK high time which
+is corresponding to the datasheet 50000 ns.
+
+Signed-off-by: Andreas Klinger <ak@it-klinger.de>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/iio/adc/hx711.c | 39 +++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 39 insertions(+)
+
+diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
+index 27005d84ed73d..8eb3f1bbe332b 100644
+--- a/drivers/iio/adc/hx711.c
++++ b/drivers/iio/adc/hx711.c
+@@ -89,6 +89,14 @@ struct hx711_data {
+ int gain_set; /* gain set on device */
+ int gain_chan_a; /* gain for channel A */
+ struct mutex lock;
++ /*
++ * delay after a rising edge on SCK until the data is ready DOUT
++ * this is dependent on the hx711 where the datasheet tells a
++ * maximum value of 100 ns
++ * but also on potential parasitic capacities on the wiring
++ */
++ u32 data_ready_delay_ns;
++ u32 clock_frequency;
+ };
+
+ static int hx711_cycle(struct hx711_data *hx711_data)
+@@ -102,6 +110,14 @@ static int hx711_cycle(struct hx711_data *hx711_data)
+ */
+ preempt_disable();
+ gpiod_set_value(hx711_data->gpiod_pd_sck, 1);
++
++ /*
++ * wait until DOUT is ready
++ * it turned out that parasitic capacities are extending the time
++ * until DOUT has reached it's value
++ */
++ ndelay(hx711_data->data_ready_delay_ns);
++
+ val = gpiod_get_value(hx711_data->gpiod_dout);
+ /*
+ * here we are not waiting for 0.2 us as suggested by the datasheet,
+@@ -112,6 +128,12 @@ static int hx711_cycle(struct hx711_data *hx711_data)
+ gpiod_set_value(hx711_data->gpiod_pd_sck, 0);
+ preempt_enable();
+
++ /*
++ * make it a square wave for addressing cases with capacitance on
++ * PC_SCK
++ */
++ ndelay(hx711_data->data_ready_delay_ns);
++
+ return val;
+ }
+
+@@ -401,6 +423,7 @@ static const struct iio_chan_spec hx711_chan_spec[] = {
+ static int hx711_probe(struct platform_device *pdev)
+ {
+ struct device *dev = &pdev->dev;
++ struct device_node *np = dev->of_node;
+ struct hx711_data *hx711_data;
+ struct iio_dev *indio_dev;
+ int ret;
+@@ -474,6 +497,22 @@ static int hx711_probe(struct platform_device *pdev)
+ hx711_data->gain_set = 128;
+ hx711_data->gain_chan_a = 128;
+
++ hx711_data->clock_frequency = 400000;
++ ret = of_property_read_u32(np, "clock-frequency",
++ &hx711_data->clock_frequency);
++
++ /*
++ * datasheet says the high level of PD_SCK has a maximum duration
++ * of 50 microseconds
++ */
++ if (hx711_data->clock_frequency < 20000) {
++ dev_warn(dev, "clock-frequency too low - assuming 400 kHz\n");
++ hx711_data->clock_frequency = 400000;
++ }
++
++ hx711_data->data_ready_delay_ns =
++ 1000000000 / hx711_data->clock_frequency;
++
+ platform_set_drvdata(pdev, indio_dev);
+
+ indio_dev->name = "hx711";
+--
+2.20.1
+
cifs-force-revalidate-inode-when-dentry-is-stale.patch
cifs-force-reval-dentry-if-lookup_reval-flag-is-set.patch
kernel-sysctl.c-do-not-override-max_threads-provided-by-userspace.patch
+firmware-google-increment-vpd-key_len-properly.patch
+gpiolib-don-t-clear-flag_is_out-when-emulating-open-.patch
+staging-fbtft-fix-memory-leak-in-fbtft_framebuffer_a.patch
+iio-hx711-add-delay-until-dout-is-ready.patch
+iio-adc-hx711-fix-bug-in-sampling-of-data.patch
--- /dev/null
+From 8dfc644ff61a6a56f8880b77af71c9603f71f7c9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 29 Sep 2019 22:09:45 -0500
+Subject: Staging: fbtft: fix memory leak in fbtft_framebuffer_alloc
+
+From: Navid Emamdoost <navid.emamdoost@gmail.com>
+
+[ Upstream commit 5bdea6060618cfcf1459dca137e89aee038ac8b9 ]
+
+In fbtft_framebuffer_alloc the error handling path should take care of
+releasing frame buffer after it is allocated via framebuffer_alloc, too.
+Therefore, in two failure cases the goto destination is changed to
+address this issue.
+
+Fixes: c296d5f9957c ("staging: fbtft: core support")
+Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
+Reviewed-by: Dan Carpenter <dan.carpenter@gmail.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20190930030949.28615-1-navid.emamdoost@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/staging/fbtft/fbtft-core.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c
+index 6d0363deba619..0cbcbad8f0742 100644
+--- a/drivers/staging/fbtft/fbtft-core.c
++++ b/drivers/staging/fbtft/fbtft-core.c
+@@ -828,7 +828,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
+ if (par->gamma.curves && gamma) {
+ if (fbtft_gamma_parse_str(par,
+ par->gamma.curves, gamma, strlen(gamma)))
+- goto alloc_fail;
++ goto release_framebuf;
+ }
+
+ /* Transmit buffer */
+@@ -845,7 +845,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
+ if (txbuflen > 0) {
+ txbuf = devm_kzalloc(par->info->device, txbuflen, GFP_KERNEL);
+ if (!txbuf)
+- goto alloc_fail;
++ goto release_framebuf;
+ par->txbuf.buf = txbuf;
+ par->txbuf.len = txbuflen;
+ }
+@@ -881,6 +881,9 @@ struct fb_info *fbtft_framebuffer_alloc(struct fbtft_display *display,
+
+ return info;
+
++release_framebuf:
++ framebuffer_release(info);
++
+ alloc_fail:
+ vfree(vmem);
+
+--
+2.20.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
