This is a note to let you know that I've just added the patch titled
video: fbdev: atmel_lcdfb: fix display-timings lookup
to the 4.14-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:
video-fbdev-atmel_lcdfb-fix-display-timings-lookup.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)…
[View More]vger.kernel.org> know about it.
>From 9cb18db0701f6b74f0c45c23ad767b3ebebe37f6 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Fri, 29 Dec 2017 19:48:43 +0100
Subject: video: fbdev: atmel_lcdfb: fix display-timings lookup
From: Johan Hovold <johan(a)kernel.org>
commit 9cb18db0701f6b74f0c45c23ad767b3ebebe37f6 upstream.
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
To make things worse, the parent display node was also prematurely
freed.
Note that the display and timings node references are never put after a
successful dt-initialisation so the nodes would leak on later probe
deferrals and on driver unbind.
Fixes: b985172b328a ("video: atmel_lcdfb: add device tree suport")
Cc: stable <stable(a)vger.kernel.org> # 3.13
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj(a)jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Cc: Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/atmel_lcdfb.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -1119,7 +1119,7 @@ static int atmel_lcdfb_of_init(struct at
goto put_display_node;
}
- timings_np = of_find_node_by_name(display_np, "display-timings");
+ timings_np = of_get_child_by_name(display_np, "display-timings");
if (!timings_np) {
dev_err(dev, "failed to find display-timings node\n");
ret = -ENODEV;
@@ -1140,6 +1140,12 @@ static int atmel_lcdfb_of_init(struct at
fb_add_videomode(&fb_vm, &info->modelist);
}
+ /*
+ * FIXME: Make sure we are not referencing any fields in display_np
+ * and timings_np and drop our references to them before returning to
+ * avoid leaking the nodes on probe deferral and driver unbind.
+ */
+
return 0;
put_timings_node:
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-4.14/pci-keystone-fix-interrupt-controller-node-lookup.patch
queue-4.14/video-fbdev-atmel_lcdfb-fix-display-timings-lookup.patch
[View Less]
This is a note to let you know that I've just added the patch titled
tracing: Fix parsing of globs with a wildcard at the beginning
to the 4.14-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:
tracing-fix-parsing-of-globs-with-a-wildcard-at-the-beginning.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
…
[View More]please let <stable(a)vger.kernel.org> know about it.
>From 07234021410bbc27b7c86c18de98616c29fbe667 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
Date: Mon, 5 Feb 2018 22:18:11 -0500
Subject: tracing: Fix parsing of globs with a wildcard at the beginning
From: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
commit 07234021410bbc27b7c86c18de98616c29fbe667 upstream.
Al Viro reported:
For substring - sure, but what about something like "*a*b" and "a*b"?
AFAICS, filter_parse_regex() ends up with identical results in both
cases - MATCH_GLOB and *search = "a*b". And no way for the caller
to tell one from another.
Testing this with the following:
# cd /sys/kernel/tracing
# echo '*raw*lock' > set_ftrace_filter
bash: echo: write error: Invalid argument
With this patch:
# echo '*raw*lock' > set_ftrace_filter
# cat set_ftrace_filter
_raw_read_trylock
_raw_write_trylock
_raw_read_unlock
_raw_spin_unlock
_raw_write_unlock
_raw_spin_trylock
_raw_spin_lock
_raw_write_lock
_raw_read_lock
Al recommended not setting the search buffer to skip the first '*' unless we
know we are not using MATCH_GLOB. This implements his suggested logic.
Link: http://lkml.kernel.org/r/20180127170748.GF13338@ZenIV.linux.org.uk
Cc: stable(a)vger.kernel.org
Fixes: 60f1d5e3bac44 ("ftrace: Support full glob matching")
Reviewed-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Suggsted-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/trace/trace_events_filter.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -400,7 +400,6 @@ enum regex_type filter_parse_regex(char
for (i = 0; i < len; i++) {
if (buff[i] == '*') {
if (!i) {
- *search = buff + 1;
type = MATCH_END_ONLY;
} else if (i == len - 1) {
if (type == MATCH_END_ONLY)
@@ -410,14 +409,14 @@ enum regex_type filter_parse_regex(char
buff[i] = 0;
break;
} else { /* pattern continues, use full glob */
- type = MATCH_GLOB;
- break;
+ return MATCH_GLOB;
}
} else if (strchr("[?\\", buff[i])) {
- type = MATCH_GLOB;
- break;
+ return MATCH_GLOB;
}
}
+ if (buff[0] == '*')
+ *search = buff + 1;
return type;
}
Patches currently in stable-queue which might be from rostedt(a)goodmis.org are
queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch
queue-4.14/tracing-fix-parsing-of-globs-with-a-wildcard-at-the-beginning.patch
[View Less]
This is a note to let you know that I've just added the patch titled
seq_file: fix incomplete reset on read from zero offset
to the 4.14-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:
seq_file-fix-incomplete-reset-on-read-from-zero-offset.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <…
[View More]stable(a)vger.kernel.org> know about it.
>From cf5eebae2cd28d37581507668605f4d23cd7218d Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Wed, 15 Nov 2017 11:34:58 +0100
Subject: seq_file: fix incomplete reset on read from zero offset
From: Miklos Szeredi <mszeredi(a)redhat.com>
commit cf5eebae2cd28d37581507668605f4d23cd7218d upstream.
When resetting iterator on a zero offset we need to discard any data
already in the buffer (count), and private state of the iterator (version).
For example this bug results in first line being repeated in /proc/mounts
if doing a zero size read before a non-zero size read.
Reported-by: Rich Felker <dalias(a)libc.org>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: e522751d605d ("seq_file: reset iterator to first record for zero offset")
Cc: <stable(a)vger.kernel.org> # v4.10
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/seq_file.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -181,8 +181,11 @@ ssize_t seq_read(struct file *file, char
* if request is to read from zero offset, reset iterator to first
* record as it might have been already advanced by previous requests
*/
- if (*ppos == 0)
+ if (*ppos == 0) {
m->index = 0;
+ m->version = 0;
+ m->count = 0;
+ }
/* Don't assume *ppos is where we left it */
if (unlikely(*ppos != m->read_pos)) {
Patches currently in stable-queue which might be from mszeredi(a)redhat.com are
queue-4.14/seq_file-fix-incomplete-reset-on-read-from-zero-offset.patch
[View Less]
This is a note to let you know that I've just added the patch titled
rtc-opal: Fix handling of firmware error codes, prevent busy loops
to the 4.14-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:
rtc-opal-fix-handling-of-firmware-error-codes-prevent-busy-loops.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable …
[View More]tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5b8b58063029f02da573120ef4dc9079822e3cda Mon Sep 17 00:00:00 2001
From: Stewart Smith <stewart(a)linux.vnet.ibm.com>
Date: Tue, 2 Aug 2016 11:50:16 +1000
Subject: rtc-opal: Fix handling of firmware error codes, prevent busy loops
From: Stewart Smith <stewart(a)linux.vnet.ibm.com>
commit 5b8b58063029f02da573120ef4dc9079822e3cda upstream.
According to the OPAL docs:
skiboot-5.2.5/doc/opal-api/opal-rtc-read-3.txt
skiboot-5.2.5/doc/opal-api/opal-rtc-write-4.txt
OPAL_HARDWARE may be returned from OPAL_RTC_READ or OPAL_RTC_WRITE and
this indicates either a transient or permanent error.
Prior to this patch, Linux was not dealing with OPAL_HARDWARE being a
permanent error particularly well, in that you could end up in a busy
loop.
This was not too hard to trigger on an AMI BMC based OpenPOWER machine
doing a continuous "ipmitool mc reset cold" to the BMC, the result of
that being that we'd get stuck in an infinite loop in
opal_get_rtc_time().
We now retry a few times before returning the error higher up the
stack.
Fixes: 16b1d26e77b1 ("rtc/tpo: Driver to support rtc and wakeup on PowerNV platform")
Cc: stable(a)vger.kernel.org # v3.19+
Signed-off-by: Stewart Smith <stewart(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/rtc/rtc-opal.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/drivers/rtc/rtc-opal.c
+++ b/drivers/rtc/rtc-opal.c
@@ -58,6 +58,7 @@ static void tm_to_opal(struct rtc_time *
static int opal_get_rtc_time(struct device *dev, struct rtc_time *tm)
{
long rc = OPAL_BUSY;
+ int retries = 10;
u32 y_m_d;
u64 h_m_s_ms;
__be32 __y_m_d;
@@ -67,8 +68,11 @@ static int opal_get_rtc_time(struct devi
rc = opal_rtc_read(&__y_m_d, &__h_m_s_ms);
if (rc == OPAL_BUSY_EVENT)
opal_poll_events(NULL);
- else
+ else if (retries-- && (rc == OPAL_HARDWARE
+ || rc == OPAL_INTERNAL_ERROR))
msleep(10);
+ else if (rc != OPAL_BUSY && rc != OPAL_BUSY_EVENT)
+ break;
}
if (rc != OPAL_SUCCESS)
@@ -84,6 +88,7 @@ static int opal_get_rtc_time(struct devi
static int opal_set_rtc_time(struct device *dev, struct rtc_time *tm)
{
long rc = OPAL_BUSY;
+ int retries = 10;
u32 y_m_d = 0;
u64 h_m_s_ms = 0;
@@ -92,8 +97,11 @@ static int opal_set_rtc_time(struct devi
rc = opal_rtc_write(y_m_d, h_m_s_ms);
if (rc == OPAL_BUSY_EVENT)
opal_poll_events(NULL);
- else
+ else if (retries-- && (rc == OPAL_HARDWARE
+ || rc == OPAL_INTERNAL_ERROR))
msleep(10);
+ else if (rc != OPAL_BUSY && rc != OPAL_BUSY_EVENT)
+ break;
}
return rc == OPAL_SUCCESS ? 0 : -EIO;
Patches currently in stable-queue which might be from stewart(a)linux.vnet.ibm.com are
queue-4.14/rtc-opal-fix-handling-of-firmware-error-codes-prevent-busy-loops.patch
[View Less]
This is a note to let you know that I've just added the patch titled
Revert "mmc: meson-gx: include tx phase in the tuning process"
to the 4.14-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:
revert-mmc-meson-gx-include-tx-phase-in-the-tuning-process.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please …
[View More]let <stable(a)vger.kernel.org> know about it.
>From fe0e58048f005fdce315eb4d185e5c160be4ac01 Mon Sep 17 00:00:00 2001
From: Jerome Brunet <jbrunet(a)baylibre.com>
Date: Mon, 12 Feb 2018 14:13:59 +0100
Subject: Revert "mmc: meson-gx: include tx phase in the tuning process"
From: Jerome Brunet <jbrunet(a)baylibre.com>
commit fe0e58048f005fdce315eb4d185e5c160be4ac01 upstream.
This reverts commit 0a44697627d17a66d7dc98f17aeca07ca79c5c20.
This commit was initially intended to fix problems with hs200 and hs400
on some boards, mainly the odroid-c2. The OC2 (Rev 0.2) I have performs
well in this modes, so I could not confirm these issues.
We've had several reports about the issues being still present on (some)
OC2, so apparently, this change does not do what it was supposed to do.
Maybe the eMMC signal quality is on the edge on the board. This may
explain the variability we see in term of stability, but this is just a
guess. Lowering the max_frequency to 100Mhz seems to do trick for those
affected by the issue
Worse, the commit created new issues (CRC errors and hangs) on other
boards, such as the kvim 1 and 2, the p200 or the libretech-cc.
According to amlogic, the Tx phase should not be tuned and left in its
default configuration, so it is best to just revert the commit.
Fixes: 0a44697627d1 ("mmc: meson-gx: include tx phase in the tuning process")
Cc: <stable(a)vger.kernel.org> # 4.14+
Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/meson-gx-mmc.c | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -716,22 +716,6 @@ static int meson_mmc_clk_phase_tuning(st
static int meson_mmc_execute_tuning(struct mmc_host *mmc, u32 opcode)
{
struct meson_host *host = mmc_priv(mmc);
- int ret;
-
- /*
- * If this is the initial tuning, try to get a sane Rx starting
- * phase before doing the actual tuning.
- */
- if (!mmc->doing_retune) {
- ret = meson_mmc_clk_phase_tuning(mmc, opcode, host->rx_clk);
-
- if (ret)
- return ret;
- }
-
- ret = meson_mmc_clk_phase_tuning(mmc, opcode, host->tx_clk);
- if (ret)
- return ret;
return meson_mmc_clk_phase_tuning(mmc, opcode, host->rx_clk);
}
@@ -762,9 +746,8 @@ static void meson_mmc_set_ios(struct mmc
if (!IS_ERR(mmc->supply.vmmc))
mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, ios->vdd);
- /* Reset phases */
+ /* Reset rx phase */
clk_set_phase(host->rx_clk, 0);
- clk_set_phase(host->tx_clk, 270);
break;
Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are
queue-4.14/revert-mmc-meson-gx-include-tx-phase-in-the-tuning-process.patch
[View Less]
This is a note to let you know that I've just added the patch titled
Revert "apple-gmux: lock iGP IO to protect from vgaarb changes"
to the 4.14-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:
revert-apple-gmux-lock-igp-io-to-protect-from-vgaarb-changes.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
…
[View More]please let <stable(a)vger.kernel.org> know about it.
>From d6fa7588fd7a8def4c747c0c574ce85d453e3788 Mon Sep 17 00:00:00 2001
From: Lukas Wunner <lukas(a)wunner.de>
Date: Wed, 24 Jan 2018 19:35:45 +0100
Subject: Revert "apple-gmux: lock iGP IO to protect from vgaarb changes"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Lukas Wunner <lukas(a)wunner.de>
commit d6fa7588fd7a8def4c747c0c574ce85d453e3788 upstream.
Commit 4eebd5a4e726 ("apple-gmux: lock iGP IO to protect from vgaarb
changes") amended this driver's ->probe hook to lock decoding of normal
(non-legacy) I/O space accesses to the integrated GPU on dual-GPU
MacBook Pros. The lock stays in place until the driver is unbound.
The change was made to work around an issue with the out-of-tree nvidia
graphics driver (available at http://www.nvidia.com/object/unix.html).
It contains the following sequence in nvidia/nv.c:
#if defined(CONFIG_VGA_ARB) && !defined(NVCPU_PPC64LE)
#if defined(VGA_DEFAULT_DEVICE)
vga_tryget(VGA_DEFAULT_DEVICE, VGA_RSRC_LEGACY_MASK);
#endif
vga_set_legacy_decoding(dev, VGA_RSRC_NONE);
#endif
This code was reported to cause deadlocks with VFIO already in 2013:
https://devtalk.nvidia.com/default/topic/545560
I've reported the issue to Nvidia developers once more in 2017:
https://www.spinics.net/lists/dri-devel/msg138754.html
On the MacBookPro10,1, this code apparently breaks backlight control
(which is handled by apple-gmux via an I/O region starting at 0x700),
as reported by Petri Hodju:
https://bugzilla.kernel.org/show_bug.cgi?id=86121
I tried to replicate Petri's observations on my MacBook9,1, which uses
the same Intel Ivy Bridge + Nvidia GeForce GT 650M architecture, to no
avail. On my machine apple-gmux' I/O region remains accessible even
with the nvidia driver loaded and commit 4eebd5a4e726 reverted.
Petri reported that apple-gmux becomes accessible again after a
suspend/resume cycle because the BIOS changed the VGA routing on the
root port to the Nvidia GPU. Perhaps this is a BIOS issue after all
that can be fixed with an update?
In any case, the change made by commit 4eebd5a4e726 has turned out to
cause two new issues:
* Wilfried Klaebe reports a deadlock when launching Xorg because it
opens /dev/vga_arbiter and calls vga_get(), but apple-gmux is holding
a lock on I/O space indefinitely. It looks like apple-gmux' current
behavior is an abuse of the vgaarb API as locks are not meant to be
held for longer periods:
https://bugzilla.kernel.org/show_bug.cgi?id=88861#c11https://bugzilla.kernel.org/attachment.cgi?id=217541
* On dual GPU MacBook Pros introduced since 2013, the integrated GPU is
powergated on boot und thus becomes invisible to Linux unless a custom
EFI protocol is used to leave it powered on. (A patch exists but is
not in mainline yet due to several negative side effects.) On these
machines, locking I/O to the integrated GPU (as done by 4eebd5a4e726)
fails and backlight control is therefore broken:
https://bugzilla.kernel.org/show_bug.cgi?id=105051
So let's revert commit 4eebd5a4e726 please. Users experiencing the
issue with the proprietary nvidia driver can comment out the above-
quoted problematic code as a workaround (or try updating the BIOS).
Cc: Petri Hodju <petrihodju(a)yahoo.com>
Cc: Bjorn Helgaas <bhelgaas(a)google.com>
Cc: Bruno Prémont <bonbons(a)linux-vserver.org>
Cc: Andy Ritger <aritger(a)nvidia.com>
Cc: Ronald Tschalär <ronald(a)innovation.ch>
Tested-by: Wilfried Klaebe <linux-kernel(a)lebenslange-mailadresse.de>
Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
Cc: stable(a)vger.kernel.org
Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/platform/x86/apple-gmux.c | 48 --------------------------------------
1 file changed, 1 insertion(+), 47 deletions(-)
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -24,7 +24,6 @@
#include <linux/delay.h>
#include <linux/pci.h>
#include <linux/vga_switcheroo.h>
-#include <linux/vgaarb.h>
#include <acpi/video.h>
#include <asm/io.h>
@@ -54,7 +53,6 @@ struct apple_gmux_data {
bool indexed;
struct mutex index_lock;
- struct pci_dev *pdev;
struct backlight_device *bdev;
/* switcheroo data */
@@ -599,23 +597,6 @@ static int gmux_resume(struct device *de
return 0;
}
-static struct pci_dev *gmux_get_io_pdev(void)
-{
- struct pci_dev *pdev = NULL;
-
- while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev))) {
- u16 cmd;
-
- pci_read_config_word(pdev, PCI_COMMAND, &cmd);
- if (!(cmd & PCI_COMMAND_IO))
- continue;
-
- return pdev;
- }
-
- return NULL;
-}
-
static int is_thunderbolt(struct device *dev, void *data)
{
return to_pci_dev(dev)->is_thunderbolt;
@@ -631,7 +612,6 @@ static int gmux_probe(struct pnp_dev *pn
int ret = -ENXIO;
acpi_status status;
unsigned long long gpe;
- struct pci_dev *pdev = NULL;
if (apple_gmux_data)
return -EBUSY;
@@ -682,7 +662,7 @@ static int gmux_probe(struct pnp_dev *pn
ver_minor = (version >> 16) & 0xff;
ver_release = (version >> 8) & 0xff;
} else {
- pr_info("gmux device not present or IO disabled\n");
+ pr_info("gmux device not present\n");
ret = -ENODEV;
goto err_release;
}
@@ -690,23 +670,6 @@ static int gmux_probe(struct pnp_dev *pn
pr_info("Found gmux version %d.%d.%d [%s]\n", ver_major, ver_minor,
ver_release, (gmux_data->indexed ? "indexed" : "classic"));
- /*
- * Apple systems with gmux are EFI based and normally don't use
- * VGA. In addition changing IO+MEM ownership between IGP and dGPU
- * disables IO/MEM used for backlight control on some systems.
- * Lock IO+MEM to GPU with active IO to prevent switch.
- */
- pdev = gmux_get_io_pdev();
- if (pdev && vga_tryget(pdev,
- VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM)) {
- pr_err("IO+MEM vgaarb-locking for PCI:%s failed\n",
- pci_name(pdev));
- ret = -EBUSY;
- goto err_release;
- } else if (pdev)
- pr_info("locked IO for PCI:%s\n", pci_name(pdev));
- gmux_data->pdev = pdev;
-
memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = gmux_read32(gmux_data, GMUX_PORT_MAX_BRIGHTNESS);
@@ -822,10 +785,6 @@ err_enable_gpe:
err_notify:
backlight_device_unregister(bdev);
err_release:
- if (gmux_data->pdev)
- vga_put(gmux_data->pdev,
- VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM);
- pci_dev_put(pdev);
release_region(gmux_data->iostart, gmux_data->iolen);
err_free:
kfree(gmux_data);
@@ -845,11 +804,6 @@ static void gmux_remove(struct pnp_dev *
&gmux_notify_handler);
}
- if (gmux_data->pdev) {
- vga_put(gmux_data->pdev,
- VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM);
- pci_dev_put(gmux_data->pdev);
- }
backlight_device_unregister(gmux_data->bdev);
release_region(gmux_data->iostart, gmux_data->iolen);
Patches currently in stable-queue which might be from lukas(a)wunner.de are
queue-4.14/pm-runtime-update-links_count-also-if-config_srcu.patch
queue-4.14/revert-apple-gmux-lock-igp-io-to-protect-from-vgaarb-changes.patch
[View Less]
This is a note to let you know that I've just added the patch titled
rbd: whitelist RBD_FEATURE_OPERATIONS feature bit
to the 4.14-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:
rbd-whitelist-rbd_feature_operations-feature-bit.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.…
[View More]kernel.org> know about it.
>From e573427a440fd67d3f522357d7ac901d59281948 Mon Sep 17 00:00:00 2001
From: Ilya Dryomov <idryomov(a)gmail.com>
Date: Tue, 16 Jan 2018 15:41:54 +0100
Subject: rbd: whitelist RBD_FEATURE_OPERATIONS feature bit
From: Ilya Dryomov <idryomov(a)gmail.com>
commit e573427a440fd67d3f522357d7ac901d59281948 upstream.
This feature bit restricts older clients from performing certain
maintenance operations against an image (e.g. clone, snap create).
krbd does not perform maintenance operations.
Cc: stable(a)vger.kernel.org
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Reviewed-by: Jason Dillaman <dillaman(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/rbd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -124,11 +124,13 @@ static int atomic_dec_return_safe(atomic
#define RBD_FEATURE_STRIPINGV2 (1ULL<<1)
#define RBD_FEATURE_EXCLUSIVE_LOCK (1ULL<<2)
#define RBD_FEATURE_DATA_POOL (1ULL<<7)
+#define RBD_FEATURE_OPERATIONS (1ULL<<8)
#define RBD_FEATURES_ALL (RBD_FEATURE_LAYERING | \
RBD_FEATURE_STRIPINGV2 | \
RBD_FEATURE_EXCLUSIVE_LOCK | \
- RBD_FEATURE_DATA_POOL)
+ RBD_FEATURE_DATA_POOL | \
+ RBD_FEATURE_OPERATIONS)
/* Features supported by this (client software) implementation. */
Patches currently in stable-queue which might be from idryomov(a)gmail.com are
queue-4.14/rbd-whitelist-rbd_feature_operations-feature-bit.patch
[View Less]
This is a note to let you know that I've just added the patch titled
PCI: keystone: Fix interrupt-controller-node lookup
to the 4.14-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:
pci-keystone-fix-interrupt-controller-node-lookup.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)…
[View More]vger.kernel.org> know about it.
>From eac56aa3bc8af3d9b9850345d0f2da9d83529134 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Fri, 17 Nov 2017 14:38:31 +0100
Subject: PCI: keystone: Fix interrupt-controller-node lookup
From: Johan Hovold <johan(a)kernel.org>
commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 upstream.
Fix child-node lookup during initialisation which was using the wrong
OF-helper and ended up searching the whole device tree depth-first
starting at the parent rather than just matching on its children.
To make things worse, the parent pci node could end up being prematurely
freed as of_find_node_by_name() drops a reference to its first argument.
Any matching child interrupt-controller node was also leaked.
Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
Cc: stable <stable(a)vger.kernel.org> # 3.18
Acked-by: Murali Karicheri <m-karicheri2(a)ti.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
[lorenzo.pieralisi(a)arm.com: updated commit subject]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/dwc/pci-keystone.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/pci/dwc/pci-keystone.c
+++ b/drivers/pci/dwc/pci-keystone.c
@@ -178,7 +178,7 @@ static int ks_pcie_get_irq_controller_in
}
/* interrupt controller is in a child node */
- *np_temp = of_find_node_by_name(np_pcie, controller);
+ *np_temp = of_get_child_by_name(np_pcie, controller);
if (!(*np_temp)) {
dev_err(dev, "Node for %s is absent\n", controller);
return -EINVAL;
@@ -187,6 +187,7 @@ static int ks_pcie_get_irq_controller_in
temp = of_irq_count(*np_temp);
if (!temp) {
dev_err(dev, "No IRQ entries in %s\n", controller);
+ of_node_put(*np_temp);
return -EINVAL;
}
@@ -204,6 +205,8 @@ static int ks_pcie_get_irq_controller_in
break;
}
+ of_node_put(*np_temp);
+
if (temp) {
*num_irqs = temp;
return 0;
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-4.14/pci-keystone-fix-interrupt-controller-node-lookup.patch
queue-4.14/video-fbdev-atmel_lcdfb-fix-display-timings-lookup.patch
[View Less]
This is a note to let you know that I've just added the patch titled
PCI: iproc: Fix NULL pointer dereference for BCMA
to the 4.14-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:
pci-iproc-fix-null-pointer-dereference-for-bcma.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.…
[View More]kernel.org> know about it.
>From 3b65ca50d24ce33cb92d88840e289135c92b40ed Mon Sep 17 00:00:00 2001
From: Ray Jui <ray.jui(a)broadcom.com>
Date: Thu, 11 Jan 2018 12:36:16 -0800
Subject: PCI: iproc: Fix NULL pointer dereference for BCMA
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ray Jui <ray.jui(a)broadcom.com>
commit 3b65ca50d24ce33cb92d88840e289135c92b40ed upstream.
With the inbound DMA mapping supported added, the iProc PCIe driver
parses DT property "dma-ranges" through call to
"of_pci_dma_range_parser_init()". In the case of BCMA, this results in a
NULL pointer deference due to a missing of_node.
Fix this by adding a guard in pcie-iproc-platform.c to only enable the
inbound DMA mapping logic when DT property "dma-ranges" is present.
Fixes: dd9d4e7498de3 ("PCI: iproc: Add inbound DMA mapping support")
Reported-by: Rafał Miłecki <rafal(a)milecki.pl>
Signed-off-by: Ray Jui <ray.jui(a)broadcom.com>
[lorenzo.pieralisi(a)arm.com: updated commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Tested-by: Rafał Miłecki <rafal(a)milecki.pl>
cc: <stable(a)vger.kernel.org> # 4.10+
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pcie-iproc-platform.c | 7 +++++++
drivers/pci/host/pcie-iproc.c | 8 +++++---
drivers/pci/host/pcie-iproc.h | 2 ++
3 files changed, 14 insertions(+), 3 deletions(-)
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -92,6 +92,13 @@ static int iproc_pcie_pltfm_probe(struct
pcie->need_ob_cfg = true;
}
+ /*
+ * DT nodes are not used by all platforms that use the iProc PCIe
+ * core driver. For platforms that require explict inbound mapping
+ * configuration, "dma-ranges" would have been present in DT
+ */
+ pcie->need_ib_cfg = of_property_read_bool(np, "dma-ranges");
+
/* PHY use is optional */
pcie->phy = devm_phy_get(dev, "pcie-phy");
if (IS_ERR(pcie->phy)) {
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -1396,9 +1396,11 @@ int iproc_pcie_setup(struct iproc_pcie *
}
}
- ret = iproc_pcie_map_dma_ranges(pcie);
- if (ret && ret != -ENOENT)
- goto err_power_off_phy;
+ if (pcie->need_ib_cfg) {
+ ret = iproc_pcie_map_dma_ranges(pcie);
+ if (ret && ret != -ENOENT)
+ goto err_power_off_phy;
+ }
#ifdef CONFIG_ARM
pcie->sysdata.private_data = pcie;
--- a/drivers/pci/host/pcie-iproc.h
+++ b/drivers/pci/host/pcie-iproc.h
@@ -74,6 +74,7 @@ struct iproc_msi;
* @ob: outbound mapping related parameters
* @ob_map: outbound mapping related parameters specific to the controller
*
+ * @need_ib_cfg: indicates SW needs to configure the inbound mapping window
* @ib: inbound mapping related parameters
* @ib_map: outbound mapping region related parameters
*
@@ -101,6 +102,7 @@ struct iproc_pcie {
struct iproc_pcie_ob ob;
const struct iproc_pcie_ob_map *ob_map;
+ bool need_ib_cfg;
struct iproc_pcie_ib ib;
const struct iproc_pcie_ib_map *ib_map;
Patches currently in stable-queue which might be from ray.jui(a)broadcom.com are
queue-4.14/pci-iproc-fix-null-pointer-dereference-for-bcma.patch
[View Less]
This is a note to let you know that I've just added the patch titled
PCI: Disable MSI for HiSilicon Hip06/Hip07 only in Root Port mode
to the 4.14-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:
pci-disable-msi-for-hisilicon-hip06-hip07-only-in-root-port-mode.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable …
[View More]tree,
please let <stable(a)vger.kernel.org> know about it.
>From deb86999323661c019ef2740eb9d479d1e526b5c Mon Sep 17 00:00:00 2001
From: Dongdong Liu <liudongdong3(a)huawei.com>
Date: Thu, 28 Dec 2017 17:53:32 +0800
Subject: PCI: Disable MSI for HiSilicon Hip06/Hip07 only in Root Port mode
From: Dongdong Liu <liudongdong3(a)huawei.com>
commit deb86999323661c019ef2740eb9d479d1e526b5c upstream.
HiSilicon Hip06/Hip07 can operate as either a Root Port or an Endpoint. It
always advertises an MSI capability, but it can only generate MSIs when in
Endpoint mode.
The device has the same Vendor and Device IDs in both modes, so check the
Class Code and disable MSI only when operating as a Root Port.
[bhelgaas: changelog]
Fixes: 72f2ff0deb87 ("PCI: Disable MSI for HiSilicon Hip06/Hip07 Root Ports")
Signed-off-by: Dongdong Liu <liudongdong3(a)huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Reviewed-by: Zhou Wang <wangzhou1(a)hisilicon.com>
Cc: stable(a)vger.kernel.org # v4.11+
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1636,8 +1636,8 @@ static void quirk_pcie_mch(struct pci_de
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7520_MCH, quirk_pcie_mch);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7320_MCH, quirk_pcie_mch);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7525_MCH, quirk_pcie_mch);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_HUAWEI, 0x1610, quirk_pcie_mch);
+DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_HUAWEI, 0x1610, PCI_CLASS_BRIDGE_PCI, 8, quirk_pcie_mch);
/*
* It's possible for the MSI to get corrupted if shpc and acpi
Patches currently in stable-queue which might be from liudongdong3(a)huawei.com are
queue-4.14/pci-disable-msi-for-hisilicon-hip06-hip07-only-in-root-port-mode.patch
[View Less]