This is a note to let you know that I've just added the patch titled
pty: cancel pty slave port buf's work in tty_release
to the 4.9-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:
pty-cancel-pty-slave-port-buf-s-work-in-tty_release.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:40:24 CET 2018
From: Sahara <keun-o.park(a)darkmatter.ae>
Date: Wed, 13 Dec 2017 09:10:48 +0400
Subject: pty: cancel pty slave port buf's work in tty_release
From: Sahara <keun-o.park(a)darkmatter.ae>
[ Upstream commit 2b022ab7542df60021ab57854b3faaaf42552eaf ]
In case that CONFIG_SLUB_DEBUG is on and pty is used, races between
release_one_tty and flush_to_ldisc work threads may happen and lead
to use-after-free condition on tty->link->port. Because SLUB_DEBUG
is turned on, freed tty->link->port is filled with POISON_FREE value.
So far without SLUB_DEBUG, port was filled with zero and flush_to_ldisc
could return without a problem by checking if tty is NULL.
CPU 0 CPU 1
----- -----
release_tty pty_write
cancel_work_sync(tty) to = tty->link
tty_kref_put(tty->link) tty_schedule_flip(to->port)
<< workqueue >> ...
release_one_tty ...
pty_cleanup ...
kfree(tty->link->port) << workqueue >>
flush_to_ldisc
tty = READ_ONCE(port->itty)
tty is 0x6b6b6b6b6b6b6b6b
!!PANIC!! access tty->ldisc
Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b93
pgd = ffffffc0eb1c3000
[6b6b6b6b6b6b6b93] *pgd=0000000000000000, *pud=0000000000000000
------------[ cut here ]------------
Kernel BUG at ffffff800851154c [verbose debug info unavailable]
Internal error: Oops - BUG: 96000004 [#1] PREEMPT SMP
CPU: 3 PID: 265 Comm: kworker/u8:9 Tainted: G W 3.18.31-g0a58eeb #1
Hardware name: Qualcomm Technologies, Inc. MSM 8996pro v1.1 + PMI8996 Carbide (DT)
Workqueue: events_unbound flush_to_ldisc
task: ffffffc0ed610ec0 ti: ffffffc0ed624000 task.ti: ffffffc0ed624000
PC is at ldsem_down_read_trylock+0x0/0x4c
LR is at tty_ldisc_ref+0x24/0x4c
pc : [<ffffff800851154c>] lr : [<ffffff800850f6c0>] pstate: 80400145
sp : ffffffc0ed627cd0
x29: ffffffc0ed627cd0 x28: 0000000000000000
x27: ffffff8009e05000 x26: ffffffc0d382cfa0
x25: 0000000000000000 x24: ffffff800a012f08
x23: 0000000000000000 x22: ffffffc0703fbc88
x21: 6b6b6b6b6b6b6b6b x20: 6b6b6b6b6b6b6b93
x19: 0000000000000000 x18: 0000000000000001
x17: 00e80000f80d6f53 x16: 0000000000000001
x15: 0000007f7d826fff x14: 00000000000000a0
x13: 0000000000000000 x12: 0000000000000109
x11: 0000000000000000 x10: 0000000000000000
x9 : ffffffc0ed624000 x8 : ffffffc0ed611580
x7 : 0000000000000000 x6 : ffffff800a42e000
x5 : 00000000000003fc x4 : 0000000003bd1201
x3 : 0000000000000001 x2 : 0000000000000001
x1 : ffffff800851004c x0 : 6b6b6b6b6b6b6b93
Signed-off-by: Sahara <keun-o.park(a)darkmatter.ae>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/tty_io.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1702,6 +1702,8 @@ static void release_tty(struct tty_struc
if (tty->link)
tty->link->port->itty = NULL;
tty_buffer_cancel_work(tty->port);
+ if (tty->link)
+ tty_buffer_cancel_work(tty->link->port);
tty_kref_put(tty->link);
tty_kref_put(tty);
Patches currently in stable-queue which might be from keun-o.park(a)darkmatter.ae are
queue-4.9/pty-cancel-pty-slave-port-buf-s-work-in-tty_release.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Remove SAO feature from Power9 DD1
to the 4.9-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:
powerpc-64s-remove-sao-feature-from-power9-dd1.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:40:23 CET 2018
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Wed, 19 Apr 2017 12:27:38 +1000
Subject: powerpc/64s: Remove SAO feature from Power9 DD1
From: Nicholas Piggin <npiggin(a)gmail.com>
[ Upstream commit ca80d5d0a8175c9be04cfbce24180b8f5e0a744b ]
Power9 DD1 does not implement SAO. Although it's not widely used, its presence
or absence is visible to user space via arch_validate_prot() so it's moderately
important that we get the value right.
Fixes: 7dccfbc325bb ("powerpc/book3s: Add a cpu table entry for different POWER9 revs")
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/include/asm/cputable.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -474,7 +474,8 @@ enum {
CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_DAWR | \
CPU_FTR_ARCH_207S | CPU_FTR_TM_COMP | CPU_FTR_ARCH_300)
-#define CPU_FTRS_POWER9_DD1 (CPU_FTRS_POWER9 | CPU_FTR_POWER9_DD1)
+#define CPU_FTRS_POWER9_DD1 ((CPU_FTRS_POWER9 | CPU_FTR_POWER9_DD1) & \
+ (~CPU_FTR_SAO))
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.9/powerpc-64s-remove-sao-feature-from-power9-dd1.patch
This is a note to let you know that I've just added the patch titled
power: supply: isp1704: Fix unchecked return value of devm_kzalloc
to the 4.9-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:
power-supply-isp1704-fix-unchecked-return-value-of-devm_kzalloc.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:40:23 CET 2018
From: Pan Bian <bianpan2016(a)163.com>
Date: Mon, 24 Apr 2017 16:22:08 +0800
Subject: power: supply: isp1704: Fix unchecked return value of devm_kzalloc
From: Pan Bian <bianpan2016(a)163.com>
[ Upstream commit 8b20839988f1ed5e534b270f3776709b640dc7e0 ]
Function devm_kzalloc() will return a NULL pointer. However, in function
isp1704_charger_probe(), the return value of devm_kzalloc() is directly
used without validation. This may result in a bad memory access bug.
Fixes: 34a109610e2a ("isp1704_charger: Add DT support")
Signed-off-by: Pan Bian <bianpan2016(a)163.com>
Reviewed-by: Pali Rohár <pali.rohar(a)gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/power/supply/isp1704_charger.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/power/supply/isp1704_charger.c
+++ b/drivers/power/supply/isp1704_charger.c
@@ -418,6 +418,10 @@ static int isp1704_charger_probe(struct
pdata = devm_kzalloc(&pdev->dev,
sizeof(struct isp1704_charger_data), GFP_KERNEL);
+ if (!pdata) {
+ ret = -ENOMEM;
+ goto fail0;
+ }
pdata->enable_gpio = gpio;
dev_info(&pdev->dev, "init gpio %d\n", pdata->enable_gpio);
Patches currently in stable-queue which might be from bianpan2016(a)163.com are
queue-4.9/tipc-check-return-value-of-nlmsg_new.patch
queue-4.9/mt7601u-check-return-value-of-alloc_skb.patch
queue-4.9/rndis_wlan-add-return-value-validation.patch
queue-4.9/libertas-check-return-value-of-alloc_workqueue.patch
queue-4.9/staging-wilc1000-fix-unchecked-return-value.patch
queue-4.9/qlcnic-fix-unchecked-return-value.patch
queue-4.9/wan-pc300too-abort-path-on-failure.patch
queue-4.9/power-supply-isp1704-fix-unchecked-return-value-of-devm_kzalloc.patch
This is a note to let you know that I've just added the patch titled
power: supply: bq24190_charger: Limit over/under voltage fault logging
to the 4.9-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:
power-supply-bq24190_charger-limit-over-under-voltage-fault-logging.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:40:23 CET 2018
From: Liam Breck <kernel(a)networkimprov.net>
Date: Tue, 11 Apr 2017 04:59:54 -0700
Subject: power: supply: bq24190_charger: Limit over/under voltage fault logging
From: Liam Breck <kernel(a)networkimprov.net>
[ Upstream commit d63d07c6fc25182af6d3ab5b3b8737b0c1025ebd ]
If the charger is unplugged before the battery is full we may
see an over/under voltage fault. Ignore this rather then emitting
a message or uevent.
This fixes messages like these getting logged on charger unplug + replug:
bq24190-charger 15-006b: Fault: boost 0, charge 1, battery 0, ntc 0
bq24190-charger 15-006b: Fault: boost 0, charge 0, battery 0, ntc 0
Cc: Tony Lindgren <tony(a)atomide.com>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Liam Breck <kernel(a)networkimprov.net>
Acked-by: Tony Lindgren <tony(a)atomide.com>
Reviewed-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Sebastian Reichel <sre(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/power/supply/bq24190_charger.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/power/supply/bq24190_charger.c
+++ b/drivers/power/supply/bq24190_charger.c
@@ -1184,8 +1184,13 @@ static irqreturn_t bq24190_irq_handler_t
}
} while (f_reg && ++i < 2);
+ /* ignore over/under voltage fault after disconnect */
+ if (f_reg == (1 << BQ24190_REG_F_CHRG_FAULT_SHIFT) &&
+ !(ss_reg & BQ24190_REG_SS_PG_STAT_MASK))
+ f_reg = 0;
+
if (f_reg != bdi->f_reg) {
- dev_info(bdi->dev,
+ dev_warn(bdi->dev,
"Fault: boost %d, charge %d, battery %d, ntc %d\n",
!!(f_reg & BQ24190_REG_F_BOOST_FAULT_MASK),
!!(f_reg & BQ24190_REG_F_CHRG_FAULT_MASK),
Patches currently in stable-queue which might be from kernel(a)networkimprov.net are
queue-4.9/power-supply-bq24190_charger-limit-over-under-voltage-fault-logging.patch
queue-4.9/power-supply-bq24190_charger-add-disable-reset-device-property.patch
This is a note to let you know that I've just added the patch titled
power: supply: bq24190_charger: Add disable-reset device-property
to the 4.9-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:
power-supply-bq24190_charger-add-disable-reset-device-property.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:40:23 CET 2018
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Fri, 14 Apr 2017 18:52:33 +0200
Subject: power: supply: bq24190_charger: Add disable-reset device-property
From: Hans de Goede <hdegoede(a)redhat.com>
[ Upstream commit 6cf62a3b97e78ba41d31390e59a1ddc98a9e3622 ]
Allow platform-code to disable the reset on probe and suspend/resume
by setting a "disable-reset" boolean device property on the device.
There are several reasons why the platform-code may want to disable
the reset on probe and suspend/resume:
1) Resetting the charger should never be necessary it should always have
sane values programmed. If it is running with invalid values while we
are not running (system turned off or suspended) there is a big problem
as that may lead to overcharging the battery.
2) The reset in suspend() is meant to put the charger back into default
mode, but this is not necessary and not a good idea. If the charger has
been programmed with a higher max charge_current / charge_voltage then
putting it back in default-mode will reset those to the safe power-on
defaults, leading to slower charging, or charging to a lower voltage
(and thus not using the full capacity) while suspended which is
undesirable. Reprogramming the max charge_current / charge_voltage
after the reset will not help here as that will put the charger back
in host mode and start the i2c watchdog if the host then does not do
anything for 40s (iow if we're suspended for more then 40s) the watchdog
expires resetting the device to default-mode, including resetting all
the registers to there safe power-on defaults. So the only way to keep
using custom charge settings while suspending is to keep the charger in
its normal running state with the i2c watchdog disabled. This is fine
as the charger will still automatically switch from constant current
to constant voltage and stop charging when the battery is full.
3) Besides never being necessary resetting the charger also causes
problems on systems where the charge voltage limit is set higher then the
reset value, if this is the case and the charger is reset while charging
and the battery voltage is between the 2 voltages, then about half the
time the charger gets confused and claims to be charging (REG08 contains
0x64) but in reality the charger has decoupled itself from VBUS (Q1 off)
and is drawing 0A from VBUS, leaving the system running from the battery.
This last problem is happening on a GPD-win mini PC with a bq24292i
charger chip combined with a max17047 fuel-gauge and a LiHV battery.
I've checked and TI does not list any errata for the bq24292i which
could explain this (there are no errata at all).
Cc: Liam Breck <kernel(a)networkimprov.net>
Cc: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Acked-by: Liam Breck <kernel(a)networkimprov.net>
Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/power/supply/bq24190_charger.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/power/supply/bq24190_charger.c
+++ b/drivers/power/supply/bq24190_charger.c
@@ -506,6 +506,9 @@ static int bq24190_register_reset(struct
int ret, limit = 100;
u8 v;
+ if (device_property_read_bool(bdi->dev, "disable-reset"))
+ return 0;
+
/* Reset the registers */
ret = bq24190_write_mask(bdi, BQ24190_REG_POC,
BQ24190_REG_POC_RESET_MASK,
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.9/power-supply-bq24190_charger-limit-over-under-voltage-fault-logging.patch
queue-4.9/acpi-pmic-xpower-fix-power_table-addresses.patch
queue-4.9/acpi-power-delay-turning-off-unused-power-resources-after-suspend.patch
queue-4.9/rtc-cmos-do-not-assume-irq-8-for-rtc-when-there-are-no-legacy-irqs.patch
queue-4.9/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch
queue-4.9/power-supply-bq24190_charger-add-disable-reset-device-property.patch
queue-4.9/x86-i8259-export-legacy_pic-symbol.patch
This is a note to let you know that I've just added the patch titled
pNFS: Fix use after free issues in pnfs_do_read()
to the 4.9-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:
pnfs-fix-use-after-free-issues-in-pnfs_do_read.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:40:23 CET 2018
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Tue, 25 Apr 2017 11:26:53 -0400
Subject: pNFS: Fix use after free issues in pnfs_do_read()
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
[ Upstream commit 6aeafd05eca9bc8ab6b03d7e56d09ffd18190f44 ]
The assumption should be that if the caller returns PNFS_ATTEMPTED, then hdr
has been consumed, and so we should not be testing hdr->task.tk_status.
If the caller returns PNFS_TRY_AGAIN, then we need to recoalesce and
free hdr.
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/pnfs.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -2308,10 +2308,20 @@ pnfs_do_read(struct nfs_pageio_descripto
enum pnfs_try_status trypnfs;
trypnfs = pnfs_try_to_read_data(hdr, call_ops, lseg);
- if (trypnfs == PNFS_TRY_AGAIN)
- pnfs_read_resend_pnfs(hdr);
- if (trypnfs == PNFS_NOT_ATTEMPTED || hdr->task.tk_status)
+ switch (trypnfs) {
+ case PNFS_NOT_ATTEMPTED:
pnfs_read_through_mds(desc, hdr);
+ case PNFS_ATTEMPTED:
+ break;
+ case PNFS_TRY_AGAIN:
+ /* cleanup hdr and prepare to redo pnfs */
+ if (!test_and_set_bit(NFS_IOHDR_REDO, &hdr->flags)) {
+ struct nfs_pgio_mirror *mirror = nfs_pgio_current_mirror(desc);
+ list_splice_init(&hdr->pages, &mirror->pg_list);
+ mirror->pg_recoalesce = 1;
+ }
+ hdr->mds_ops->rpc_release(hdr);
+ }
}
static void pnfs_readhdr_free(struct nfs_pgio_header *hdr)
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.9/pnfs-fix-use-after-free-issues-in-pnfs_do_read.patch
queue-4.9/pnfs-fix-a-deadlock-when-coalescing-writes-and-returning-the-layout.patch
queue-4.9/nfs-fix-missing-pg_cleanup-after-nfs_pageio_cond_complete.patch
This is a note to let you know that I've just added the patch titled
pNFS: Fix a deadlock when coalescing writes and returning the layout
to the 4.9-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:
pnfs-fix-a-deadlock-when-coalescing-writes-and-returning-the-layout.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:40:24 CET 2018
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Mon, 1 May 2017 17:06:56 -0400
Subject: pNFS: Fix a deadlock when coalescing writes and returning the layout
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
[ Upstream commit 61f454e30c18a28924e96be12592c0d5e24bcc81 ]
Consider the following deadlock:
Process P1 Process P2 Process P3
========== ========== ==========
lock_page(page)
lseg = pnfs_update_layout(inode)
lo = NFS_I(inode)->layout
pnfs_error_mark_layout_for_return(lo)
lock_page(page)
lseg = pnfs_update_layout(inode)
In this scenario,
- P1 has declared the layout to be in error, but P2 holds a reference to
a layout segment on that inode, so the layoutreturn is deferred.
- P2 is waiting for a page lock held by P3.
- P3 is asking for a new layout segment, but is blocked waiting
for the layoutreturn.
The fix is to ensure that pnfs_error_mark_layout_for_return() does
not set the NFS_LAYOUT_RETURN flag, which blocks P3. Instead, we allow
the latter to call LAYOUTGET so that it can make progress and unblock
P2.
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/pnfs.c | 2 --
1 file changed, 2 deletions(-)
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -1953,8 +1953,6 @@ void pnfs_error_mark_layout_for_return(s
spin_lock(&inode->i_lock);
pnfs_set_plh_return_info(lo, range.iomode, 0);
- /* Block LAYOUTGET */
- set_bit(NFS_LAYOUT_RETURN, &lo->plh_flags);
/*
* mark all matching lsegs so that we are sure to have no live
* segments at hand when sending layoutreturn. See pnfs_put_lseg()
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.9/pnfs-fix-use-after-free-issues-in-pnfs_do_read.patch
queue-4.9/pnfs-fix-a-deadlock-when-coalescing-writes-and-returning-the-layout.patch
queue-4.9/nfs-fix-missing-pg_cleanup-after-nfs_pageio_cond_complete.patch
This is a note to let you know that I've just added the patch titled
platform/x86: intel-vbtn: add volume up and down
to the 4.9-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:
platform-x86-intel-vbtn-add-volume-up-and-down.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:40:23 CET 2018
From: Maarten Maathuis <madman2003(a)gmail.com>
Date: Mon, 24 Apr 2017 23:35:21 +0200
Subject: platform/x86: intel-vbtn: add volume up and down
From: Maarten Maathuis <madman2003(a)gmail.com>
[ Upstream commit 8d9e29972836b75eb74f533594999500a4c7cc19 ]
Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
Signed-off-by: Maarten Maathuis <madman2003(a)shikahr.net>
[andy: fixed indentation of comments and massaged title of the change]
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/platform/x86/intel-vbtn.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -37,6 +37,10 @@ static const struct acpi_device_id intel
static const struct key_entry intel_vbtn_keymap[] = {
{ KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
{ KE_KEY, 0xC1, { KEY_POWER } }, /* power key release */
+ { KE_KEY, 0xC4, { KEY_VOLUMEUP } }, /* volume-up key press */
+ { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } }, /* volume-up key release */
+ { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } }, /* volume-down key press */
+ { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } }, /* volume-down key release */
{ KE_END },
};
Patches currently in stable-queue which might be from madman2003(a)gmail.com are
queue-4.9/platform-x86-intel-vbtn-add-volume-up-and-down.patch
This is a note to let you know that I've just added the patch titled
platform/x86: asus-wmi: try to set als by default
to the 4.9-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:
platform-x86-asus-wmi-try-to-set-als-by-default.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:40:23 CET 2018
From: Oleksij Rempel <linux(a)rempel-privat.de>
Date: Fri, 28 Apr 2017 16:19:49 +0200
Subject: platform/x86: asus-wmi: try to set als by default
From: Oleksij Rempel <linux(a)rempel-privat.de>
[ Upstream commit e9b615186805e2c18a0ac76aca62c1543ecfdbb8 ]
some laptops, for example ASUS UX330UAK, have brocken als_get function
but working als_set funktion. In this case, ALS will stay turned off.
Method (WMNB, 3, Serialized)
{
...
If (Local0 == 0x53545344)
{
...
If (IIA0 == 0x00050001)
{
If (!ALSP)
{
Return (0x02)
}
Local0 = (GALS & 0x10) <<<---- bug,
should be: (GALS () & 0x10)
If (Local0)
{
Return (0x00050001)
}
Else
{
Return (0x00050000)
}
}
.....
If (Local0 == 0x53564544)
{
...
If (IIA0 == 0x00050001)
{
Return (ALSC (IIA1))
}
......
Method (GALS, 0, NotSerialized)
{
Local0 = Zero
Local0 |= 0x20
If (ALAE)
{
Local0 |= 0x10
}
Local1 = 0x0A
Local1 <<= 0x08
Local0 |= Local1
Return (Local0)
}
Since it works without problems on Windows I assume ASUS WMI driver for Win
never trying to get ALS state, and instead it is setting it by default to ON.
This patch will do the same. Turn ALS on by default.
Signed-off-by: Oleksij Rempel <linux(a)rempel-privat.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/platform/x86/asus-nb-wmi.c | 13 +++++++++++++
drivers/platform/x86/asus-wmi.c | 12 ++++++++++++
drivers/platform/x86/asus-wmi.h | 1 +
3 files changed, 26 insertions(+)
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -120,6 +120,10 @@ static struct quirk_entry quirk_asus_x55
.xusb2pr = 0x01D9,
};
+static struct quirk_entry quirk_asus_ux330uak = {
+ .wmi_force_als_set = true,
+};
+
static int dmi_matched(const struct dmi_system_id *dmi)
{
quirks = dmi->driver_data;
@@ -422,6 +426,15 @@ static const struct dmi_system_id asus_q
},
{
.callback = dmi_matched,
+ .ident = "ASUSTeK COMPUTER INC. UX330UAK",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "UX330UAK"),
+ },
+ .driver_data = &quirk_asus_ux330uak,
+ },
+ {
+ .callback = dmi_matched,
.ident = "ASUSTeK COMPUTER INC. X550LB",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1109,6 +1109,15 @@ static void asus_wmi_set_xusb2pr(struct
}
/*
+ * Some devices dont support or have borcken get_als method
+ * but still support set method.
+ */
+static void asus_wmi_set_als(void)
+{
+ asus_wmi_set_devstate(ASUS_WMI_DEVID_ALS_ENABLE, 1, NULL);
+}
+
+/*
* Hwmon device
*/
static int asus_hwmon_agfn_fan_speed_read(struct asus_wmi *asus, int fan,
@@ -2120,6 +2129,9 @@ static int asus_wmi_add(struct platform_
goto fail_rfkill;
}
+ if (asus->driver->quirks->wmi_force_als_set)
+ asus_wmi_set_als();
+
/* Some Asus desktop boards export an acpi-video backlight interface,
stop this from showing up */
chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -45,6 +45,7 @@ struct quirk_entry {
bool store_backlight_power;
bool wmi_backlight_power;
bool wmi_backlight_native;
+ bool wmi_force_als_set;
int wapf;
/*
* For machines with AMD graphic chips, it will send out WMI event
Patches currently in stable-queue which might be from linux(a)rempel-privat.de are
queue-4.9/platform-x86-asus-wmi-try-to-set-als-by-default.patch