Hi Greg,
This patch is not marked for 4.4-stable, but it's already in 4.9 and 4.14 stable.
Please apply to 4.4-stable.
This patch adds necessary function when removing driver.
--
SZ Lin (林上智)
Hi Greg,
This patch is not marked for 4.4-stable, but it's already in 4.9 and 4.14 stable.
Please apply to 4.4-stable.
This patch fixed leak of mdio device reference.
--
SZ Lin (林上智)
Hi,
This patch is not marked for 4.4-stable, but it's already in 4.9 and 4.14 stable.
Please apply to 4.4-stable.
This patch fixed parsing of phy-handle DT property in dual_emac config.
--
SZ Lin (林上智)
e466af75c074 ("netfilter: x_tables: avoid stack-out-of-bounds read in
xt_copy_counters_from_user") fixes an out-of-bounds read that happens
when a userspace-controlled value is not NULL terminated. It looks like
the fix was taken into 3.16.y but not kernels after it.
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
commit 44a182b9d17765514fa2b1cc911e4e65134eef93 upstream.
KASAN found a use-after-free in xhci_free_virt_device+0x33b/0x38e
where xhci_free_virt_device() sets slot id to 0 if udev exists:
if (dev->udev && dev->udev->slot_id)
dev->udev->slot_id = 0;
dev->udev will be true even if udev is freed because dev->udev is
not set to NULL.
set dev->udev pointer to NULL in xhci_free_dev()
The original patch went to stable so this fix needs to be applied
there as well.
Fixes: a400efe455f7 ("xhci: zero usb device slot_id member when disabling and freeing a xhci slot")
Cc: <stable(a)vger.kernel.org>
Reported-by: Guenter Roeck <linux(a)roeck-us.net>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Tested-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
---
The original fix has been integrated into some recent -stable versions,
but wasn't backported to older LTS kernel like v4.9 or v4.4. The context
in xhci_free_dev() changed a bit because upstream added
xhci_disable_slot().
drivers/usb/host/xhci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index c190fabd1875..e9f5f9c32b49 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3656,6 +3656,9 @@ void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
}
spin_lock_irqsave(&xhci->lock, flags);
+
+ virt_dev->udev = NULL;
+
/* Don't disable the slot if the host controller is dead. */
state = readl(&xhci->op_regs->status);
if (state == 0xffffffff || (xhci->xhc_state & XHCI_STATE_DYING) ||
--
2.19.0.397.gdd90340f6a-goog
Hi stable-maintainers,
Hi Greg,
it seems that the patch to fix early boot stalling with Intel Core 2
processors, which Linus' already applied to his tree and could be
found in >=4.19-rc3, somehow missed the CC: line for linux-stable to
pick it up. As of now 4.18.8-rc1 does not include it.
The latest kernel version unaffected by this issues is 4.17.19, so a
backport to 4.18.y should be enough.
Thank you for all your hard work,
Siegfried
commit 6209c285e7a5e68dbcdf8fd2456c6dd68433806b upstream.
Since Haswell we have no color range indication either in the pipe or
port registers for DP. Instead, there's a separate register for setting
the DP Main Stream Attributes (MSA) directly. The MSA register
definition makes no references to colorimetry, just a vague reference to
the DP spec. The connection to the color range was lost.
Apparently we've failed to set the proper MSA bit for limited, or CEA,
range ever since the first DDI platforms. We've started setting other
MSA parameters since commit dae847991a43 ("drm/i915: add
intel_ddi_set_pipe_settings").
Without the crucial bit of information, the DP sink has no way of
knowing the source is actually transmitting limited range RGB, leading
to "washed out" colors. With the colorimetry information, compliant
sinks should be able to handle the limited range properly. Native
(i.e. non-LSPCON) HDMI was not affected because we do pass the color
range via AVI infoframes.
Though not the root cause, the problem was made worse for DDI platforms
with commit 55bc60db5988 ("drm/i915: Add "Automatic" mode for the
"Broadcast RGB" property"), which selects limited range RGB
automatically based on the mode, as per the DP, HDMI and CEA specs.
After all these years, the fix boils down to flipping one bit.
[Per testing reports, this fixes DP sinks, but not the LSPCON. My
educated guess is that the LSPCON fails to turn the CEA range MSA into
AVI infoframes for HDMI.]
Reported-by: Michał Kopeć <mkopec12(a)gmail.com>
Reported-by: N. W. <nw9165-3201(a)yahoo.com>
Reported-by: Nicholas Stommel <nicholas.stommel(a)gmail.com>
Reported-by: Tom Yan <tom.ty89(a)gmail.com>
Tested-by: Nicholas Stommel <nicholas.stommel(a)gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=100023
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921
Cc: Paulo Zanoni <paulo.r.zanoni(a)intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> # v3.9+
Reviewed-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.n…
(cherry picked from commit dc5977da99ea28094b8fa4e9bacbd29bedc41de5)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c9bcc6c45012..b3f7ba3b11c5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8441,6 +8441,7 @@ enum skl_power_gate {
#define TRANS_MSA_10_BPC (2<<5)
#define TRANS_MSA_12_BPC (3<<5)
#define TRANS_MSA_16_BPC (4<<5)
+#define TRANS_MSA_CEA_RANGE (1<<3)
/* LCPLL Control */
#define LCPLL_CTL _MMIO(0x130040)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 5e5fe03b638c..3a4a581345c4 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1396,6 +1396,10 @@ void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state)
WARN_ON(transcoder_is_dsi(cpu_transcoder));
temp = TRANS_MSA_SYNC_CLK;
+
+ if (crtc_state->limited_color_range)
+ temp |= TRANS_MSA_CEA_RANGE;
+
switch (crtc_state->pipe_bpp) {
case 18:
temp |= TRANS_MSA_6_BPC;
--
2.11.0
adding stable@ for stable kernel issues...
On Thu, Sep 13, 2018 at 09:58:35AM +0200, Koen Vandeputte wrote:
> Hi all,
>
> I'm currently in the process of updating the kernel version within OpenWrt.
> (4.14.68 to 4.14.69)
>
> Testing shows some issues on devices using specifically UBIFS.
> Altering a perfect valid writable file shows weird errors:
>
>
> [ Node 2 | node-2 ] ls -l /root/custom/scripts/banner.sh
> -rwxr-xr-x 1 root root 283 Sep 11 09:52
> /root/custom/scripts/banner.sh
>
> [ Node 2 | node-2 ] cat /root/custom/scripts/banner.sh
> #!/bin/sh
>
> if [ ! -f /root/.banner_ok ]
> then
> RELEASE=$(cat /root/build_date)
> VERSION=$(cat /root/version)
>
> echo "Generating banner: $VERSION $RELEASE"
> sed s/VERSION/$VERSION/g /root/custom/banner > /etc/banner
> sed -i s/RELEASE/$RELEASE/g /etc/banner
>
> touch /root/.banner_ok
> fi
>
> [ Node 2 | node-2 ] echo "test" > /root/custom/scripts/banner.sh
> -ash: can't create /root/custom/scripts/banner.sh: nonexistent directory
>
>
>
> I'm also noticing other apps fail because /etc doesn't exists yet after
> UBIFS boot loading.
> these 2 issues were not seen on 4.14.68.
>
> The bootlog doesn't show any error:
> https://pastebin.com/raw/dJx47uBp
>
>
> I'm only seeing these issues on UBIFS enabled volumes.
> Reverting ("ubifs: xattr: Don't operate on deleted inodes") fixes these
> weird issues.
Do you also have the same problem on Linus's latest tree, or 4.18, with
this change in the tree?
thanks,
greg k-h