* Re: [PATCH 1/2] drm/amdgpu: always un-gate UVD REGS path.
From: StDenis, Tom @ 2016-11-09 10:23 UTC (permalink / raw)
To: Zhu, Rex; +Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
In-Reply-To: <1478686135-21055-1-git-send-email-Rex.Zhu-5C7GfCeVMHo@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1584 bytes --]
You could do that as
WREG32_FIELD(UVD_CGC_GATE, REGS, 0);
Unless you need 'data' somewhere else in the function.
Tom
________________________________
From: amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of Rex Zhu <Rex.Zhu-5C7GfCeVMHo@public.gmane.org>
Sent: Wednesday, November 9, 2016 05:08
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: Zhu, Rex
Subject: [PATCH 1/2] drm/amdgpu: always un-gate UVD REGS path.
Change-Id: I910a79b551a9b79b635161bb42ac123a23783225
Signed-off-by: Rex Zhu <Rex.Zhu-5C7GfCeVMHo@public.gmane.org>
---
drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c b/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c
index d2c96f1..d686946 100644
--- a/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c
+++ b/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c
@@ -596,7 +596,10 @@ static void uvd_v4_2_set_dcm(struct amdgpu_device *adev,
bool sw_mode)
{
u32 tmp, tmp2;
+ u32 data = RREG32(mmUVD_CGC_GATE);
+ data &= ~UVD_CGC_GATE__REGS_MASK;
+ WREG32(mmUVD_CGC_GATE, data);
tmp = RREG32(mmUVD_CGC_CTRL);
tmp &= ~(UVD_CGC_CTRL__CLK_OFF_DELAY_MASK | UVD_CGC_CTRL__CLK_GATE_DLY_TIMER_MASK);
tmp |= UVD_CGC_CTRL__DYN_CLOCK_MODE_MASK |
--
1.9.1
_______________________________________________
amd-gfx mailing list
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[-- Attachment #1.2: Type: text/html, Size: 3102 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* Re: gcc-4.6.3, was Re: Debian on mac68k
From: John Paul Adrian Glaubitz @ 2016-11-09 10:24 UTC (permalink / raw)
To: Finn Thain; +Cc: Angelo Dureghello, debian-68k, linux-m68k
In-Reply-To: <alpine.LNX.2.00.1611090924080.2702@nippy.intranet>
On 11/09/2016 12:06 AM, Finn Thain wrote:
> As a way to get a compiler, it's more difficult than untarring the one
> from kernel.org, which was the effort I've been willing to invest so far.
If you're not on a Debian-based distribution, that is :).
> I would consider installing the Debian Testing compiler in the form of a
> container, if one was available.
You can just install Debian into a systemd-nspawn chroot with the help
of debootstrap. No need to use Docker or anything else. I have used
this method to install and boot Fedora Rawhide on my Debian unstable
system. Pretty nifty and simple:
# debootstrap --no-check-gpg --arch=amd64 --variant=buildd unstable /srv/unstable/ ftp://ftp.debian.org/debian
# systemd-nspawn -bD /srv/unstable
That's all you need to boot a Debian container on any machine running systemd.
> Or I could just update my cross-compiler build scripts again, but that
> solution doesn't get the upstream project much closer to the ideal
> solution, i.e. a convenient, reliable "reference" compiler.
Does that really make such a difference? I have always used the gcc
versions shipped in Debian and never had any issues. Matthias Klose
also updates them very regularly, so I don't have to worry about
that.
> That would require supported compiler and distro releases. Certainly
> Debian's gcc-5-m68k-linux-gnu or gcc-6-m68k-linux-gnu packages are good
> candidates for building a container, and time permitting, I would
> willingly test them and isolate and report any bugs I found.
We're thoroughly testing the toolchain in Debian on the buildds. By
actively building packages, we have found many bugs in gcc and binutils,
most of them were in the SH and SPARC targets though. I don't remember
running into any m68k-related toolchain issue.
Btw, there is one additional advantage using Debian for cross-platform
work: Multi-Arch. You can easily install build dependencies when
cross-building for other targets. I have used this extensively to
bootstrap ghc [1].
Adrian
> [1] https://wiki.debian.org/PortsDocs/BootstrappingGHC
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* [Buildroot] [PATCH 1/4] configs: atmel: at91sam9260eknf: update defconfig
From: Thomas Petazzoni @ 2016-11-09 10:25 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161109101009.l66iviomyfuit2t5@rfolt0960.corp.atmel.com>
Hello,
On Wed, 9 Nov 2016 11:10:09 +0100, Ludovic Desroches wrote:
> > Why enable both U-Boot and Barebox?
> >
>
> I don't know why Barebox was selected but the 'official' bootloader is
> U-Boot for all our products that's why I add it. I kept Barebox because
> it was already selected and I don't know if someone is still using it or
> not.
But the end result is a defconfig that doesn't make any sense.
Please provide a defconfig that makes sense, and with an updated
readme.txt if you decide to change the bootloader (and therefore the
flashing instructions).
> > > # Kernel
> > > BR2_LINUX_KERNEL=y
> > > -BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > > -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.9.1"
> >
> > For the sake of reproducibility you should set this to the version you tested,
> > say, 4.8.6. The same goes for other patches in this series.
>
> As Alexandre said, we don't want to spend time for the maintainance of these
> old boards so sticking to the mainline seems to be the way to go. Giving a
> version is a kind of commitment but we no longer perform tests on these
> boards excepting kernel boot with kernelci.
That's not Buildroot policy. We want defconfigs with fixed kernel and
bootloader versions, so that we know they have been tested.
If you are not able/willing to test those defconfigs, then we could
just as well remove them. But I'm not going to merge a defconfig that
doesn't comply with our policy of having a fixed kernel and a fixed
bootloader version.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] Fix legacy ncurses detection.
From: Samuel Thibault @ 2016-11-09 10:25 UTC (permalink / raw)
To: Sergey Smolov
Cc: Cornelia Huck, Peter Maydell, Michal Suchanek, QEMU Developers
In-Reply-To: <5822F736.90008@ispras.ru>
Sergey Smolov, on Wed 09 Nov 2016 13:15:18 +0300, wrote:
> Is it planned to publish this patch into master?
Yes.
Samuel
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] cipher: fix leak on initialization error
From: Marc-André Lureau @ 2016-11-09 10:26 UTC (permalink / raw)
To: Daniel P. Berrange; +Cc: Marc-André Lureau, qemu-devel
In-Reply-To: <20161109102239.GB22181@redhat.com>
Hi
----- Original Message -----
> On Wed, Nov 09, 2016 at 02:18:15PM +0400, Marc-André Lureau wrote:
> > If ctx->blocksize != XTS_BLOCK_SIZE, ctx will be leaked.
> > Assign ctx earler, and call qcrypto_cipher_free() on error.
> >
> > Spotted thanks to ASAN.
> >
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > ---
> > crypto/cipher-nettle.c | 15 ++++++++-------
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
> > index cd094cd..593962c 100644
> > --- a/crypto/cipher-nettle.c
> > +++ b/crypto/cipher-nettle.c
> > @@ -376,6 +376,7 @@ QCryptoCipher
> > *qcrypto_cipher_new(QCryptoCipherAlgorithm alg,
> > goto error;
> > }
>
> 'ctx' is non-NULL at this point and there's a 'goto error' just
> above here....
>
Right, fixing it sending v2
> >
> > + cipher->opaque = ctx;
> > if (mode == QCRYPTO_CIPHER_MODE_XTS &&
> > ctx->blocksize != XTS_BLOCK_SIZE) {
> > error_setg(errp, "Cipher block size %zu must equal XTS block size
> > %d",
> > @@ -384,13 +385,11 @@ QCryptoCipher
> > *qcrypto_cipher_new(QCryptoCipherAlgorithm alg,
> > }
> >
> > ctx->iv = g_new0(uint8_t, ctx->blocksize);
> > - cipher->opaque = ctx;
> >
> > return cipher;
> >
> > error:
> > - g_free(cipher);
> > - g_free(ctx);
> > + qcrypto_cipher_free(cipher);
> > return NULL;
> > }
>
>
> ...so you're leaking 'ctx' now, since it hasn't been assigned
> to cipher->ctx.
>
> You need to move 'cipher->opque = ctx' to the place where we
> initially allocate 'ctx', before any gotos at which point....
>
> >
> > @@ -404,10 +403,12 @@ void qcrypto_cipher_free(QCryptoCipher *cipher)
> > }
> >
> > ctx = cipher->opaque;
> > - g_free(ctx->iv);
> > - g_free(ctx->ctx);
> > - g_free(ctx->ctx_tweak);
> > - g_free(ctx);
> > + if (ctx) {
> > + g_free(ctx->iv);
> > + g_free(ctx->ctx);
> > + g_free(ctx->ctx_tweak);
> > + g_free(ctx);
> > + }
> > g_free(cipher);
> > }
>
> ...this change is not needed
>
> Regards,
> Daniel
> --
> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org -o- http://virt-manager.org :|
> |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
>
^ permalink raw reply
* Patch "HID: usbhid: add ATEN CS962 to list of quirky devices" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:26 UTC (permalink / raw)
To: oneukum, gregkh, jkosina; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
HID: usbhid: add ATEN CS962 to list of quirky devices
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
hid-usbhid-add-aten-cs962-to-list-of-quirky-devices.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From cf0ea4da4c7df11f7a508b2f37518e0f117f3791 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Thu, 3 Nov 2016 12:31:41 +0100
Subject: HID: usbhid: add ATEN CS962 to list of quirky devices
From: Oliver Neukum <oneukum@suse.com>
commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream.
Like many similar devices it needs a quirk to work.
Issuing the request gets the device into an irrecoverable state.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -168,6 +168,7 @@
#define USB_DEVICE_ID_ATEN_4PORTKVM 0x2205
#define USB_DEVICE_ID_ATEN_4PORTKVMC 0x2208
#define USB_DEVICE_ID_ATEN_CS682 0x2213
+#define USB_DEVICE_ID_ATEN_CS692 0x8021
#define USB_VENDOR_ID_ATMEL 0x03eb
#define USB_DEVICE_ID_ATMEL_MULTITOUCH 0x211c
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -61,6 +61,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVM, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVMC, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS682, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS692, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FIGHTERSTICK, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_COMBATSTICK, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FLIGHT_SIM_ECLIPSE_YOKE, HID_QUIRK_NOGET },
Patches currently in stable-queue which might be from oneukum@suse.com are
queue-4.4/hid-usbhid-add-aten-cs962-to-list-of-quirky-devices.patch
^ permalink raw reply
* Patch "kvm: x86: Check memopp before dereference (CVE-2016-8630)" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:26 UTC (permalink / raw)
To: osh, gregkh, pbonzini; +Cc: stable, stable-commits
In-Reply-To: <1477592752-126650-2-git-send-email-osh@google.com>
This is a note to let you know that I've just added the patch titled
kvm: x86: Check memopp before dereference (CVE-2016-8630)
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
kvm-x86-check-memopp-before-dereference-cve-2016-8630.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d9092f52d7e61dd1557f2db2400ddb430e85937e Mon Sep 17 00:00:00 2001
From: Owen Hofmann <osh@google.com>
Date: Thu, 27 Oct 2016 11:25:52 -0700
Subject: kvm: x86: Check memopp before dereference (CVE-2016-8630)
From: Owen Hofmann <osh@google.com>
commit d9092f52d7e61dd1557f2db2400ddb430e85937e upstream.
Commit 41061cdb98 ("KVM: emulate: do not initialize memopp") removes a
check for non-NULL under incorrect assumptions. An undefined instruction
with a ModR/M byte with Mod=0 and R/M-5 (e.g. 0xc7 0x15) will attempt
to dereference a null pointer here.
Fixes: 41061cdb98a0bec464278b4db8e894a3121671f5
Message-Id: <1477592752-126650-2-git-send-email-osh@google.com>
Signed-off-by: Owen Hofmann <osh@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/emulate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -5033,7 +5033,7 @@ done_prefixes:
/* Decode and fetch the destination operand: register or memory. */
rc = decode_operand(ctxt, &ctxt->dst, (ctxt->d >> DstShift) & OpMask);
- if (ctxt->rip_relative)
+ if (ctxt->rip_relative && likely(ctxt->memopp))
ctxt->memopp->addr.mem.ea = address_mask(ctxt,
ctxt->memopp->addr.mem.ea + ctxt->_eip);
Patches currently in stable-queue which might be from osh@google.com are
queue-4.4/kvm-x86-check-memopp-before-dereference-cve-2016-8630.patch
^ permalink raw reply
* Patch "pwm: Unexport children before chip removal" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:26 UTC (permalink / raw)
To: davidhsu, gregkh, thierry.reding; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
pwm: Unexport children before chip removal
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
pwm-unexport-children-before-chip-removal.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 0733424c9ba9f42242409d1ece780777272f7ea1 Mon Sep 17 00:00:00 2001
From: David Hsu <davidhsu@google.com>
Date: Tue, 9 Aug 2016 14:57:46 -0700
Subject: pwm: Unexport children before chip removal
From: David Hsu <davidhsu@google.com>
commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream.
Exported pwm channels aren't removed before the pwmchip and are
leaked. This results in invalid sysfs files. This fix removes
all exported pwm channels before chip removal.
Signed-off-by: David Hsu <davidhsu@google.com>
Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pwm/core.c | 2 ++
drivers/pwm/sysfs.c | 18 ++++++++++++++++++
include/linux/pwm.h | 5 +++++
3 files changed, 25 insertions(+)
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -321,6 +321,8 @@ int pwmchip_remove(struct pwm_chip *chip
unsigned int i;
int ret = 0;
+ pwmchip_sysfs_unexport_children(chip);
+
mutex_lock(&pwm_lock);
for (i = 0; i < chip->npwm; i++) {
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -350,6 +350,24 @@ void pwmchip_sysfs_unexport(struct pwm_c
}
}
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+ struct device *parent;
+ unsigned int i;
+
+ parent = class_find_device(&pwm_class, NULL, chip,
+ pwmchip_sysfs_match);
+ if (!parent)
+ return;
+
+ for (i = 0; i < chip->npwm; i++) {
+ struct pwm_device *pwm = &chip->pwms[i];
+
+ if (test_bit(PWMF_EXPORTED, &pwm->flags))
+ pwm_unexport_child(parent, pwm);
+ }
+}
+
static int __init pwm_sysfs_init(void)
{
return class_register(&pwm_class);
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -331,6 +331,7 @@ static inline void pwm_remove_table(stru
#ifdef CONFIG_PWM_SYSFS
void pwmchip_sysfs_export(struct pwm_chip *chip);
void pwmchip_sysfs_unexport(struct pwm_chip *chip);
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip);
#else
static inline void pwmchip_sysfs_export(struct pwm_chip *chip)
{
@@ -339,6 +340,10 @@ static inline void pwmchip_sysfs_export(
static inline void pwmchip_sysfs_unexport(struct pwm_chip *chip)
{
}
+
+static inline void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+}
#endif /* CONFIG_PWM_SYSFS */
#endif /* __LINUX_PWM_H */
Patches currently in stable-queue which might be from davidhsu@google.com are
queue-4.4/pwm-unexport-children-before-chip-removal.patch
^ permalink raw reply
* Patch "tty: vt, fix bogus division in csi_J" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:26 UTC (permalink / raw)
To: jslaby, gregkh, ppisar; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
tty: vt, fix bogus division in csi_J
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
tty-vt-fix-bogus-division-in-csi_j.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 42acfc6615f47e465731c263bee0c799edb098f2 Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Mon, 3 Oct 2016 11:00:17 +0200
Subject: tty: vt, fix bogus division in csi_J
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Jiri Slaby <jslaby@suse.cz>
commit 42acfc6615f47e465731c263bee0c799edb098f2 upstream.
In csi_J(3), the third parameter of scr_memsetw (vc_screenbuf_size) is
divided by 2 inappropriatelly. But scr_memsetw expects size, not
count, because it divides the size by 2 on its own before doing actual
memset-by-words.
So remove the bogus division.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Petr Písař <ppisar@redhat.com>
Fixes: f8df13e0a9 (tty: Clean console safely)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/vt/vt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1178,7 +1178,7 @@ static void csi_J(struct vc_data *vc, in
break;
case 3: /* erase scroll-back buffer (and whole display) */
scr_memsetw(vc->vc_screenbuf, vc->vc_video_erase_char,
- vc->vc_screenbuf_size >> 1);
+ vc->vc_screenbuf_size);
set_origin(vc);
if (CON_IS_VISIBLE(vc))
update_screen(vc);
Patches currently in stable-queue which might be from jslaby@suse.cz are
queue-4.4/tty-vt-fix-bogus-division-in-csi_j.patch
^ permalink raw reply
* Patch "ubi: fastmap: Fix add_vol() return value test in ubi_attach_fastmap()" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:26 UTC (permalink / raw)
To: boris.brezillon, dan.carpenter, gregkh, richard, shengyong1
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ubi: fastmap: Fix add_vol() return value test in ubi_attach_fastmap()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ubi-fastmap-fix-add_vol-return-value-test-in-ubi_attach_fastmap.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 40b6e61ac72e99672e47cdb99c8d7d226004169b Mon Sep 17 00:00:00 2001
From: Boris Brezillon <boris.brezillon@free-electrons.com>
Date: Fri, 28 Oct 2016 11:08:44 +0200
Subject: ubi: fastmap: Fix add_vol() return value test in ubi_attach_fastmap()
From: Boris Brezillon <boris.brezillon@free-electrons.com>
commit 40b6e61ac72e99672e47cdb99c8d7d226004169b upstream.
Commit e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already
exists") introduced a bug by changing the possible error codes returned
by add_vol():
- this function no longer returns NULL in case of allocation failure
but return ERR_PTR(-ENOMEM)
- when a duplicate entry in the volume RB tree is found it returns
ERR_PTR(-EEXIST) instead of ERR_PTR(-EINVAL)
Fix the tests done on add_vol() return val to match this new behavior.
Fixes: e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already exists")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Sheng Yong <shengyong1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mtd/ubi/fastmap.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -749,11 +749,11 @@ static int ubi_attach_fastmap(struct ubi
fmvhdr->vol_type,
be32_to_cpu(fmvhdr->last_eb_bytes));
- if (!av)
- goto fail_bad;
- if (PTR_ERR(av) == -EINVAL) {
- ubi_err(ubi, "volume (ID %i) already exists",
- fmvhdr->vol_id);
+ if (IS_ERR(av)) {
+ if (PTR_ERR(av) == -EEXIST)
+ ubi_err(ubi, "volume (ID %i) already exists",
+ fmvhdr->vol_id);
+
goto fail_bad;
}
Patches currently in stable-queue which might be from boris.brezillon@free-electrons.com are
queue-4.4/ubi-fastmap-scrub-peb-when-bitflips-are-detected-in-a-free-peb-ec-header.patch
queue-4.4/ubi-fastmap-fix-add_vol-return-value-test-in-ubi_attach_fastmap.patch
^ permalink raw reply
* Patch "UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:26 UTC (permalink / raw)
To: boris.brezillon, gregkh, richard; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ubi-fastmap-scrub-peb-when-bitflips-are-detected-in-a-free-peb-ec-header.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From ecbfa8eabae9cd73522d1d3d15869703c263d859 Mon Sep 17 00:00:00 2001
From: Boris Brezillon <boris.brezillon@free-electrons.com>
Date: Fri, 16 Sep 2016 16:59:12 +0200
Subject: UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header
From: Boris Brezillon <boris.brezillon@free-electrons.com>
commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream.
scan_pool() does not mark the PEB for scrubing when bitflips are
detected in the EC header of a free PEB (VID header region left to
0xff).
Make sure we scrub the PEB in this case.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mtd/ubi/fastmap.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -513,10 +513,11 @@ static int scan_pool(struct ubi_device *
unsigned long long ec = be64_to_cpu(ech->ec);
unmap_peb(ai, pnum);
dbg_bld("Adding PEB to free: %i", pnum);
+
if (err == UBI_IO_FF_BITFLIPS)
- add_aeb(ai, free, pnum, ec, 1);
- else
- add_aeb(ai, free, pnum, ec, 0);
+ scrub = 1;
+
+ add_aeb(ai, free, pnum, ec, scrub);
continue;
} else if (err == 0 || err == UBI_IO_BITFLIPS) {
dbg_bld("Found non empty PEB:%i in pool", pnum);
Patches currently in stable-queue which might be from boris.brezillon@free-electrons.com are
queue-4.4/ubi-fastmap-scrub-peb-when-bitflips-are-detected-in-a-free-peb-ec-header.patch
queue-4.4/ubi-fastmap-fix-add_vol-return-value-test-in-ubi_attach_fastmap.patch
^ permalink raw reply
* Patch "usb: dwc3: Fix size used in dma_free_coherent()" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 10:26 UTC (permalink / raw)
To: christophe.jaillet, felipe.balbi, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
usb: dwc3: Fix size used in dma_free_coherent()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
usb-dwc3-fix-size-used-in-dma_free_coherent.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 51fbc7c06c8900370c6da5fc4a4685add8fa4fb0 Mon Sep 17 00:00:00 2001
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Fri, 7 Oct 2016 22:12:39 +0200
Subject: usb: dwc3: Fix size used in dma_free_coherent()
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
commit 51fbc7c06c8900370c6da5fc4a4685add8fa4fb0 upstream.
In commit 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support"), the
size of the memory allocated with 'dma_alloc_coherent()' has been modified
but the corresponding calls to 'dma_free_coherent()' have not been updated
accordingly.
This has been spotted with coccinelle, using the following script:
////////////////////
@r@
expression x0, x1, y0, y1, z0, z1, t0, t1, ret;
@@
* ret = dma_alloc_coherent(x0, y0, z0, t0);
...
* dma_free_coherent(x1, y1, ret, t1);
@script:python@
y0 << r.y0;
y1 << r.y1;
@@
if y1.find(y0) == -1:
print "WARNING: sizes look different: '%s' vs '%s'" % (y0, y1)
////////////////////
Fixes: 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2845,7 +2845,7 @@ err3:
kfree(dwc->setup_buf);
err2:
- dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+ dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
dwc->ep0_trb, dwc->ep0_trb_addr);
err1:
@@ -2869,7 +2869,7 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
kfree(dwc->setup_buf);
- dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+ dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
dwc->ep0_trb, dwc->ep0_trb_addr);
dma_free_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
Patches currently in stable-queue which might be from christophe.jaillet@wanadoo.fr are
queue-4.4/usb-dwc3-fix-size-used-in-dma_free_coherent.patch
^ permalink raw reply
* RE: [PATCH] HID:i2c-hid: add a simple quirk to fix device defects
From: Hn Chen @ 2016-11-09 10:26 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: jkosina@suse.cz, dmitry.torokhov@gmail.com,
linux-input@vger.kernel.org
In-Reply-To: <20161109082503.GC10327@mail.corp.redhat.com>
Hi Benjamin,
Just submit patch v2 with comments added and the return value check.
About the return value check, not every time we send command with POWER_ON,
the device was always in the Sleep mode. If the POWER_ON command is executed well(like system boot up),
then just let it leave i2c_hid_set_power().
Hn.chen.
-----Original Message-----
From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com]
Sent: Wednesday, November 09, 2016 4:25 PM
To: Hn Chen
Cc: jkosina@suse.cz; dmitry.torokhov@gmail.com; linux-input@vger.kernel.org
Subject: Re: [PATCH] HID:i2c-hid: add a simple quirk to fix device defects
On Nov 09 2016 or thereabouts, Hn Chen wrote:
> Hi Benjamin,
>
> Ok, I will add a static quirk table and lookup for the quirks in i2c_hid_probe().
>
> About the return value after send the PWR_ON command, it should be failed in weida's case.
> The oscillator of the controller will be gated in the deep sleep mode
> and the controller will be active after the first command but there is no any feedback.
> So should I check the failed return value here ? Or I should check if it is ok and then just return ?
Maybe just add a comment above saying that this is expected to fail on some devices, so there is no point in checking the return value here.
Cheers,
Benjamin
>
> Hn.chen
>
> -----Original Message-----
> From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com]
> Sent: Tuesday, November 08, 2016 5:38 PM
> To: Hn Chen
> Cc: jkosina@suse.cz; dmitry.torokhov@gmail.com;
> linux-input@vger.kernel.org
> Subject: Re: [PATCH] HID:i2c-hid: add a simple quirk to fix device
> defects
>
> On Nov 08 2016 or thereabouts, hn.chen@weidahitech.com wrote:
> > From: HungNien Chen <hn.chen@weidahitech.com>
> >
> > Weida's device can get a quirk value by the quirk function.
> > Base on the quirk value, set_power function will send a command to
> > wake up the device before send the PWR_ON command.
> >
> > Signed-off-by: HungNien Chen <hn.chen@weidahitech.com>
> > ---
> > drivers/hid/hid-ids.h | 5 +++++
> > drivers/hid/i2c-hid/i2c-hid.c | 32 ++++++++++++++++++++++++++++++++
> > 2 files changed, 37 insertions(+)
> >
> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index
> > 6cfb5ca..787afdf 100644
> > --- a/drivers/hid/hid-ids.h
> > +++ b/drivers/hid/hid-ids.h
> > @@ -1033,6 +1033,11 @@
> > #define USB_DEVICE_ID_WALTOP_MEDIA_TABLET_14_1_INCH 0x0500
> > #define USB_DEVICE_ID_WALTOP_SIRIUS_BATTERY_FREE_TABLET 0x0502
> >
> > +#define USB_VENDOR_ID_WEIDA 0x2575
> > +#define USB_DEVICE_ID_WEIDA_8756 0x8756
> > +#define USB_DEVICE_ID_WEIDA_8752 0xC300
> > +#define USB_DEVICE_ID_WEIDA_8755 0xC301
> > +
> > #define USB_VENDOR_ID_WISEGROUP 0x0925
> > #define USB_DEVICE_ID_SMARTJOY_PLUS 0x0005
> > #define USB_DEVICE_ID_SUPER_JOY_BOX_3 0x8888
> > diff --git a/drivers/hid/i2c-hid/i2c-hid.c
> > b/drivers/hid/i2c-hid/i2c-hid.c index b3ec4f2..7a9b100 100644
> > --- a/drivers/hid/i2c-hid/i2c-hid.c
> > +++ b/drivers/hid/i2c-hid/i2c-hid.c
> > @@ -41,6 +41,11 @@
> >
> > #include <linux/i2c/i2c-hid.h>
> >
> > +#include "../hid-ids.h"
> > +
> > +/* quirks to control the device */
> > +#define I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV (1 << 0)
> > +
> > /* flags */
> > #define I2C_HID_STARTED 0
> > #define I2C_HID_RESET_PENDING 1
> > @@ -143,6 +148,7 @@ struct i2c_hid {
> > char *argsbuf; /* Command arguments buffer */
> >
> > unsigned long flags; /* device flags */
> > + unsigned long quirks; /* Various quirks */
> >
> > wait_queue_head_t wait; /* For waiting the interrupt */
> > struct gpio_desc *desc;
> > @@ -154,6 +160,25 @@ struct i2c_hid {
> > struct mutex reset_lock;
> > };
> >
> > +/*
> > + * i2c_hid_lookup_quirk: return any quirks associated with a I2C
> > +HID device
> > + * @idVendor: the 16-bit vendor ID
> > + * @idProduct: the 16-bit product ID
> > + *
> > + * Returns: a u32 quirks value.
> > + */
> > +static u32 i2c_hid_lookup_quirk(const u16 idVendor, const u16
> > +idProduct) {
> > + u32 quirks = 0;
> > +
> > + /* Weida devices check here */
> > + if (idVendor == USB_VENDOR_ID_WEIDA &&
> > + idProduct >= USB_DEVICE_ID_WEIDA_8752)
>
> Wouldn't it make more sense to have a static table of the affected products, instead of this test?
>
> > + return I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV;
> > +
> > + return quirks;
> > +}
> > +
> > static int __i2c_hid_command(struct i2c_client *client,
> > const struct i2c_hid_cmd *command, u8 reportID,
> > u8 reportType, u8 *args, int args_len, @@ -346,6 +371,11 @@
> > static int i2c_hid_set_power(struct i2c_client *client, int
> > power_state)
> >
> > i2c_hid_dbg(ihid, "%s\n", __func__);
> >
> > + /* Some devices require to send a command to wakeup first */
> > + if (power_state == I2C_HID_PWR_ON &&
> > + ihid->quirks & I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV)
> > + i2c_hid_command(client, &hid_set_power_cmd, NULL, 0);
>
> Isn't there a need to check the return value here?
>
> > +
> > ret = __i2c_hid_command(client, &hid_set_power_cmd, power_state,
> > 0, NULL, 0, NULL, 0);
> > if (ret)
> > @@ -661,6 +691,8 @@ static int i2c_hid_parse(struct hid_device *hid)
> >
> > i2c_hid_dbg(ihid, "entering %s\n", __func__);
> >
> > + ihid->quirks = i2c_hid_lookup_quirk(hid->vendor, hid->product);
>
> Please lookup for the quirks in i2c_hid_probe(), right after we set
> version, vendor and product
>
> > +
> > rsize = le16_to_cpu(hdesc->wReportDescLength);
> > if (!rsize || rsize > HID_MAX_DESCRIPTOR_SIZE) {
> > dbg_hid("weird size of report descriptor (%u)\n", rsize);
> > --
> > 1.9.1
> >
>
> Cheers,
> Benjamin
>
^ permalink raw reply
* Patch "ARM: fix oops when using older ARMv4T CPUs" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: rmk+kernel; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: fix oops when using older ARMv4T CPUs
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-fix-oops-when-using-older-armv4t-cpus.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 04946fb60fb157faafa01658dff3131d49f49ccb Mon Sep 17 00:00:00 2001
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 18 Oct 2016 10:24:49 +0100
Subject: ARM: fix oops when using older ARMv4T CPUs
From: Russell King <rmk+kernel@armlinux.org.uk>
commit 04946fb60fb157faafa01658dff3131d49f49ccb upstream.
Alexander Shiyan reports that CLPS711x fails at boot time in the data
exception handler due to a NULL pointer dereference. This is caused by
the late-v4t abort handler overwriting R9 (which becomes zero). Fix
this by making the abort handler save and restore R9.
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c3b58000
[00000008] *pgd=800000000, *pte=00000000, *ppte=feff4140
Internal error: Oops: 63c11817 [#1] PREEMPT ARM
CPU: 0 PID: 448 Comm: ash Not tainted 4.8.1+ #1
Hardware name: Cirrus Logic CLPS711X (Device Tree Support)
task: c39e03a0 ti: c3b4e000 task.ti: c3b4e000
PC is at __dabt_svc+0x4c/0x60
LR is at do_page_fault+0x144/0x2ac
pc : [<c000d3ac>] lr : [<c000fcec>] psr: 60000093
sp : c3b4fe6c ip : 00000001 fp : b6f1bf88
r10: c387a5a0 r9 : 00000000 r8 : e4e0e001
r7 : bee3ef83 r6 : 00100000 r5 : 80000013 r4 : c022fcf8
r3 : 00000000 r2 : 00000008 r1 : bf000000 r0 : 00000000
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0000217f Table: c3b58055 DAC: 00000055
Process ash (pid: 448, stack limit = 0xc3b4e190)
Stack: (0xc3b4fe6c to 0xc3b50000)
fe60: bee3ef83 c05168d1 ffffffff 00000000 c3adfe80
fe80: c3a03300 00000000 c3b4fed0 c3a03400 bee3ef83 c387a5a0 b6f1bf88 00000001
fea0: c3b4febc 00000076 c022fcf8 80000013 ffffffff 0000003f bf000000 bee3ef83
fec0: 00000004 00000000 c3adfe80 c00e432c 00000812 00000005 00000001 00000006
fee0: b6f1b000 00000000 00010000 0003c944 0004d000 0004d439 00010000 b6f1b000
ff00: 00000005 00000000 00015ecc c3b4fed0 0000000a 00000000 00000000 c00a1dc0
ff20: befff000 c3a03300 c3b4e000 c0507cd8 c0508024 fffffff8 c3a03300 00000000
ff40: c0516a58 c00a35bc c39e03a0 000001c0 bea84ce8 0004e008 c3b3a000 c00a3ac0
ff60: c3b40374 c3b3a000 bea84d11 00000000 c0500188 bea84d11 bea84ce8 00000001
ff80: 0000000b c000a304 c3b4e000 00000000 bea84ce4 c00a3cd0 00000000 bea84d11
ffa0: bea84ce8 c000a160 bea84d11 bea84ce8 bea84d11 bea84ce8 0004e008 0004d450
ffc0: bea84d11 bea84ce8 00000001 0000000b b6f45ee4 00000000 b6f5ff70 bea84ce4
ffe0: b6f2f130 bea84cb0 b6f2f194 b6ef29f4 a0000010 bea84d11 02c7cffa 02c7cffd
[<c000d3ac>] (__dabt_svc) from [<c022fcf8>] (__copy_to_user_std+0xf8/0x330)
[<c022fcf8>] (__copy_to_user_std) from [<c00e432c>]
+(load_elf_binary+0x920/0x107c)
[<c00e432c>] (load_elf_binary) from [<c00a35bc>]
+(search_binary_handler+0x80/0x16c)
[<c00a35bc>] (search_binary_handler) from [<c00a3ac0>]
+(do_execveat_common+0x418/0x600)
[<c00a3ac0>] (do_execveat_common) from [<c00a3cd0>] (do_execve+0x28/0x30)
[<c00a3cd0>] (do_execve) from [<c000a160>] (ret_fast_syscall+0x0/0x30)
Code: e1a0200d eb00136b e321f093 e59d104c (e5891008)
---[ end trace 4b4f8086ebef98c5 ]---
Fixes: e6978e4bf181 ("ARM: save and reset the address limit when entering an exception")
Reported-by: Alexander Shiyan <shc_work@mail.ru>
Tested-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mm/abort-lv4t.S | 34 ++++++++++++++++++++++++----------
1 file changed, 24 insertions(+), 10 deletions(-)
--- a/arch/arm/mm/abort-lv4t.S
+++ b/arch/arm/mm/abort-lv4t.S
@@ -7,7 +7,7 @@
* : r4 = aborted context pc
* : r5 = aborted context psr
*
- * Returns : r4-r5, r10-r11, r13 preserved
+ * Returns : r4-r5, r9-r11, r13 preserved
*
* Purpose : obtain information about current aborted instruction.
* Note: we read user space. This means we might cause a data
@@ -48,7 +48,10 @@ ENTRY(v4t_late_abort)
/* c */ b do_DataAbort @ ldc rd, [rn], #m @ Same as ldr rd, [rn], #m
/* d */ b do_DataAbort @ ldc rd, [rn, #m]
/* e */ b .data_unknown
-/* f */
+/* f */ b .data_unknown
+
+.data_unknown_r9:
+ ldr r9, [sp], #4
.data_unknown: @ Part of jumptable
mov r0, r4
mov r1, r8
@@ -57,6 +60,7 @@ ENTRY(v4t_late_abort)
.data_arm_ldmstm:
tst r8, #1 << 21 @ check writeback bit
beq do_DataAbort @ no writeback -> no fixup
+ str r9, [sp, #-4]!
mov r7, #0x11
orr r7, r7, #0x1100
and r6, r8, r7
@@ -75,12 +79,14 @@ ENTRY(v4t_late_abort)
subne r7, r7, r6, lsl #2 @ Undo increment
addeq r7, r7, r6, lsl #2 @ Undo decrement
str r7, [r2, r9, lsr #14] @ Put register 'Rn'
+ ldr r9, [sp], #4
b do_DataAbort
.data_arm_lateldrhpre:
tst r8, #1 << 21 @ Check writeback bit
beq do_DataAbort @ No writeback -> no fixup
.data_arm_lateldrhpost:
+ str r9, [sp, #-4]!
and r9, r8, #0x00f @ get Rm / low nibble of immediate value
tst r8, #1 << 22 @ if (immediate offset)
andne r6, r8, #0xf00 @ { immediate high nibble
@@ -93,6 +99,7 @@ ENTRY(v4t_late_abort)
subne r7, r7, r6 @ Undo incrmenet
addeq r7, r7, r6 @ Undo decrement
str r7, [r2, r9, lsr #14] @ Put register 'Rn'
+ ldr r9, [sp], #4
b do_DataAbort
.data_arm_lateldrpreconst:
@@ -101,12 +108,14 @@ ENTRY(v4t_late_abort)
.data_arm_lateldrpostconst:
movs r6, r8, lsl #20 @ Get offset
beq do_DataAbort @ zero -> no fixup
+ str r9, [sp, #-4]!
and r9, r8, #15 << 16 @ Extract 'n' from instruction
ldr r7, [r2, r9, lsr #14] @ Get register 'Rn'
tst r8, #1 << 23 @ Check U bit
subne r7, r7, r6, lsr #20 @ Undo increment
addeq r7, r7, r6, lsr #20 @ Undo decrement
str r7, [r2, r9, lsr #14] @ Put register 'Rn'
+ ldr r9, [sp], #4
b do_DataAbort
.data_arm_lateldrprereg:
@@ -115,6 +124,7 @@ ENTRY(v4t_late_abort)
.data_arm_lateldrpostreg:
and r7, r8, #15 @ Extract 'm' from instruction
ldr r6, [r2, r7, lsl #2] @ Get register 'Rm'
+ str r9, [sp, #-4]!
mov r9, r8, lsr #7 @ get shift count
ands r9, r9, #31
and r7, r8, #0x70 @ get shift type
@@ -126,33 +136,33 @@ ENTRY(v4t_late_abort)
b .data_arm_apply_r6_and_rn
b .data_arm_apply_r6_and_rn @ 1: LSL #0
nop
- b .data_unknown @ 2: MUL?
+ b .data_unknown_r9 @ 2: MUL?
nop
- b .data_unknown @ 3: MUL?
+ b .data_unknown_r9 @ 3: MUL?
nop
mov r6, r6, lsr r9 @ 4: LSR #!0
b .data_arm_apply_r6_and_rn
mov r6, r6, lsr #32 @ 5: LSR #32
b .data_arm_apply_r6_and_rn
- b .data_unknown @ 6: MUL?
+ b .data_unknown_r9 @ 6: MUL?
nop
- b .data_unknown @ 7: MUL?
+ b .data_unknown_r9 @ 7: MUL?
nop
mov r6, r6, asr r9 @ 8: ASR #!0
b .data_arm_apply_r6_and_rn
mov r6, r6, asr #32 @ 9: ASR #32
b .data_arm_apply_r6_and_rn
- b .data_unknown @ A: MUL?
+ b .data_unknown_r9 @ A: MUL?
nop
- b .data_unknown @ B: MUL?
+ b .data_unknown_r9 @ B: MUL?
nop
mov r6, r6, ror r9 @ C: ROR #!0
b .data_arm_apply_r6_and_rn
mov r6, r6, rrx @ D: RRX
b .data_arm_apply_r6_and_rn
- b .data_unknown @ E: MUL?
+ b .data_unknown_r9 @ E: MUL?
nop
- b .data_unknown @ F: MUL?
+ b .data_unknown_r9 @ F: MUL?
.data_thumb_abort:
ldrh r8, [r4] @ read instruction
@@ -190,6 +200,7 @@ ENTRY(v4t_late_abort)
.data_thumb_pushpop:
tst r8, #1 << 10
beq .data_unknown
+ str r9, [sp, #-4]!
and r6, r8, #0x55 @ hweight8(r8) + R bit
and r9, r8, #0xaa
add r6, r6, r9, lsr #1
@@ -204,9 +215,11 @@ ENTRY(v4t_late_abort)
addeq r7, r7, r6, lsl #2 @ increment SP if PUSH
subne r7, r7, r6, lsl #2 @ decrement SP if POP
str r7, [r2, #13 << 2]
+ ldr r9, [sp], #4
b do_DataAbort
.data_thumb_ldmstm:
+ str r9, [sp, #-4]!
and r6, r8, #0x55 @ hweight8(r8)
and r9, r8, #0xaa
add r6, r6, r9, lsr #1
@@ -219,4 +232,5 @@ ENTRY(v4t_late_abort)
and r6, r6, #15 @ number of regs to transfer
sub r7, r7, r6, lsl #2 @ always decrement
str r7, [r2, r9, lsr #6]
+ ldr r9, [sp], #4
b do_DataAbort
Patches currently in stable-queue which might be from rmk+kernel@armlinux.org.uk are
queue-4.8/arm-fix-oops-when-using-older-armv4t-cpus.patch
^ permalink raw reply
* Patch "btrfs: qgroup: Prevent qgroup->reserved from going subzero" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: rgoldwyn, dsterba, gregkh, quwenruo; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
btrfs: qgroup: Prevent qgroup->reserved from going subzero
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
btrfs-qgroup-prevent-qgroup-reserved-from-going-subzero.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 0b34c261e235a5c74dcf78bd305845bd15fe2b42 Mon Sep 17 00:00:00 2001
From: Goldwyn Rodrigues <rgoldwyn@suse.com>
Date: Fri, 30 Sep 2016 10:40:52 -0500
Subject: btrfs: qgroup: Prevent qgroup->reserved from going subzero
From: Goldwyn Rodrigues <rgoldwyn@suse.com>
commit 0b34c261e235a5c74dcf78bd305845bd15fe2b42 upstream.
While free'ing qgroup->reserved resources, we much check if
the page has not been invalidated by a truncate operation
by checking if the page is still dirty before reducing the
qgroup resources. Resources in such a case are free'd when
the entire extent is released by delayed_ref.
This fixes a double accounting while releasing resources
in case of truncating a file, reproduced by the following testcase.
SCRATCH_DEV=/dev/vdb
SCRATCH_MNT=/mnt
mkfs.btrfs -f $SCRATCH_DEV
mount -t btrfs $SCRATCH_DEV $SCRATCH_MNT
cd $SCRATCH_MNT
btrfs quota enable $SCRATCH_MNT
btrfs subvolume create a
btrfs qgroup limit 500m a $SCRATCH_MNT
sync
for c in {1..15}; do
dd if=/dev/zero bs=1M count=40 of=$SCRATCH_MNT/a/file;
done
sleep 10
sync
sleep 5
touch $SCRATCH_MNT/a/newfile
echo "Removing file"
rm $SCRATCH_MNT/a/file
Fixes: b9d0b38928 ("btrfs: Add handler for invalidate page")
Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Reviewed-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/btrfs/inode.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -8915,9 +8915,14 @@ again:
* So even we call qgroup_free_data(), it won't decrease reserved
* space.
* 2) Not written to disk
- * This means the reserved space should be freed here.
+ * This means the reserved space should be freed here. However,
+ * if a truncate invalidates the page (by clearing PageDirty)
+ * and the page is accounted for while allocating extent
+ * in btrfs_check_data_free_space() we let delayed_ref to
+ * free the entire extent.
*/
- btrfs_qgroup_free_data(inode, page_start, PAGE_SIZE);
+ if (PageDirty(page))
+ btrfs_qgroup_free_data(inode, page_start, PAGE_SIZE);
if (!inode_evicting) {
clear_extent_bit(tree, page_start, page_end,
EXTENT_LOCKED | EXTENT_DIRTY |
Patches currently in stable-queue which might be from rgoldwyn@suse.com are
queue-4.8/btrfs-qgroup-prevent-qgroup-reserved-from-going-subzero.patch
^ permalink raw reply
* Patch "HID: usbhid: add ATEN CS962 to list of quirky devices" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: oneukum, gregkh, jkosina; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
HID: usbhid: add ATEN CS962 to list of quirky devices
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
hid-usbhid-add-aten-cs962-to-list-of-quirky-devices.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From cf0ea4da4c7df11f7a508b2f37518e0f117f3791 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Thu, 3 Nov 2016 12:31:41 +0100
Subject: HID: usbhid: add ATEN CS962 to list of quirky devices
From: Oliver Neukum <oneukum@suse.com>
commit cf0ea4da4c7df11f7a508b2f37518e0f117f3791 upstream.
Like many similar devices it needs a quirk to work.
Issuing the request gets the device into an irrecoverable state.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -179,6 +179,7 @@
#define USB_DEVICE_ID_ATEN_4PORTKVM 0x2205
#define USB_DEVICE_ID_ATEN_4PORTKVMC 0x2208
#define USB_DEVICE_ID_ATEN_CS682 0x2213
+#define USB_DEVICE_ID_ATEN_CS692 0x8021
#define USB_VENDOR_ID_ATMEL 0x03eb
#define USB_DEVICE_ID_ATMEL_MULTITOUCH 0x211c
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -63,6 +63,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVM, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_4PORTKVMC, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS682, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_ATEN, USB_DEVICE_ID_ATEN_CS692, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FIGHTERSTICK, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_COMBATSTICK, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_FLIGHT_SIM_ECLIPSE_YOKE, HID_QUIRK_NOGET },
Patches currently in stable-queue which might be from oneukum@suse.com are
queue-4.8/hid-usbhid-add-aten-cs962-to-list-of-quirky-devices.patch
^ permalink raw reply
* Patch "kvm: x86: Check memopp before dereference (CVE-2016-8630)" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: osh, gregkh, pbonzini; +Cc: stable, stable-commits
In-Reply-To: <1477592752-126650-2-git-send-email-osh@google.com>
This is a note to let you know that I've just added the patch titled
kvm: x86: Check memopp before dereference (CVE-2016-8630)
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
kvm-x86-check-memopp-before-dereference-cve-2016-8630.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d9092f52d7e61dd1557f2db2400ddb430e85937e Mon Sep 17 00:00:00 2001
From: Owen Hofmann <osh@google.com>
Date: Thu, 27 Oct 2016 11:25:52 -0700
Subject: kvm: x86: Check memopp before dereference (CVE-2016-8630)
From: Owen Hofmann <osh@google.com>
commit d9092f52d7e61dd1557f2db2400ddb430e85937e upstream.
Commit 41061cdb98 ("KVM: emulate: do not initialize memopp") removes a
check for non-NULL under incorrect assumptions. An undefined instruction
with a ModR/M byte with Mod=0 and R/M-5 (e.g. 0xc7 0x15) will attempt
to dereference a null pointer here.
Fixes: 41061cdb98a0bec464278b4db8e894a3121671f5
Message-Id: <1477592752-126650-2-git-send-email-osh@google.com>
Signed-off-by: Owen Hofmann <osh@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/emulate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -5045,7 +5045,7 @@ done_prefixes:
/* Decode and fetch the destination operand: register or memory. */
rc = decode_operand(ctxt, &ctxt->dst, (ctxt->d >> DstShift) & OpMask);
- if (ctxt->rip_relative)
+ if (ctxt->rip_relative && likely(ctxt->memopp))
ctxt->memopp->addr.mem.ea = address_mask(ctxt,
ctxt->memopp->addr.mem.ea + ctxt->_eip);
Patches currently in stable-queue which might be from osh@google.com are
queue-4.8/kvm-x86-check-memopp-before-dereference-cve-2016-8630.patch
^ permalink raw reply
* Patch "cpufreq: intel_pstate: Set P-state upfront in performance mode" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: rafael.j.wysocki, gregkh, srinivas.pandruvada; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
cpufreq: intel_pstate: Set P-state upfront in performance mode
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
cpufreq-intel_pstate-set-p-state-upfront-in-performance-mode.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From a6c6ead14183ea4ec8ce7551e1f3451024b9c4db Mon Sep 17 00:00:00 2001
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Date: Wed, 19 Oct 2016 02:57:22 +0200
Subject: cpufreq: intel_pstate: Set P-state upfront in performance mode
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
commit a6c6ead14183ea4ec8ce7551e1f3451024b9c4db upstream.
After commit a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with
utilization update callbacks) the cpufreq governor callbacks may not
be invoked on NOHZ_FULL CPUs and, in particular, switching to the
"performance" policy via sysfs may not have any effect on them. That
is a problem, because it usually is desirable to squeeze the last
bit of performance out of those CPUs, so work around it by setting
the maximum P-state (within the limits) in intel_pstate_set_policy()
upfront when the policy is CPUFREQ_POLICY_PERFORMANCE.
Fixes: a4675fbc4a7a (cpufreq: intel_pstate: Replace timers with utilization update callbacks)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/cpufreq/intel_pstate.c | 29 +++++++++++++++++++++++++----
1 file changed, 25 insertions(+), 4 deletions(-)
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -1133,10 +1133,8 @@ static void intel_pstate_get_min_max(str
*min = clamp_t(int, min_perf, cpu->pstate.min_pstate, max_perf);
}
-static void intel_pstate_set_min_pstate(struct cpudata *cpu)
+static void intel_pstate_set_pstate(struct cpudata *cpu, int pstate)
{
- int pstate = cpu->pstate.min_pstate;
-
trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
cpu->pstate.current_pstate = pstate;
/*
@@ -1148,6 +1146,20 @@ static void intel_pstate_set_min_pstate(
pstate_funcs.get_val(cpu, pstate));
}
+static void intel_pstate_set_min_pstate(struct cpudata *cpu)
+{
+ intel_pstate_set_pstate(cpu, cpu->pstate.min_pstate);
+}
+
+static void intel_pstate_max_within_limits(struct cpudata *cpu)
+{
+ int min_pstate, max_pstate;
+
+ update_turbo_state();
+ intel_pstate_get_min_max(cpu, &min_pstate, &max_pstate);
+ intel_pstate_set_pstate(cpu, max_pstate);
+}
+
static void intel_pstate_get_cpu_pstates(struct cpudata *cpu)
{
cpu->pstate.min_pstate = pstate_funcs.get_min();
@@ -1465,7 +1477,7 @@ static int intel_pstate_set_policy(struc
pr_debug("set_policy cpuinfo.max %u policy->max %u\n",
policy->cpuinfo.max_freq, policy->max);
- cpu = all_cpu_data[0];
+ cpu = all_cpu_data[policy->cpu];
if (cpu->pstate.max_pstate_physical > cpu->pstate.max_pstate &&
policy->max < policy->cpuinfo.max_freq &&
policy->max > cpu->pstate.max_pstate * cpu->pstate.scaling) {
@@ -1509,6 +1521,15 @@ static int intel_pstate_set_policy(struc
limits->max_perf = round_up(limits->max_perf, FRAC_BITS);
out:
+ if (policy->policy == CPUFREQ_POLICY_PERFORMANCE) {
+ /*
+ * NOHZ_FULL CPUs need this as the governor callback may not
+ * be invoked on them.
+ */
+ intel_pstate_clear_update_util_hook(policy->cpu);
+ intel_pstate_max_within_limits(cpu);
+ }
+
intel_pstate_set_update_util_hook(policy->cpu);
intel_pstate_hwp_set_policy(policy);
Patches currently in stable-queue which might be from rafael.j.wysocki@intel.com are
queue-4.8/cpufreq-intel_pstate-set-p-state-upfront-in-performance-mode.patch
^ permalink raw reply
* Patch "pwm: Unexport children before chip removal" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: davidhsu, gregkh, thierry.reding; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
pwm: Unexport children before chip removal
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
pwm-unexport-children-before-chip-removal.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 0733424c9ba9f42242409d1ece780777272f7ea1 Mon Sep 17 00:00:00 2001
From: David Hsu <davidhsu@google.com>
Date: Tue, 9 Aug 2016 14:57:46 -0700
Subject: pwm: Unexport children before chip removal
From: David Hsu <davidhsu@google.com>
commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream.
Exported pwm channels aren't removed before the pwmchip and are
leaked. This results in invalid sysfs files. This fix removes
all exported pwm channels before chip removal.
Signed-off-by: David Hsu <davidhsu@google.com>
Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pwm/core.c | 2 ++
drivers/pwm/sysfs.c | 18 ++++++++++++++++++
include/linux/pwm.h | 5 +++++
3 files changed, 25 insertions(+)
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -339,6 +339,8 @@ int pwmchip_remove(struct pwm_chip *chip
unsigned int i;
int ret = 0;
+ pwmchip_sysfs_unexport_children(chip);
+
mutex_lock(&pwm_lock);
for (i = 0; i < chip->npwm; i++) {
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -409,6 +409,24 @@ void pwmchip_sysfs_unexport(struct pwm_c
}
}
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+ struct device *parent;
+ unsigned int i;
+
+ parent = class_find_device(&pwm_class, NULL, chip,
+ pwmchip_sysfs_match);
+ if (!parent)
+ return;
+
+ for (i = 0; i < chip->npwm; i++) {
+ struct pwm_device *pwm = &chip->pwms[i];
+
+ if (test_bit(PWMF_EXPORTED, &pwm->flags))
+ pwm_unexport_child(parent, pwm);
+ }
+}
+
static int __init pwm_sysfs_init(void)
{
return class_register(&pwm_class);
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -641,6 +641,7 @@ static inline void pwm_remove_table(stru
#ifdef CONFIG_PWM_SYSFS
void pwmchip_sysfs_export(struct pwm_chip *chip);
void pwmchip_sysfs_unexport(struct pwm_chip *chip);
+void pwmchip_sysfs_unexport_children(struct pwm_chip *chip);
#else
static inline void pwmchip_sysfs_export(struct pwm_chip *chip)
{
@@ -649,6 +650,10 @@ static inline void pwmchip_sysfs_export(
static inline void pwmchip_sysfs_unexport(struct pwm_chip *chip)
{
}
+
+static inline void pwmchip_sysfs_unexport_children(struct pwm_chip *chip)
+{
+}
#endif /* CONFIG_PWM_SYSFS */
#endif /* __LINUX_PWM_H */
Patches currently in stable-queue which might be from davidhsu@google.com are
queue-4.8/pwm-unexport-children-before-chip-removal.patch
^ permalink raw reply
* Patch "omapfb: fix return value check in dsi_bind()" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: weiyongjun1, gregkh, peter.ujfalusi, tomi.valkeinen
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
omapfb: fix return value check in dsi_bind()
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
omapfb-fix-return-value-check-in-dsi_bind.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 43da7575cdecaf5af2d6b3f3a9e4e6c9144be428 Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Sat, 17 Sep 2016 15:53:34 +0000
Subject: omapfb: fix return value check in dsi_bind()
From: Wei Yongjun <weiyongjun1@huawei.com>
commit 43da7575cdecaf5af2d6b3f3a9e4e6c9144be428 upstream.
Fix the retrn value check which testing the wrong variable
in dsi_bind().
Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
@@ -5348,7 +5348,7 @@ static int dsi_bind(struct device *dev,
dsi->phy_base = devm_ioremap(&dsidev->dev, res->start,
resource_size(res));
- if (!dsi->proto_base) {
+ if (!dsi->phy_base) {
DSSERR("can't ioremap DSI PHY\n");
return -ENOMEM;
}
@@ -5368,7 +5368,7 @@ static int dsi_bind(struct device *dev,
dsi->pll_base = devm_ioremap(&dsidev->dev, res->start,
resource_size(res));
- if (!dsi->proto_base) {
+ if (!dsi->pll_base) {
DSSERR("can't ioremap DSI PLL\n");
return -ENOMEM;
}
Patches currently in stable-queue which might be from weiyongjun1@huawei.com are
queue-4.8/omapfb-fix-return-value-check-in-dsi_bind.patch
^ permalink raw reply
* Patch "uapi: add missing install of sync_file.h" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: emilio.lopez, gregkh, gustavo.padovan, mpe, seanpaul
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
uapi: add missing install of sync_file.h
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
uapi-add-missing-install-of-sync_file.h.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 58f0f9f75c1b94dabbfc3daa333a4e68536b0a42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Emilio=20L=C3=B3pez?= <emilio.lopez@collabora.co.uk>
Date: Tue, 27 Sep 2016 11:31:42 -0300
Subject: uapi: add missing install of sync_file.h
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Emilio López <emilio.lopez@collabora.co.uk>
commit 58f0f9f75c1b94dabbfc3daa333a4e68536b0a42 upstream.
As part of the sync framework destaging, the sync_file.h header
was moved, but an entry was not added on Kbuild to install it.
This patch resolves this omission so that "make headers_install"
installs this header.
Fixes: 460bfc41fd52 ("dma-buf/sync_file: de-stage sync_file headers")
Reported-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Emilio López <emilio.lopez@collabora.co.uk>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20160927143142.8975-1-emilio.lopez@collabora.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/uapi/linux/Kbuild | 1 +
1 file changed, 1 insertion(+)
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -396,6 +396,7 @@ header-y += string.h
header-y += suspend_ioctls.h
header-y += swab.h
header-y += synclink.h
+header-y += sync_file.h
header-y += sysctl.h
header-y += sysinfo.h
header-y += target_core_user.h
Patches currently in stable-queue which might be from emilio.lopez@collabora.co.uk are
queue-4.8/uapi-add-missing-install-of-sync_file.h.patch
^ permalink raw reply
* Patch "tty: vt, fix bogus division in csi_J" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: jslaby, gregkh, ppisar; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
tty: vt, fix bogus division in csi_J
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
tty-vt-fix-bogus-division-in-csi_j.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 42acfc6615f47e465731c263bee0c799edb098f2 Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Mon, 3 Oct 2016 11:00:17 +0200
Subject: tty: vt, fix bogus division in csi_J
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Jiri Slaby <jslaby@suse.cz>
commit 42acfc6615f47e465731c263bee0c799edb098f2 upstream.
In csi_J(3), the third parameter of scr_memsetw (vc_screenbuf_size) is
divided by 2 inappropriatelly. But scr_memsetw expects size, not
count, because it divides the size by 2 on its own before doing actual
memset-by-words.
So remove the bogus division.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Petr Písař <ppisar@redhat.com>
Fixes: f8df13e0a9 (tty: Clean console safely)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/vt/vt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1181,7 +1181,7 @@ static void csi_J(struct vc_data *vc, in
break;
case 3: /* erase scroll-back buffer (and whole display) */
scr_memsetw(vc->vc_screenbuf, vc->vc_video_erase_char,
- vc->vc_screenbuf_size >> 1);
+ vc->vc_screenbuf_size);
set_origin(vc);
if (con_is_visible(vc))
update_screen(vc);
Patches currently in stable-queue which might be from jslaby@suse.cz are
queue-4.8/tty-vt-fix-bogus-division-in-csi_j.patch
^ permalink raw reply
* Patch "UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: boris.brezillon, gregkh, richard; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ubi-fastmap-scrub-peb-when-bitflips-are-detected-in-a-free-peb-ec-header.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From ecbfa8eabae9cd73522d1d3d15869703c263d859 Mon Sep 17 00:00:00 2001
From: Boris Brezillon <boris.brezillon@free-electrons.com>
Date: Fri, 16 Sep 2016 16:59:12 +0200
Subject: UBI: fastmap: scrub PEB when bitflips are detected in a free PEB EC header
From: Boris Brezillon <boris.brezillon@free-electrons.com>
commit ecbfa8eabae9cd73522d1d3d15869703c263d859 upstream.
scan_pool() does not mark the PEB for scrubing when bitflips are
detected in the EC header of a free PEB (VID header region left to
0xff).
Make sure we scrub the PEB in this case.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mtd/ubi/fastmap.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -515,10 +515,11 @@ static int scan_pool(struct ubi_device *
unsigned long long ec = be64_to_cpu(ech->ec);
unmap_peb(ai, pnum);
dbg_bld("Adding PEB to free: %i", pnum);
+
if (err == UBI_IO_FF_BITFLIPS)
- add_aeb(ai, free, pnum, ec, 1);
- else
- add_aeb(ai, free, pnum, ec, 0);
+ scrub = 1;
+
+ add_aeb(ai, free, pnum, ec, scrub);
continue;
} else if (err == 0 || err == UBI_IO_BITFLIPS) {
dbg_bld("Found non empty PEB:%i in pool", pnum);
Patches currently in stable-queue which might be from boris.brezillon@free-electrons.com are
queue-4.8/ubi-fastmap-scrub-peb-when-bitflips-are-detected-in-a-free-peb-ec-header.patch
queue-4.8/ubi-fastmap-fix-add_vol-return-value-test-in-ubi_attach_fastmap.patch
^ permalink raw reply
* Patch "ubi: fastmap: Fix add_vol() return value test in ubi_attach_fastmap()" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: boris.brezillon, dan.carpenter, gregkh, richard, shengyong1
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ubi: fastmap: Fix add_vol() return value test in ubi_attach_fastmap()
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ubi-fastmap-fix-add_vol-return-value-test-in-ubi_attach_fastmap.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 40b6e61ac72e99672e47cdb99c8d7d226004169b Mon Sep 17 00:00:00 2001
From: Boris Brezillon <boris.brezillon@free-electrons.com>
Date: Fri, 28 Oct 2016 11:08:44 +0200
Subject: ubi: fastmap: Fix add_vol() return value test in ubi_attach_fastmap()
From: Boris Brezillon <boris.brezillon@free-electrons.com>
commit 40b6e61ac72e99672e47cdb99c8d7d226004169b upstream.
Commit e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already
exists") introduced a bug by changing the possible error codes returned
by add_vol():
- this function no longer returns NULL in case of allocation failure
but return ERR_PTR(-ENOMEM)
- when a duplicate entry in the volume RB tree is found it returns
ERR_PTR(-EEXIST) instead of ERR_PTR(-EINVAL)
Fix the tests done on add_vol() return val to match this new behavior.
Fixes: e96a8a3bb671 ("UBI: Fastmap: Do not add vol if it already exists")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Sheng Yong <shengyong1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mtd/ubi/fastmap.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/mtd/ubi/fastmap.c
+++ b/drivers/mtd/ubi/fastmap.c
@@ -751,11 +751,11 @@ static int ubi_attach_fastmap(struct ubi
fmvhdr->vol_type,
be32_to_cpu(fmvhdr->last_eb_bytes));
- if (!av)
- goto fail_bad;
- if (PTR_ERR(av) == -EINVAL) {
- ubi_err(ubi, "volume (ID %i) already exists",
- fmvhdr->vol_id);
+ if (IS_ERR(av)) {
+ if (PTR_ERR(av) == -EEXIST)
+ ubi_err(ubi, "volume (ID %i) already exists",
+ fmvhdr->vol_id);
+
goto fail_bad;
}
Patches currently in stable-queue which might be from boris.brezillon@free-electrons.com are
queue-4.8/ubi-fastmap-scrub-peb-when-bitflips-are-detected-in-a-free-peb-ec-header.patch
queue-4.8/ubi-fastmap-fix-add_vol-return-value-test-in-ubi_attach_fastmap.patch
^ permalink raw reply
* Patch "usb: dwc3: Fix size used in dma_free_coherent()" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 10:27 UTC (permalink / raw)
To: christophe.jaillet, felipe.balbi, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
usb: dwc3: Fix size used in dma_free_coherent()
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
usb-dwc3-fix-size-used-in-dma_free_coherent.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 51fbc7c06c8900370c6da5fc4a4685add8fa4fb0 Mon Sep 17 00:00:00 2001
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Fri, 7 Oct 2016 22:12:39 +0200
Subject: usb: dwc3: Fix size used in dma_free_coherent()
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
commit 51fbc7c06c8900370c6da5fc4a4685add8fa4fb0 upstream.
In commit 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support"), the
size of the memory allocated with 'dma_alloc_coherent()' has been modified
but the corresponding calls to 'dma_free_coherent()' have not been updated
accordingly.
This has been spotted with coccinelle, using the following script:
////////////////////
@r@
expression x0, x1, y0, y1, z0, z1, t0, t1, ret;
@@
* ret = dma_alloc_coherent(x0, y0, z0, t0);
...
* dma_free_coherent(x1, y1, ret, t1);
@script:python@
y0 << r.y0;
y1 << r.y1;
@@
if y1.find(y0) == -1:
print "WARNING: sizes look different: '%s' vs '%s'" % (y0, y1)
////////////////////
Fixes: 2abd9d5fa60f9 ("usb: dwc3: ep0: Add chained TRB support")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -3055,7 +3055,7 @@ err3:
kfree(dwc->setup_buf);
err2:
- dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+ dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
dwc->ep0_trb, dwc->ep0_trb_addr);
err1:
@@ -3080,7 +3080,7 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
kfree(dwc->setup_buf);
kfree(dwc->zlp_buf);
- dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+ dma_free_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
dwc->ep0_trb, dwc->ep0_trb_addr);
dma_free_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
Patches currently in stable-queue which might be from christophe.jaillet@wanadoo.fr are
queue-4.8/usb-dwc3-fix-size-used-in-dma_free_coherent.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.