This is a note to let you know that I've just added the patch titled
pinctrl: sx150x: Register pinctrl before adding the gpiochip
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pinctrl-sx150x-register-pinctrl-before-adding-the-gpiochip.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1a1d39e1b8dd1d0f92a79da4fcc1ab0be3ae9bfc Mon Sep 17 00:00:00 2001
From: Peter Rosin <peda(a)axentia.se>
Date: Wed, 17 Jan 2018 14:34:22 +0100
Subject: pinctrl: sx150x: Register pinctrl before adding the gpiochip
From: Peter Rosin <peda(a)axentia.se>
commit 1a1d39e1b8dd1d0f92a79da4fcc1ab0be3ae9bfc upstream.
Various gpiolib activity depend on the pinctrl to be up and kicking.
Therefore, register the pinctrl before adding a gpiochip.
Suggested-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Peter Rosin <peda(a)axentia.se>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pinctrl/pinctrl-sx150x.c | 35 +++++++++++++++++++++--------------
1 file changed, 21 insertions(+), 14 deletions(-)
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -1144,6 +1144,27 @@ static int sx150x_probe(struct i2c_clien
if (ret)
return ret;
+ /* Pinctrl_desc */
+ pctl->pinctrl_desc.name = "sx150x-pinctrl";
+ pctl->pinctrl_desc.pctlops = &sx150x_pinctrl_ops;
+ pctl->pinctrl_desc.confops = &sx150x_pinconf_ops;
+ pctl->pinctrl_desc.pins = pctl->data->pins;
+ pctl->pinctrl_desc.npins = pctl->data->npins;
+ pctl->pinctrl_desc.owner = THIS_MODULE;
+
+ ret = devm_pinctrl_register_and_init(dev, &pctl->pinctrl_desc,
+ pctl, &pctl->pctldev);
+ if (ret) {
+ dev_err(dev, "Failed to register pinctrl device\n");
+ return ret;
+ }
+
+ ret = pinctrl_enable(pctl->pctldev);
+ if (ret) {
+ dev_err(dev, "Failed to enable pinctrl device\n");
+ return ret;
+ }
+
/* Register GPIO controller */
pctl->gpio.label = devm_kstrdup(dev, client->name, GFP_KERNEL);
pctl->gpio.base = -1;
@@ -1217,20 +1238,6 @@ static int sx150x_probe(struct i2c_clien
client->irq);
}
- /* Pinctrl_desc */
- pctl->pinctrl_desc.name = "sx150x-pinctrl";
- pctl->pinctrl_desc.pctlops = &sx150x_pinctrl_ops;
- pctl->pinctrl_desc.confops = &sx150x_pinconf_ops;
- pctl->pinctrl_desc.pins = pctl->data->pins;
- pctl->pinctrl_desc.npins = pctl->data->npins;
- pctl->pinctrl_desc.owner = THIS_MODULE;
-
- pctl->pctldev = devm_pinctrl_register(dev, &pctl->pinctrl_desc, pctl);
- if (IS_ERR(pctl->pctldev)) {
- dev_err(dev, "Failed to register pinctrl device\n");
- return PTR_ERR(pctl->pctldev);
- }
-
return 0;
}
Patches currently in stable-queue which might be from peda(a)axentia.se are
queue-4.15/pinctrl-sx150x-register-pinctrl-before-adding-the-gpiochip.patch
queue-4.15/pinctrl-sx150x-unregister-the-pinctrl-on-release.patch
queue-4.15/pinctrl-sx150x-add-a-static-gpio-pinctrl-pin-range-mapping.patch
This is a note to let you know that I've just added the patch titled
pinctrl: sx150x: Add a static gpio/pinctrl pin range mapping
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pinctrl-sx150x-add-a-static-gpio-pinctrl-pin-range-mapping.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b930151e5b55a0e62a3aad06876de891ac980471 Mon Sep 17 00:00:00 2001
From: Peter Rosin <peda(a)axentia.se>
Date: Wed, 17 Jan 2018 14:34:23 +0100
Subject: pinctrl: sx150x: Add a static gpio/pinctrl pin range mapping
From: Peter Rosin <peda(a)axentia.se>
commit b930151e5b55a0e62a3aad06876de891ac980471 upstream.
Without such a range, gpiolib fails with -EPROBE_DEFER, pending the
addition of the range. So, without a range, gpiolib will keep
deferring indefinitely.
Fixes: 9e80f9064e73 ("pinctrl: Add SX150X GPIO Extender Pinctrl Driver")
Fixes: e10f72bf4b3e ("gpio: gpiolib: Generalise state persistence beyond sleep")
Suggested-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Peter Rosin <peda(a)axentia.se>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pinctrl/pinctrl-sx150x.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -1193,6 +1193,11 @@ static int sx150x_probe(struct i2c_clien
if (ret)
return ret;
+ ret = gpiochip_add_pin_range(&pctl->gpio, dev_name(dev),
+ 0, 0, pctl->data->npins);
+ if (ret)
+ return ret;
+
/* Add Interrupt support if an irq is specified */
if (client->irq > 0) {
pctl->irq_chip.name = devm_kstrdup(dev, client->name,
Patches currently in stable-queue which might be from peda(a)axentia.se are
queue-4.15/pinctrl-sx150x-register-pinctrl-before-adding-the-gpiochip.patch
queue-4.15/pinctrl-sx150x-unregister-the-pinctrl-on-release.patch
queue-4.15/pinctrl-sx150x-add-a-static-gpio-pinctrl-pin-range-mapping.patch
This is a note to let you know that I've just added the patch titled
pinctrl: mcp23s08: fix irq setup order
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pinctrl-mcp23s08-fix-irq-setup-order.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 02e389e63e3523828fc3832f27e0341885f60f6f Mon Sep 17 00:00:00 2001
From: Dmitry Mastykin <mastichi(a)gmail.com>
Date: Thu, 28 Dec 2017 18:19:24 +0300
Subject: pinctrl: mcp23s08: fix irq setup order
From: Dmitry Mastykin <mastichi(a)gmail.com>
commit 02e389e63e3523828fc3832f27e0341885f60f6f upstream.
When using mcp23s08 module with gpio-keys, often (50% of boots)
it fails to get irq numbers with message:
"gpio-keys keys: Unable to get irq number for GPIO 0, error -6".
Seems that irqs must be setup before devm_gpiochip_add_data().
Signed-off-by: Dmitry Mastykin <mastichi(a)gmail.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pinctrl/pinctrl-mcp23s08.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/pinctrl/pinctrl-mcp23s08.c
+++ b/drivers/pinctrl/pinctrl-mcp23s08.c
@@ -896,16 +896,16 @@ static int mcp23s08_probe_one(struct mcp
goto fail;
}
- ret = devm_gpiochip_add_data(dev, &mcp->chip, mcp);
- if (ret < 0)
- goto fail;
-
if (mcp->irq && mcp->irq_controller) {
ret = mcp23s08_irq_setup(mcp);
if (ret)
goto fail;
}
+ ret = devm_gpiochip_add_data(dev, &mcp->chip, mcp);
+ if (ret < 0)
+ goto fail;
+
mcp->pinctrl_desc.name = "mcp23xxx-pinctrl";
mcp->pinctrl_desc.pctlops = &mcp_pinctrl_ops;
mcp->pinctrl_desc.confops = &mcp_pinconf_ops;
Patches currently in stable-queue which might be from mastichi(a)gmail.com are
queue-4.15/pinctrl-mcp23s08-fix-irq-setup-order.patch
This is a note to let you know that I've just added the patch titled
pinctrl: intel: Initialize GPIO properly when used through irqchip
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pinctrl-intel-initialize-gpio-properly-when-used-through-irqchip.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f5a26acf0162477af6ee4c11b4fb9cffe5d3e257 Mon Sep 17 00:00:00 2001
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Date: Wed, 29 Nov 2017 16:25:44 +0300
Subject: pinctrl: intel: Initialize GPIO properly when used through irqchip
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
commit f5a26acf0162477af6ee4c11b4fb9cffe5d3e257 upstream.
When a GPIO is requested using gpiod_get_* APIs the intel pinctrl driver
switches the pin to GPIO mode and makes sure interrupts are routed to
the GPIO hardware instead of IOAPIC. However, if the GPIO is used
directly through irqchip, as is the case with many I2C-HID devices where
I2C core automatically configures interrupt for the device, the pin is
not initialized as GPIO. Instead we rely that the BIOS configures the
pin accordingly which seems not to be the case at least in Asus X540NA
SKU3 with Focaltech touchpad.
When the pin is not properly configured it might result weird behaviour
like interrupts suddenly stop firing completely and the touchpad stops
responding to user input.
Fix this by properly initializing the pin to GPIO mode also when it is
used directly through irqchip.
Fixes: 7981c0015af2 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support")
Reported-by: Daniel Drake <drake(a)endlessm.com>
Reported-and-tested-by: Chris Chiu <chiu(a)endlessm.com>
Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pinctrl/intel/pinctrl-intel.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -425,6 +425,18 @@ static void __intel_gpio_set_direction(v
writel(value, padcfg0);
}
+static void intel_gpio_set_gpio_mode(void __iomem *padcfg0)
+{
+ u32 value;
+
+ /* Put the pad into GPIO mode */
+ value = readl(padcfg0) & ~PADCFG0_PMODE_MASK;
+ /* Disable SCI/SMI/NMI generation */
+ value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI);
+ value &= ~(PADCFG0_GPIROUTSMI | PADCFG0_GPIROUTNMI);
+ writel(value, padcfg0);
+}
+
static int intel_gpio_request_enable(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin)
@@ -432,7 +444,6 @@ static int intel_gpio_request_enable(str
struct intel_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
void __iomem *padcfg0;
unsigned long flags;
- u32 value;
raw_spin_lock_irqsave(&pctrl->lock, flags);
@@ -442,13 +453,7 @@ static int intel_gpio_request_enable(str
}
padcfg0 = intel_get_padcfg(pctrl, pin, PADCFG0);
- /* Put the pad into GPIO mode */
- value = readl(padcfg0) & ~PADCFG0_PMODE_MASK;
- /* Disable SCI/SMI/NMI generation */
- value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI);
- value &= ~(PADCFG0_GPIROUTSMI | PADCFG0_GPIROUTNMI);
- writel(value, padcfg0);
-
+ intel_gpio_set_gpio_mode(padcfg0);
/* Disable TX buffer and enable RX (this will be input) */
__intel_gpio_set_direction(padcfg0, true);
@@ -935,6 +940,8 @@ static int intel_gpio_irq_type(struct ir
raw_spin_lock_irqsave(&pctrl->lock, flags);
+ intel_gpio_set_gpio_mode(reg);
+
value = readl(reg);
value &= ~(PADCFG0_RXEVCFG_MASK | PADCFG0_RXINV);
Patches currently in stable-queue which might be from mika.westerberg(a)linux.intel.com are
queue-4.15/pinctrl-intel-initialize-gpio-properly-when-used-through-irqchip.patch
queue-4.15/ahci-add-intel-cannon-lake-pch-h-pci-id.patch
This is a note to let you know that I've just added the patch titled
media: ts2020: avoid integer overflows on 32 bit machines
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-ts2020-avoid-integer-overflows-on-32-bit-machines.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 81742be14b6a90c9fd0ff6eb4218bdf696ad8e46 Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Date: Wed, 10 Jan 2018 07:20:39 -0500
Subject: media: ts2020: avoid integer overflows on 32 bit machines
From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
commit 81742be14b6a90c9fd0ff6eb4218bdf696ad8e46 upstream.
Before this patch, when compiled for arm32, the signal strength
were reported as:
Lock (0x1f) Signal= 4294908.66dBm C/N= 12.79dB
Because of a 32 bit integer overflow. After it, it is properly
reported as:
Lock (0x1f) Signal= -58.64dBm C/N= 12.79dB
Fixes: 0f91c9d6bab9 ("[media] TS2020: Calculate tuner gain correctly")
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/dvb-frontends/ts2020.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/media/dvb-frontends/ts2020.c
+++ b/drivers/media/dvb-frontends/ts2020.c
@@ -368,7 +368,7 @@ static int ts2020_read_tuner_gain(struct
gain2 = clamp_t(long, gain2, 0, 13);
v_agc = clamp_t(long, v_agc, 400, 1100);
- *_gain = -(gain1 * 2330 +
+ *_gain = -((__s64)gain1 * 2330 +
gain2 * 3500 +
v_agc * 24 / 10 * 10 +
10000);
@@ -386,7 +386,7 @@ static int ts2020_read_tuner_gain(struct
gain3 = clamp_t(long, gain3, 0, 6);
v_agc = clamp_t(long, v_agc, 600, 1600);
- *_gain = -(gain1 * 2650 +
+ *_gain = -((__s64)gain1 * 2650 +
gain2 * 3380 +
gain3 * 2850 +
v_agc * 176 / 100 * 10 -
Patches currently in stable-queue which might be from mchehab(a)s-opensource.com are
queue-4.15/media-hdpvr-fix-an-error-handling-path-in-hdpvr_probe.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
queue-4.15/media-dvb-usb-v2-lmedm04-move-ts2020-attach-to-dm04_lme2510_tuner.patch
queue-4.15/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
queue-4.15/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
queue-4.15/media-vivid-fix-module-load-error-when-enabling-fb-and-no_error_inj-1.patch
queue-4.15/media-dvb-frontends-fix-i2c-access-helpers-for-kasan.patch
queue-4.15/media-dvb-usb-v2-lmedm04-improve-logic-checking-of-warm-start.patch
queue-4.15/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch
queue-4.15/media-dvb_frontend-be-sure-to-init-dvb_frontend_handle_ioctl-return-code.patch
queue-4.15/media-ts2020-avoid-integer-overflows-on-32-bit-machines.patch
queue-4.15/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
queue-4.15/media-dt-bindings-media-cec-gpio.txt-mention-the-cec-hpd-max-voltages.patch
queue-4.15/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch
queue-4.15/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
queue-4.15/media-v4l2-ioctl.c-use-check_fmt-for-enum-g-s-try_fmt.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch
This is a note to let you know that I've just added the patch titled
media: dvb_frontend: be sure to init dvb_frontend_handle_ioctl() return code
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-dvb_frontend-be-sure-to-init-dvb_frontend_handle_ioctl-return-code.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a9cb97c3e628902e37583d8a40bb28cf76522cf1 Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Date: Wed, 1 Nov 2017 17:05:39 -0400
Subject: media: dvb_frontend: be sure to init dvb_frontend_handle_ioctl() return code
From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
commit a9cb97c3e628902e37583d8a40bb28cf76522cf1 upstream.
As smatch warned:
drivers/media/dvb-core/dvb_frontend.c:2468 dvb_frontend_handle_ioctl() error: uninitialized symbol 'err'.
The ioctl handler actually got a regression here: before changeset
d73dcf0cdb95 ("media: dvb_frontend: cleanup ioctl handling logic"),
the code used to return -EOPNOTSUPP if an ioctl handler was not
implemented on a driver. After the change, it may return a random
value.
Fixes: d73dcf0cdb95 ("media: dvb_frontend: cleanup ioctl handling logic")
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Tested-by: Daniel Scheller <d.scheller(a)gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/dvb-core/dvb_frontend.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2110,7 +2110,7 @@ static int dvb_frontend_handle_ioctl(str
struct dvb_frontend *fe = dvbdev->priv;
struct dvb_frontend_private *fepriv = fe->frontend_priv;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
- int i, err;
+ int i, err = -EOPNOTSUPP;
dev_dbg(fe->dvb->device, "%s:\n", __func__);
@@ -2145,6 +2145,7 @@ static int dvb_frontend_handle_ioctl(str
}
}
kfree(tvp);
+ err = 0;
break;
}
case FE_GET_PROPERTY: {
@@ -2196,6 +2197,7 @@ static int dvb_frontend_handle_ioctl(str
return -EFAULT;
}
kfree(tvp);
+ err = 0;
break;
}
Patches currently in stable-queue which might be from mchehab(a)s-opensource.com are
queue-4.15/media-hdpvr-fix-an-error-handling-path-in-hdpvr_probe.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
queue-4.15/media-dvb-usb-v2-lmedm04-move-ts2020-attach-to-dm04_lme2510_tuner.patch
queue-4.15/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
queue-4.15/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
queue-4.15/media-vivid-fix-module-load-error-when-enabling-fb-and-no_error_inj-1.patch
queue-4.15/media-dvb-frontends-fix-i2c-access-helpers-for-kasan.patch
queue-4.15/media-dvb-usb-v2-lmedm04-improve-logic-checking-of-warm-start.patch
queue-4.15/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch
queue-4.15/media-dvb_frontend-be-sure-to-init-dvb_frontend_handle_ioctl-return-code.patch
queue-4.15/media-ts2020-avoid-integer-overflows-on-32-bit-machines.patch
queue-4.15/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
queue-4.15/media-dt-bindings-media-cec-gpio.txt-mention-the-cec-hpd-max-voltages.patch
queue-4.15/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch
queue-4.15/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
queue-4.15/media-v4l2-ioctl.c-use-check_fmt-for-enum-g-s-try_fmt.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch
This is a note to let you know that I've just added the patch titled
media: dt-bindings/media/cec-gpio.txt: mention the CEC/HPD max voltages
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-dt-bindings-media-cec-gpio.txt-mention-the-cec-hpd-max-voltages.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From dac15ed62dc9d7898d3695a3c393d6f712d66185 Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hverkuil(a)xs4all.nl>
Date: Sat, 16 Dec 2017 05:44:13 -0500
Subject: media: dt-bindings/media/cec-gpio.txt: mention the CEC/HPD max voltages
From: Hans Verkuil <hverkuil(a)xs4all.nl>
commit dac15ed62dc9d7898d3695a3c393d6f712d66185 upstream.
Mention the maximum voltages of the CEC and HPD lines. Since in the example
these lines are connected to a Raspberry Pi and the Rpi GPIO lines are 3.3V
it is a good idea to warn against directly connecting the HPD to the Raspberry
Pi's GPIO line.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Reviewed-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/devicetree/bindings/media/cec-gpio.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/Documentation/devicetree/bindings/media/cec-gpio.txt
+++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
@@ -4,6 +4,10 @@ The HDMI CEC GPIO module supports CEC im
is hooked up to a pull-up GPIO line and - optionally - the HPD line is
hooked up to another GPIO line.
+Please note: the maximum voltage for the CEC line is 3.63V, for the HPD
+line it is 5.3V. So you may need some sort of level conversion circuitry
+when connecting them to a GPIO line.
+
Required properties:
- compatible: value must be "cec-gpio".
- cec-gpios: gpio that the CEC line is connected to. The line should be
@@ -21,7 +25,7 @@ the following property is optional:
Example for the Raspberry Pi 3 where the CEC line is connected to
pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
-connected to pin 11 aka BCM17:
+connected to pin 11 aka BCM17 (some level shifter is needed for this!):
#include <dt-bindings/gpio/gpio.h>
Patches currently in stable-queue which might be from hverkuil(a)xs4all.nl are
queue-4.15/media-dt-bindings-media-cec-gpio.txt-mention-the-cec-hpd-max-voltages.patch
This is a note to let you know that I've just added the patch titled
media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-cxusb-dib0700-ignore-xc2028_i2c_flush.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9893b905e743ded332575ca04486bd586c0772f7 Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Date: Wed, 24 Jan 2018 06:01:57 -0500
Subject: media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
From: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
commit 9893b905e743ded332575ca04486bd586c0772f7 upstream.
The XC2028_I2C_FLUSH only needs to be implemented on a few
devices. Others can safely ignore it.
That prevents filling the dmesg with lots of messages like:
dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0
Fixes: 4d37ece757a8 ("[media] tuner/xc2028: Add I2C flush callback")
Reported-by: Enrico Mioso <mrkiko.rs(a)gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/usb/dvb-usb/cxusb.c | 2 ++
drivers/media/usb/dvb-usb/dib0700_devices.c | 1 +
2 files changed, 3 insertions(+)
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -677,6 +677,8 @@ static int dvico_bluebird_xc2028_callbac
case XC2028_RESET_CLK:
deb_info("%s: XC2028_RESET_CLK %d\n", __func__, arg);
break;
+ case XC2028_I2C_FLUSH:
+ break;
default:
deb_info("%s: unknown command %d, arg %d\n", __func__,
command, arg);
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -430,6 +430,7 @@ static int stk7700ph_xc3028_callback(voi
state->dib7000p_ops.set_gpio(adap->fe_adap[0].fe, 8, 0, 1);
break;
case XC2028_RESET_CLK:
+ case XC2028_I2C_FLUSH:
break;
default:
err("%s: unknown command %d, arg %d\n", __func__,
Patches currently in stable-queue which might be from mchehab(a)osg.samsung.com are
queue-4.15/media-cxusb-dib0700-ignore-xc2028_i2c_flush.patch