This is a note to let you know that I've just added the patch titled
Btrfs: fix incorrect space accounting after failure to insert inline extent
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:
btrfs-fix-incorrect-space-accounting-after-failure-to-insert-inline-extent.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: Filipe Manana <fdmanana(a)suse.com>
Date: Wed, 8 Mar 2017 16:43:49 +0000
Subject: Btrfs: fix incorrect space accounting after failure to insert inline extent
From: Filipe Manana <fdmanana(a)suse.com>
[ Upstream commit 1c81ba237bcecad9bc885a1ddcf02d725ea38482 ]
When using compression, if we fail to insert an inline extent we
incorrectly end up attempting to free the reserved data space twice,
once through extent_clear_unlock_delalloc(), because we pass it the
flag EXTENT_DO_ACCOUNTING, and once through a direct call to
btrfs_free_reserved_data_space_noquota(). This results in a trace
like the following:
[ 834.576240] ------------[ cut here ]------------
[ 834.576825] WARNING: CPU: 2 PID: 486 at fs/btrfs/extent-tree.c:4316 btrfs_free_reserved_data_space_noquota+0x60/0x9f [btrfs]
[ 834.579501] Modules linked in: btrfs crc32c_generic xor raid6_pq ppdev i2c_piix4 acpi_cpufreq psmouse tpm_tis parport_pc pcspkr serio_raw tpm_tis_core sg parport evdev i2c_core tpm button loop autofs4 ext4 crc16 jbd2 mbcache sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix virtio_pci libata virtio_ring virtio scsi_mod e1000 floppy [last unloaded: btrfs]
[ 834.592116] CPU: 2 PID: 486 Comm: kworker/u32:4 Not tainted 4.10.0-rc8-btrfs-next-37+ #2
[ 834.593316] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
[ 834.595273] Workqueue: btrfs-delalloc btrfs_delalloc_helper [btrfs]
[ 834.596103] Call Trace:
[ 834.596103] dump_stack+0x67/0x90
[ 834.596103] __warn+0xc2/0xdd
[ 834.596103] warn_slowpath_null+0x1d/0x1f
[ 834.596103] btrfs_free_reserved_data_space_noquota+0x60/0x9f [btrfs]
[ 834.596103] compress_file_range.constprop.42+0x2fa/0x3fc [btrfs]
[ 834.596103] ? submit_compressed_extents+0x3a7/0x3a7 [btrfs]
[ 834.596103] async_cow_start+0x32/0x4d [btrfs]
[ 834.596103] btrfs_scrubparity_helper+0x187/0x3e7 [btrfs]
[ 834.596103] btrfs_delalloc_helper+0xe/0x10 [btrfs]
[ 834.596103] process_one_work+0x273/0x4e4
[ 834.596103] worker_thread+0x1eb/0x2ca
[ 834.596103] ? rescuer_thread+0x2b6/0x2b6
[ 834.596103] kthread+0x100/0x108
[ 834.596103] ? __list_del_entry+0x22/0x22
[ 834.596103] ret_from_fork+0x2e/0x40
[ 834.611656] ---[ end trace 719902fe6bdef08f ]---
So fix this by not calling directly btrfs_free_reserved_data_space_noquota()
if an error happened.
Signed-off-by: Filipe Manana <fdmanana(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/inode.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -567,8 +567,10 @@ cont:
PAGE_SET_WRITEBACK |
page_error_op |
PAGE_END_WRITEBACK);
- btrfs_free_reserved_data_space_noquota(inode, start,
- end - start + 1);
+ if (ret == 0)
+ btrfs_free_reserved_data_space_noquota(inode,
+ start,
+ end - start + 1);
goto free_pages_out;
}
}
Patches currently in stable-queue which might be from fdmanana(a)suse.com are
queue-4.9/btrfs-fix-incorrect-space-accounting-after-failure-to-insert-inline-extent.patch
queue-4.9/btrfs-fix-extent-map-leak-during-fallocate-error-path.patch
queue-4.9/btrfs-send-fix-file-hole-not-being-preserved-due-to-inline-extent.patch
This is a note to let you know that I've just added the patch titled
Btrfs: fix extent map leak during fallocate error path
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:
btrfs-fix-extent-map-leak-during-fallocate-error-path.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: Filipe Manana <fdmanana(a)suse.com>
Date: Mon, 3 Apr 2017 15:57:17 +0100
Subject: Btrfs: fix extent map leak during fallocate error path
From: Filipe Manana <fdmanana(a)suse.com>
[ Upstream commit be2d253cc98244765323a7c94cc1ac5cd5a17072 ]
If the call to btrfs_qgroup_reserve_data() failed, we were leaking an
extent map structure. The failure can happen either due to an -ENOMEM
condition or, when quotas are enabled, due to -EDQUOT for example.
Signed-off-by: Filipe Manana <fdmanana(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/file.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -2817,8 +2817,10 @@ static long btrfs_fallocate(struct file
}
ret = btrfs_qgroup_reserve_data(inode, cur_offset,
last_byte - cur_offset);
- if (ret < 0)
+ if (ret < 0) {
+ free_extent_map(em);
break;
+ }
} else {
/*
* Do not need to reserve unwritten extent for this
Patches currently in stable-queue which might be from fdmanana(a)suse.com are
queue-4.9/btrfs-fix-incorrect-space-accounting-after-failure-to-insert-inline-extent.patch
queue-4.9/btrfs-fix-extent-map-leak-during-fallocate-error-path.patch
queue-4.9/btrfs-send-fix-file-hole-not-being-preserved-due-to-inline-extent.patch
This is a note to let you know that I've just added the patch titled
btrfs: fix a bogus warning when converting only data or metadata
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:
btrfs-fix-a-bogus-warning-when-converting-only-data-or-metadata.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: Adam Borowski <kilobyte(a)angband.pl>
Date: Tue, 7 Mar 2017 23:34:44 +0100
Subject: btrfs: fix a bogus warning when converting only data or metadata
From: Adam Borowski <kilobyte(a)angband.pl>
[ Upstream commit 14506127979a5a3d0c5d9b4cc76ce9d4ec23b717 ]
If your filesystem has, eg, data:raid0 metadata:raid1, and you run "btrfs
balance -dconvert=raid1", the meta.target field will be uninitialized.
That's otherwise ok, as it's unused except for this warning.
Thus, let's use the existing set of raid levels for the comparison.
As a side effect, non-convert balances will now nag about data>metadata.
Signed-off-by: Adam Borowski <kilobyte(a)angband.pl>
Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/volumes.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -3765,6 +3765,7 @@ int btrfs_balance(struct btrfs_balance_c
struct btrfs_ioctl_balance_args *bargs)
{
struct btrfs_fs_info *fs_info = bctl->fs_info;
+ u64 meta_target, data_target;
u64 allowed;
int mixed = 0;
int ret;
@@ -3861,11 +3862,16 @@ int btrfs_balance(struct btrfs_balance_c
}
} while (read_seqretry(&fs_info->profiles_lock, seq));
- if (btrfs_get_num_tolerated_disk_barrier_failures(bctl->meta.target) <
- btrfs_get_num_tolerated_disk_barrier_failures(bctl->data.target)) {
+ /* if we're not converting, the target field is uninitialized */
+ meta_target = (bctl->meta.flags & BTRFS_BALANCE_ARGS_CONVERT) ?
+ bctl->meta.target : fs_info->avail_metadata_alloc_bits;
+ data_target = (bctl->data.flags & BTRFS_BALANCE_ARGS_CONVERT) ?
+ bctl->data.target : fs_info->avail_data_alloc_bits;
+ if (btrfs_get_num_tolerated_disk_barrier_failures(meta_target) <
+ btrfs_get_num_tolerated_disk_barrier_failures(data_target)) {
btrfs_warn(fs_info,
"metadata profile 0x%llx has lower redundancy than data profile 0x%llx",
- bctl->meta.target, bctl->data.target);
+ meta_target, data_target);
}
if (bctl->sys.flags & BTRFS_BALANCE_ARGS_CONVERT) {
Patches currently in stable-queue which might be from kilobyte(a)angband.pl are
queue-4.9/btrfs-fix-a-bogus-warning-when-converting-only-data-or-metadata.patch
This is a note to let you know that I've just added the patch titled
bonding: handle link transition from FAIL to UP correctly
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:
bonding-handle-link-transition-from-fail-to-up-correctly.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: Mahesh Bandewar <maheshb(a)google.com>
Date: Tue, 11 Apr 2017 22:36:00 -0700
Subject: bonding: handle link transition from FAIL to UP correctly
From: Mahesh Bandewar <maheshb(a)google.com>
[ Upstream commit fb9eb899a6dc663e4a2deed9af2ac28f507d0ffb ]
When link transitions from LINK_FAIL to LINK_UP, the commit phase is
not called. This leads to an erroneous state causing slave-link state to
get stuck in "going down" state while its speed and duplex are perfectly
fine. This issue is a side-effect of splitting link-set into propose and
commit phases introduced by de77ecd4ef02 ("bonding: improve link-status
update in mii-monitoring")
This patch fixes these issues by calling commit phase whenever link
state change is proposed.
Fixes: de77ecd4ef02 ("bonding: improve link-status update in mii-monitoring")
Signed-off-by: Mahesh Bandewar <maheshb(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/bonding/bond_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2067,6 +2067,7 @@ static int bond_miimon_inspect(struct bo
(bond->params.downdelay - slave->delay) *
bond->params.miimon,
slave->dev->name);
+ commit++;
continue;
}
@@ -2104,7 +2105,7 @@ static int bond_miimon_inspect(struct bo
(bond->params.updelay - slave->delay) *
bond->params.miimon,
slave->dev->name);
-
+ commit++;
continue;
}
Patches currently in stable-queue which might be from maheshb(a)google.com are
queue-4.9/bonding-handle-link-transition-from-fail-to-up-correctly.patch
This is a note to let you know that I've just added the patch titled
bnx2x: Align RX buffers
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:
bnx2x-align-rx-buffers.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: Scott Wood <swood(a)redhat.com>
Date: Fri, 28 Apr 2017 19:17:41 -0500
Subject: bnx2x: Align RX buffers
From: Scott Wood <swood(a)redhat.com>
[ Upstream commit 9b70de6d0266888b3743f03802502e43131043c8 ]
The bnx2x driver is not providing proper alignment on the receive buffers it
passes to build_skb(), causing skb_shared_info to be misaligned.
skb_shared_info contains an atomic, and while PPC normally supports
unaligned accesses, it does not support unaligned atomics.
Aligning the size of rx buffers will ensure that page_frag_alloc() returns
aligned addresses.
This can be reproduced on PPC by setting the network MTU to 1450 (or other
non-multiple-of-4) and then generating sufficient inbound network traffic
(one or two large "wget"s usually does it), producing the following oops:
Unable to handle kernel paging request for unaligned access at address 0xc00000ffc43af656
Faulting instruction address: 0xc00000000080ef8c
Oops: Kernel access of bad area, sig: 7 [#1]
SMP NR_CPUS=2048
NUMA
PowerNV
Modules linked in: vmx_crypto powernv_rng rng_core powernv_op_panel leds_powernv led_class nfsd ip_tables x_tables autofs4 xfs lpfc bnx2x mdio libcrc32c crc_t10dif crct10dif_generic crct10dif_common
CPU: 104 PID: 0 Comm: swapper/104 Not tainted 4.11.0-rc8-00088-g4c761da #2
task: c00000ffd4892400 task.stack: c00000ffd4920000
NIP: c00000000080ef8c LR: c00000000080eee8 CTR: c0000000001f8320
REGS: c00000ffffc33710 TRAP: 0600 Not tainted (4.11.0-rc8-00088-g4c761da)
MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
CR: 24082042 XER: 00000000
CFAR: c00000000080eea0 DAR: c00000ffc43af656 DSISR: 00000000 SOFTE: 1
GPR00: c000000000907f64 c00000ffffc33990 c000000000dd3b00 c00000ffcaf22100
GPR04: c00000ffcaf22e00 0000000000000000 0000000000000000 0000000000000000
GPR08: 0000000000b80008 c00000ffc43af636 c00000ffc43af656 0000000000000000
GPR12: c0000000001f6f00 c00000000fe1a000 000000000000049f 000000000000c51f
GPR16: 00000000ffffef33 0000000000000000 0000000000008a43 0000000000000001
GPR20: c00000ffc58a90c0 0000000000000000 000000000000dd86 0000000000000000
GPR24: c000007fd0ed10c0 00000000ffffffff 0000000000000158 000000000000014a
GPR28: c00000ffc43af010 c00000ffc9144000 c00000ffcaf22e00 c00000ffcaf22100
NIP [c00000000080ef8c] __skb_clone+0xdc/0x140
LR [c00000000080eee8] __skb_clone+0x38/0x140
Call Trace:
[c00000ffffc33990] [c00000000080fb74] skb_clone+0x74/0x110 (unreliable)
[c00000ffffc339c0] [c000000000907f64] packet_rcv+0x144/0x510
[c00000ffffc33a40] [c000000000827b64] __netif_receive_skb_core+0x5b4/0xd80
[c00000ffffc33b00] [c00000000082b2bc] netif_receive_skb_internal+0x2c/0xc0
[c00000ffffc33b40] [c00000000082c49c] napi_gro_receive+0x11c/0x260
[c00000ffffc33b80] [d000000066483d68] bnx2x_poll+0xcf8/0x17b0 [bnx2x]
[c00000ffffc33d00] [c00000000082babc] net_rx_action+0x31c/0x480
[c00000ffffc33e10] [c0000000000d5a44] __do_softirq+0x164/0x3d0
[c00000ffffc33f00] [c0000000000d60a8] irq_exit+0x108/0x120
[c00000ffffc33f20] [c000000000015b98] __do_irq+0x98/0x200
[c00000ffffc33f90] [c000000000027f14] call_do_irq+0x14/0x24
[c00000ffd4923a90] [c000000000015d94] do_IRQ+0x94/0x110
[c00000ffd4923ae0] [c000000000008d90] hardware_interrupt_common+0x150/0x160
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -2026,6 +2026,7 @@ static void bnx2x_set_rx_buf_size(struct
ETH_OVREHEAD +
mtu +
BNX2X_FW_RX_ALIGN_END;
+ fp->rx_buf_size = SKB_DATA_ALIGN(fp->rx_buf_size);
/* Note : rx_buf_size doesn't take into account NET_SKB_PAD */
if (fp->rx_buf_size + NET_SKB_PAD <= PAGE_SIZE)
fp->rx_frag_size = fp->rx_buf_size + NET_SKB_PAD;
Patches currently in stable-queue which might be from swood(a)redhat.com are
queue-4.9/bnx2x-align-rx-buffers.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: hci_qca: Avoid setup failure on missing rampatch
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:
bluetooth-hci_qca-avoid-setup-failure-on-missing-rampatch.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: Loic Poulain <loic.poulain(a)linaro.org>
Date: Mon, 6 Nov 2017 12:16:56 +0100
Subject: Bluetooth: hci_qca: Avoid setup failure on missing rampatch
From: Loic Poulain <loic.poulain(a)linaro.org>
[ Upstream commit ba8f3597900291a93604643017fff66a14546015 ]
Assuming that the original code idea was to enable in-band sleeping
only if the setup_rome method returns succes and run in 'standard'
mode otherwise, we should not return setup_rome return value which
makes qca_setup fail if no rampatch/nvm file found.
This fixes BT issue on the dragonboard-820C p4 which includes the
following QCA controller:
hci0: Product:0x00000008
hci0: Patch :0x00000111
hci0: ROM :0x00000302
hci0: SOC :0x00000044
Since there is no rampatch for this controller revision, just make
it work as is.
Signed-off-by: Loic Poulain <loic.poulain(a)linaro.org>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/hci_qca.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -936,6 +936,9 @@ static int qca_setup(struct hci_uart *hu
if (!ret) {
set_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags);
qca_debugfs_init(hdev);
+ } else if (ret == -ENOENT) {
+ /* No patch/nvm-config found, run with original fw/config */
+ ret = 0;
}
/* Setup bdaddr */
Patches currently in stable-queue which might be from loic.poulain(a)linaro.org are
queue-4.9/bluetooth-btqcomsmd-fix-skb-double-free-corruption.patch
queue-4.9/bluetooth-hci_qca-avoid-setup-failure-on-missing-rampatch.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: hci_ldisc: Add protocol check to hci_uart_tx_wakeup()
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:
bluetooth-hci_ldisc-add-protocol-check-to-hci_uart_tx_wakeup.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: Dean Jenkins <Dean_Jenkins(a)mentor.com>
Date: Fri, 28 Apr 2017 13:57:26 +0100
Subject: Bluetooth: hci_ldisc: Add protocol check to hci_uart_tx_wakeup()
From: Dean Jenkins <Dean_Jenkins(a)mentor.com>
[ Upstream commit 2d6f1da168e1d62c47f7d50135ac4cbd8411dcb1 ]
Before attempting to schedule a work-item onto hu->write_work in
hci_uart_tx_wakeup(), check that the Data Link protocol layer is
still bound to the HCI UART driver.
Failure to perform this protocol check causes a race condition between
the work queue hu->write_work running hci_uart_write_work() and the
Data Link protocol layer being unbound (closed) in hci_uart_tty_close().
Note hci_uart_tty_close() does have a "cancel_work_sync(&hu->write_work)"
but it is ineffective because it cannot prevent work-items being added
to hu->write_work after cancel_work_sync() has run.
Therefore, add a check for HCI_UART_PROTO_READY into hci_uart_tx_wakeup()
which prevents scheduling of the work queue when HCI_UART_PROTO_READY
is in the clear state. However, note a small race condition remains
because the hci_uart_tx_wakeup() thread can run in parallel with the
hci_uart_tty_close() thread so it is possible that a schedule of
hu->write_work can occur when HCI_UART_PROTO_READY is cleared. A complete
solution needs locking of the threads which is implemented in a future
commit.
Signed-off-by: Dean Jenkins <Dean_Jenkins(a)mentor.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/hci_ldisc.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -125,6 +125,9 @@ static inline struct sk_buff *hci_uart_d
int hci_uart_tx_wakeup(struct hci_uart *hu)
{
+ if (!test_bit(HCI_UART_PROTO_READY, &hu->flags))
+ return 0;
+
if (test_and_set_bit(HCI_UART_SENDING, &hu->tx_state)) {
set_bit(HCI_UART_TX_WAKEUP, &hu->tx_state);
return 0;
Patches currently in stable-queue which might be from Dean_Jenkins(a)mentor.com are
queue-4.9/bluetooth-hci_ldisc-add-protocol-check-to-hci_uart_dequeue.patch
queue-4.9/bluetooth-hci_ldisc-add-protocol-check-to-hci_uart_tx_wakeup.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: hci_ldisc: Add protocol check to hci_uart_dequeue()
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:
bluetooth-hci_ldisc-add-protocol-check-to-hci_uart_dequeue.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: Dean Jenkins <Dean_Jenkins(a)mentor.com>
Date: Fri, 28 Apr 2017 13:57:25 +0100
Subject: Bluetooth: hci_ldisc: Add protocol check to hci_uart_dequeue()
From: Dean Jenkins <Dean_Jenkins(a)mentor.com>
[ Upstream commit 048e1bd3a27fbeb84ccdff52e165370c1339a193 ]
Before attempting to dequeue a Data Link protocol encapsulated message,
check that the Data Link protocol is still bound to the HCI UART driver.
This makes the code consistent with the usage of the other proto
function pointers.
Therefore, add a check for HCI_UART_PROTO_READY into hci_uart_dequeue()
and return NULL if the Data Link protocol is not bound.
This is needed for robustness as there is a scheduling race condition.
hci_uart_write_work() is scheduled to run via work queue hu->write_work
from hci_uart_tx_wakeup(). Therefore, there is a delay between
scheduling hci_uart_write_work() to run and hci_uart_dequeue() running
whereby the Data Link protocol layer could become unbound during the
scheduling delay. In this case, without the check, the call to the
unbound Data Link protocol layer dequeue function can crash.
It is noted that hci_uart_tty_close() has a
"cancel_work_sync(&hu->write_work)" statement but this only reduces
the window of the race condition because it is possible for a new
work-item to be added to work queue hu->write_work after the call to
cancel_work_sync(). For example, Data Link layer retransmissions can
be added to the work queue after the cancel_work_sync() has finished.
Signed-off-by: Dean Jenkins <Dean_Jenkins(a)mentor.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/hci_ldisc.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -113,10 +113,12 @@ static inline struct sk_buff *hci_uart_d
{
struct sk_buff *skb = hu->tx_skb;
- if (!skb)
- skb = hu->proto->dequeue(hu);
- else
+ if (!skb) {
+ if (test_bit(HCI_UART_PROTO_READY, &hu->flags))
+ skb = hu->proto->dequeue(hu);
+ } else {
hu->tx_skb = NULL;
+ }
return skb;
}
Patches currently in stable-queue which might be from Dean_Jenkins(a)mentor.com are
queue-4.9/bluetooth-hci_ldisc-add-protocol-check-to-hci_uart_dequeue.patch
queue-4.9/bluetooth-hci_ldisc-add-protocol-check-to-hci_uart_tx_wakeup.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btqcomsmd: Fix skb double free corruption
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:
bluetooth-btqcomsmd-fix-skb-double-free-corruption.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: Loic Poulain <loic.poulain(a)linaro.org>
Date: Wed, 22 Nov 2017 15:03:17 +0100
Subject: Bluetooth: btqcomsmd: Fix skb double free corruption
From: Loic Poulain <loic.poulain(a)linaro.org>
[ Upstream commit 67b8fbead4685b36d290a0ef91c6ddffc4920ec9 ]
In case of hci send frame failure, skb is still owned
by the caller (hci_core) and then should not be freed.
This fixes crash on dragonboard-410c when sending SCO
packet. skb is freed by both btqcomsmd and hci_core.
Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
Signed-off-by: Loic Poulain <loic.poulain(a)linaro.org>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btqcomsmd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/bluetooth/btqcomsmd.c
+++ b/drivers/bluetooth/btqcomsmd.c
@@ -85,7 +85,8 @@ static int btqcomsmd_send(struct hci_dev
break;
}
- kfree_skb(skb);
+ if (!ret)
+ kfree_skb(skb);
return ret;
}
Patches currently in stable-queue which might be from loic.poulain(a)linaro.org are
queue-4.9/bluetooth-btqcomsmd-fix-skb-double-free-corruption.patch
queue-4.9/bluetooth-hci_qca-avoid-setup-failure-on-missing-rampatch.patch
This is a note to let you know that I've just added the patch titled
block/mq: Cure cpu hotplug lock inversion
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:
block-mq-cure-cpu-hotplug-lock-inversion.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: Peter Zijlstra <peterz(a)infradead.org>
Date: Thu, 4 May 2017 15:05:26 +0200
Subject: block/mq: Cure cpu hotplug lock inversion
From: Peter Zijlstra <peterz(a)infradead.org>
[ Upstream commit eabe06595d62cfa9278e2cd012df614bc68a7042 ]
By poking at /debug/sched_features I triggered the following splat:
[] ======================================================
[] WARNING: possible circular locking dependency detected
[] 4.11.0-00873-g964c8b7-dirty #694 Not tainted
[] ------------------------------------------------------
[] bash/2109 is trying to acquire lock:
[] (cpu_hotplug_lock.rw_sem){++++++}, at: [<ffffffff8120cb8b>] static_key_slow_dec+0x1b/0x50
[]
[] but task is already holding lock:
[] (&sb->s_type->i_mutex_key#4){+++++.}, at: [<ffffffff81140216>] sched_feat_write+0x86/0x170
[]
[] which lock already depends on the new lock.
[]
[]
[] the existing dependency chain (in reverse order) is:
[]
[] -> #2 (&sb->s_type->i_mutex_key#4){+++++.}:
[] lock_acquire+0x100/0x210
[] down_write+0x28/0x60
[] start_creating+0x5e/0xf0
[] debugfs_create_dir+0x13/0x110
[] blk_mq_debugfs_register+0x21/0x70
[] blk_mq_register_dev+0x64/0xd0
[] blk_register_queue+0x6a/0x170
[] device_add_disk+0x22d/0x440
[] loop_add+0x1f3/0x280
[] loop_init+0x104/0x142
[] do_one_initcall+0x43/0x180
[] kernel_init_freeable+0x1de/0x266
[] kernel_init+0xe/0x100
[] ret_from_fork+0x31/0x40
[]
[] -> #1 (all_q_mutex){+.+.+.}:
[] lock_acquire+0x100/0x210
[] __mutex_lock+0x6c/0x960
[] mutex_lock_nested+0x1b/0x20
[] blk_mq_init_allocated_queue+0x37c/0x4e0
[] blk_mq_init_queue+0x3a/0x60
[] loop_add+0xe5/0x280
[] loop_init+0x104/0x142
[] do_one_initcall+0x43/0x180
[] kernel_init_freeable+0x1de/0x266
[] kernel_init+0xe/0x100
[] ret_from_fork+0x31/0x40
[] *** DEADLOCK ***
[]
[] 3 locks held by bash/2109:
[] #0: (sb_writers#11){.+.+.+}, at: [<ffffffff81292bcd>] vfs_write+0x17d/0x1a0
[] #1: (debugfs_srcu){......}, at: [<ffffffff8155a90d>] full_proxy_write+0x5d/0xd0
[] #2: (&sb->s_type->i_mutex_key#4){+++++.}, at: [<ffffffff81140216>] sched_feat_write+0x86/0x170
[]
[] stack backtrace:
[] CPU: 9 PID: 2109 Comm: bash Not tainted 4.11.0-00873-g964c8b7-dirty #694
[] Hardware name: Intel Corporation S2600GZ/S2600GZ, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
[] Call Trace:
[] lock_acquire+0x100/0x210
[] get_online_cpus+0x2a/0x90
[] static_key_slow_dec+0x1b/0x50
[] static_key_disable+0x20/0x30
[] sched_feat_write+0x131/0x170
[] full_proxy_write+0x97/0xd0
[] __vfs_write+0x28/0x120
[] vfs_write+0xb5/0x1a0
[] SyS_write+0x49/0xa0
[] entry_SYSCALL_64_fastpath+0x23/0xc2
This is because of the cpu hotplug lock rework. Break the chain at #1
by reversing the lock acquisition order. This way i_mutex_key#4 no
longer depends on cpu_hotplug_lock and things are good.
Cc: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Signed-off-by: Jens Axboe <axboe(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-mq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2014,15 +2014,15 @@ struct request_queue *blk_mq_init_alloca
blk_mq_init_cpu_queues(q, set->nr_hw_queues);
- get_online_cpus();
mutex_lock(&all_q_mutex);
+ get_online_cpus();
list_add_tail(&q->all_q_node, &all_q_list);
blk_mq_add_queue_tag_set(set, q);
blk_mq_map_swqueue(q, cpu_online_mask);
- mutex_unlock(&all_q_mutex);
put_online_cpus();
+ mutex_unlock(&all_q_mutex);
return q;
Patches currently in stable-queue which might be from peterz(a)infradead.org are
queue-4.9/acpi-processor-fix-error-handling-in-__acpi_processor_start.patch
queue-4.9/x86-reboot-turn-off-kvm-when-halting-a-cpu.patch
queue-4.9/block-mq-cure-cpu-hotplug-lock-inversion.patch
queue-4.9/acpi-processor-replace-racy-task-affinity-logic.patch
queue-4.9/perf-tests-kmod-path-don-t-fail-if-compressed-modules-aren-t-supported.patch
queue-4.9/cpufreq-sh-replace-racy-task-affinity-logic.patch
queue-4.9/x86-kaslr-fix-kexec-kernel-boot-crash-when-kaslr-randomization-fails.patch
This is a note to let you know that I've just added the patch titled
ath10k: handling qos at STA side based on AP WMM enable/disable
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:
ath10k-handling-qos-at-sta-side-based-on-ap-wmm-enable-disable.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: Balaji Pothunoori <bpothuno(a)qti.qualcomm.com>
Date: Thu, 7 Dec 2017 16:58:04 +0200
Subject: ath10k: handling qos at STA side based on AP WMM enable/disable
From: Balaji Pothunoori <bpothuno(a)qti.qualcomm.com>
[ Upstream commit 07ffb4497360ae8789f05555fec8171ee952304d ]
Data packets are not sent by STA in case of STA joined to
non QOS AP (WMM disabled AP). This is happening because of STA
is sending data packets to firmware from host with qos enabled
along with non qos queue value(TID = 16).
Due to qos enabled, firmware is discarding the packet.
This patch fixes this issue by updating the qos based on station
WME capability field if WMM is disabled in AP.
This patch is required by 10.4 family chipsets like
QCA4019/QCA9888/QCA9884/QCA99X0.
Firmware Versoin : 10.4-3.5.1-00018.
For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch
has no effect.
Signed-off-by: Balaji Pothunoori <bpothuno(a)qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,7 +2505,7 @@ static void ath10k_peer_assoc_h_qos(stru
}
break;
case WMI_VDEV_TYPE_STA:
- if (vif->bss_conf.qos)
+ if (sta->wme)
arg->peer_flags |= arvif->ar->wmi.peer_flags->qos;
break;
case WMI_VDEV_TYPE_IBSS:
Patches currently in stable-queue which might be from bpothuno(a)qti.qualcomm.com are
queue-4.9/ath10k-handling-qos-at-sta-side-based-on-ap-wmm-enable-disable.patch
This is a note to let you know that I've just added the patch titled
ath10k: fix out of bounds access to local buffer
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:
ath10k-fix-out-of-bounds-access-to-local-buffer.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: Michael Mera <dev(a)michaelmera.com>
Date: Mon, 24 Apr 2017 16:11:57 +0900
Subject: ath10k: fix out of bounds access to local buffer
From: Michael Mera <dev(a)michaelmera.com>
[ Upstream commit a16703aaeaedec7a8bee5be5522c7c3e75478951 ]
During write to debugfs file simulate_fw_crash, fixed-size local buffer
'buf' is accessed and modified at index 'count-1', where 'count' is the
size of the write (so potentially out of bounds).
This patch fixes this problem.
Signed-off-by: Michael Mera <dev(a)michaelmera.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/debug.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -624,17 +624,21 @@ static ssize_t ath10k_write_simulate_fw_
size_t count, loff_t *ppos)
{
struct ath10k *ar = file->private_data;
- char buf[32];
+ char buf[32] = {0};
+ ssize_t rc;
int ret;
- simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, user_buf, count);
+ /* filter partial writes and invalid commands */
+ if (*ppos != 0 || count >= sizeof(buf) || count == 0)
+ return -EINVAL;
- /* make sure that buf is null terminated */
- buf[sizeof(buf) - 1] = 0;
+ rc = simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, user_buf, count);
+ if (rc < 0)
+ return rc;
/* drop the possible '\n' from the end */
- if (buf[count - 1] == '\n')
- buf[count - 1] = 0;
+ if (buf[*ppos - 1] == '\n')
+ buf[*ppos - 1] = '\0';
mutex_lock(&ar->conf_mutex);
Patches currently in stable-queue which might be from dev(a)michaelmera.com are
queue-4.9/ath10k-fix-out-of-bounds-access-to-local-buffer.patch
This is a note to let you know that I've just added the patch titled
ath: Fix updating radar flags for coutry code India
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:
ath-fix-updating-radar-flags-for-coutry-code-india.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: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Date: Wed, 12 Apr 2017 23:19:37 +0530
Subject: ath: Fix updating radar flags for coutry code India
From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
[ Upstream commit c0c345d4cacc6a1f39d4856f37dcf6e34f51a5e4 ]
As per latest regulatory update for India, channel 52, 56, 60, 64
is no longer restricted to DFS. Enabling DFS/no infra flags in driver
results in applying all DFS related restrictions (like doing CAC etc
before this channel moves to 'available state') for these channels
even though the country code is programmed as 'India' in he hardware,
fix this by relaxing the frequency range while applying RADAR flags
only if the country code is programmed to India. If the frequency range
needs to modified based on different country code, ath_is_radar_freq
can be extended/modified dynamically.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/regd.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -254,8 +254,12 @@ bool ath_is_49ghz_allowed(u16 regdomain)
EXPORT_SYMBOL(ath_is_49ghz_allowed);
/* Frequency is one where radar detection is required */
-static bool ath_is_radar_freq(u16 center_freq)
+static bool ath_is_radar_freq(u16 center_freq,
+ struct ath_regulatory *reg)
+
{
+ if (reg->country_code == CTRY_INDIA)
+ return (center_freq >= 5500 && center_freq <= 5700);
return (center_freq >= 5260 && center_freq <= 5700);
}
@@ -306,7 +310,7 @@ __ath_reg_apply_beaconing_flags(struct w
enum nl80211_reg_initiator initiator,
struct ieee80211_channel *ch)
{
- if (ath_is_radar_freq(ch->center_freq) ||
+ if (ath_is_radar_freq(ch->center_freq, reg) ||
(ch->flags & IEEE80211_CHAN_RADAR))
return;
@@ -395,8 +399,9 @@ ath_reg_apply_ir_flags(struct wiphy *wip
}
}
-/* Always apply Radar/DFS rules on freq range 5260 MHz - 5700 MHz */
-static void ath_reg_apply_radar_flags(struct wiphy *wiphy)
+/* Always apply Radar/DFS rules on freq range 5500 MHz - 5700 MHz */
+static void ath_reg_apply_radar_flags(struct wiphy *wiphy,
+ struct ath_regulatory *reg)
{
struct ieee80211_supported_band *sband;
struct ieee80211_channel *ch;
@@ -409,7 +414,7 @@ static void ath_reg_apply_radar_flags(st
for (i = 0; i < sband->n_channels; i++) {
ch = &sband->channels[i];
- if (!ath_is_radar_freq(ch->center_freq))
+ if (!ath_is_radar_freq(ch->center_freq, reg))
continue;
/* We always enable radar detection/DFS on this
* frequency range. Additionally we also apply on
@@ -505,7 +510,7 @@ void ath_reg_notifier_apply(struct wiphy
struct ath_common *common = container_of(reg, struct ath_common,
regulatory);
/* We always apply this */
- ath_reg_apply_radar_flags(wiphy);
+ ath_reg_apply_radar_flags(wiphy, reg);
/*
* This would happen when we have sent a custom regulatory request
@@ -653,7 +658,7 @@ ath_regd_init_wiphy(struct ath_regulator
}
wiphy_apply_custom_regulatory(wiphy, regd);
- ath_reg_apply_radar_flags(wiphy);
+ ath_reg_apply_radar_flags(wiphy, reg);
ath_reg_apply_world_flags(wiphy, NL80211_REGDOM_SET_BY_DRIVER, reg);
return 0;
}
Patches currently in stable-queue which might be from mohammed(a)qti.qualcomm.com are
queue-4.9/mac80211-fix-possible-sband-related-null-pointer-de-reference.patch
queue-4.9/ath-fix-updating-radar-flags-for-coutry-code-india.patch
This is a note to let you know that I've just added the patch titled
ASoC: Intel: Skylake: Uninitialized variable in probe_codec()
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:
asoc-intel-skylake-uninitialized-variable-in-probe_codec.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: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Thu, 20 Apr 2017 13:17:02 +0300
Subject: ASoC: Intel: Skylake: Uninitialized variable in probe_codec()
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit e6a33532affd14c12688c0e9b2e773e8b2550f3b ]
My static checker complains that if snd_hdac_bus_get_response() returns
-EIO then "res" is uninitialized. Fix this by initializing it to -1 so
that the error is handled correctly.
Fixes: d8c2dab8381d ("ASoC: Intel: Add Skylake HDA audio driver")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/intel/skylake/skl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/soc/intel/skylake/skl.c
+++ b/sound/soc/intel/skylake/skl.c
@@ -457,7 +457,7 @@ static int probe_codec(struct hdac_ext_b
struct hdac_bus *bus = ebus_to_hbus(ebus);
unsigned int cmd = (addr << 28) | (AC_NODE_ROOT << 20) |
(AC_VERB_PARAMETERS << 8) | AC_PAR_VENDOR_ID;
- unsigned int res;
+ unsigned int res = -1;
mutex_lock(&bus->cmd_mutex);
snd_hdac_bus_send_cmd(bus, cmd);
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/netfilter-x_tables-unlock-on-error-in-xt_find_table_lock.patch
queue-4.9/asoc-intel-skylake-uninitialized-variable-in-probe_codec.patch
queue-4.9/mmc-host-omap_hsmmc-checking-for-null-instead-of-is_err.patch
queue-4.9/qed-unlock-on-error-in-qed_vf_pf_acquire.patch
queue-4.9/hsi-ssi_protocol-double-free-in-ssip_pn_xmit.patch
queue-4.9/cifs-small-underflow-in-cnvrtdosunixtm.patch
queue-4.9/ib-rdmavt-restore-irqs-on-error-path-in-rvt_create_ah.patch
This is a note to let you know that I've just added the patch titled
ASoC: Intel: Atom: update Thinkpad 10 quirk
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:
asoc-intel-atom-update-thinkpad-10-quirk.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: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
Date: Mon, 17 Apr 2017 10:04:07 -0500
Subject: ASoC: Intel: Atom: update Thinkpad 10 quirk
From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
[ Upstream commit beb5989a8c6c6867b4e873cca2a66d31f977368f ]
There are multiple skews of the same Lenovo audio hardware
based on the Realtek RT5670 codec.
Manufacturer: LENOVO
Product Name: 20C1CTO1WW
Version: ThinkPad 10
Manufacturer: LENOVO
Product Name: 20C3001VHH
Version: ThinkPad 10
Manufacturer: LENOVO
Product Name: 20C10024GE
Version: ThinkPad Tablet B
Manufacturer: LENOVO
Product Name: 20359
Version: Lenovo Miix 2 10
For all these devices, the same quirk is used to force
the machine driver to be based on RT5670 instead of RT5640
as indicated by the BIOS.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96691
Tested-by: Nicole Faerber <nicole.faerber(a)dpin.de>
Tested-by: Viacheslav Ostroukh <v.dev(a)ostroukh.me>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/intel/atom/sst/sst_acpi.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
--- a/sound/soc/intel/atom/sst/sst_acpi.c
+++ b/sound/soc/intel/atom/sst/sst_acpi.c
@@ -420,7 +420,21 @@ static const struct dmi_system_id byt_ta
.callback = byt_thinkpad10_quirk_cb,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_MATCH(DMI_PRODUCT_NAME, "20C3001VHH"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad 10"),
+ },
+ },
+ {
+ .callback = byt_thinkpad10_quirk_cb,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad Tablet B"),
+ },
+ },
+ {
+ .callback = byt_thinkpad10_quirk_cb,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo Miix 2 10"),
},
},
{ }
Patches currently in stable-queue which might be from pierre-louis.bossart(a)linux.intel.com are
queue-4.9/asoc-intel-atom-update-thinkpad-10-quirk.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: aspeed-evb: Add unit name to memory node
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:
arm-dts-aspeed-evb-add-unit-name-to-memory-node.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: Joel Stanley <joel(a)jms.id.au>
Date: Mon, 18 Dec 2017 23:27:03 +1030
Subject: ARM: dts: aspeed-evb: Add unit name to memory node
From: Joel Stanley <joel(a)jms.id.au>
[ Upstream commit e40ed274489a5f516da120186578eb379b452ac6 ]
Fixes a warning when building with W=1.
All of the ASPEED device trees build without warnings now.
Signed-off-by: Joel Stanley <joel(a)jms.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/aspeed-ast2500-evb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/aspeed-ast2500-evb.dts
+++ b/arch/arm/boot/dts/aspeed-ast2500-evb.dts
@@ -15,7 +15,7 @@
bootargs = "console=ttyS4,115200 earlyprintk";
};
- memory {
+ memory@80000000 {
reg = <0x80000000 0x20000000>;
};
};
Patches currently in stable-queue which might be from joel(a)jms.id.au are
queue-4.9/arm-dts-aspeed-evb-add-unit-name-to-memory-node.patch
This is a note to let you know that I've just added the patch titled
ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP
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:
arm-dra7-clockdomain-change-the-clktrctrl-of-cm_pcie_clkstctrl-to-sw_wkup.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: Kishon Vijay Abraham I <kishon(a)ti.com>
Date: Mon, 27 Mar 2017 15:15:20 +0530
Subject: ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP
From: Kishon Vijay Abraham I <kishon(a)ti.com>
[ Upstream commit 2c949ce38f4e81d7487f165fa3b8f77d74a2a6c4 ]
The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should be
set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO in RC
mode. However in EP mode, the host system is not able to access the
MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.
Acked-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/mach-omap2/clockdomains7xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
@@ -524,7 +524,7 @@ static struct clockdomain pcie_7xx_clkdm
.dep_bit = DRA7XX_PCIE_STATDEP_SHIFT,
.wkdep_srcs = pcie_wkup_sleep_deps,
.sleepdep_srcs = pcie_wkup_sleep_deps,
- .flags = CLKDM_CAN_HWSUP_SWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
static struct clockdomain atl_7xx_clkdm = {
Patches currently in stable-queue which might be from kishon(a)ti.com are
queue-4.9/arm-dra7-clockdomain-change-the-clktrctrl-of-cm_pcie_clkstctrl-to-sw_wkup.patch
queue-4.9/mmc-host-omap_hsmmc-checking-for-null-instead-of-is_err.patch
This is a note to let you know that I've just added the patch titled
ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA and !FRAME_POINTER
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:
arm-8668-1-ftrace-fix-dynamic-ftrace-with-debug_rodata-and-frame_pointer.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: Abel Vesa <abelvesa(a)linux.com>
Date: Mon, 3 Apr 2017 23:58:54 +0100
Subject: ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA and !FRAME_POINTER
From: Abel Vesa <abelvesa(a)linux.com>
[ Upstream commit 6f05d0761af612e04572ba4d65b4c0274a88444f ]
The support for dynamic ftrace with CONFIG_DEBUG_RODATA involves
overriding the weak arch_ftrace_update_code() with a variant which makes
the kernel text writable around the patching.
This override was however added under the CONFIG_OLD_MCOUNT ifdef, and
CONFIG_OLD_MCOUNT is only enabled if frame pointers are enabled.
This leads to non-functional dynamic ftrace (ftrace triggers a
WARN_ON()) when CONFIG_DEBUG_RODATA is enabled and CONFIG_FRAME_POINTER
is not.
Move the override out of that ifdef and into the CONFIG_DYNAMIC_FTRACE
ifdef where it belongs.
Fixes: 80d6b0c2eed2a ("ARM: mm: allow text and rodata sections to be read-only")
Suggested-by: Nicolai Stange <nicstange(a)gmail.com>
Suggested-by: Rabin Vincent <rabin(a)rab.in>
Signed-off-by: Abel Vesa <abelvesa(a)gmail.com>
Acked-by: Rabin Vincent <rabin(a)rab.in>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/kernel/ftrace.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -29,11 +29,6 @@
#endif
#ifdef CONFIG_DYNAMIC_FTRACE
-#ifdef CONFIG_OLD_MCOUNT
-#define OLD_MCOUNT_ADDR ((unsigned long) mcount)
-#define OLD_FTRACE_ADDR ((unsigned long) ftrace_caller_old)
-
-#define OLD_NOP 0xe1a00000 /* mov r0, r0 */
static int __ftrace_modify_code(void *data)
{
@@ -51,6 +46,12 @@ void arch_ftrace_update_code(int command
stop_machine(__ftrace_modify_code, &command, NULL);
}
+#ifdef CONFIG_OLD_MCOUNT
+#define OLD_MCOUNT_ADDR ((unsigned long) mcount)
+#define OLD_FTRACE_ADDR ((unsigned long) ftrace_caller_old)
+
+#define OLD_NOP 0xe1a00000 /* mov r0, r0 */
+
static unsigned long ftrace_nop_replace(struct dyn_ftrace *rec)
{
return rec->arch.old_mcount ? OLD_NOP : NOP;
Patches currently in stable-queue which might be from abelvesa(a)linux.com are
queue-4.9/arm-8668-1-ftrace-fix-dynamic-ftrace-with-debug_rodata-and-frame_pointer.patch
This is a note to let you know that I've just added the patch titled
ALSA: hda - Fix headset microphone detection for ASUS N551 and N751
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:
alsa-hda-fix-headset-microphone-detection-for-asus-n551-and-n751.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: Mikhail Paulyshka <me(a)mixaill.tk>
Date: Fri, 21 Apr 2017 08:52:42 +0200
Subject: ALSA: hda - Fix headset microphone detection for ASUS N551 and N751
From: Mikhail Paulyshka <me(a)mixaill.tk>
[ Upstream commit fc7438b1eb12b6c93d7b7a62423779eb5dfc673c ]
Headset microphone does not work out of the box on ASUS Nx51
laptops. This patch fixes it.
Patch tested on Asus N551 laptop. Asus N751 part is not tested, but
according to [1] this laptop uses the same audiosystem.
1. https://bugzilla.kernel.org/show_bug.cgi?id=117781
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195437
Signed-off-by: Mikhail Paulyshka <me(a)mixaill.tk>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6780,6 +6780,7 @@ enum {
ALC668_FIXUP_DELL_DISABLE_AAMIX,
ALC668_FIXUP_DELL_XPS13,
ALC662_FIXUP_ASUS_Nx50,
+ ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE,
ALC668_FIXUP_ASUS_Nx51,
ALC891_FIXUP_HEADSET_MODE,
ALC891_FIXUP_DELL_MIC_NO_PRESENCE,
@@ -7031,14 +7032,21 @@ static const struct hda_fixup alc662_fix
.chained = true,
.chain_id = ALC662_FIXUP_BASS_1A
},
+ [ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc_fixup_headset_mode_alc668,
+ .chain_id = ALC662_FIXUP_BASS_CHMAP
+ },
[ALC668_FIXUP_ASUS_Nx51] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
- {0x1a, 0x90170151}, /* bass speaker */
+ { 0x19, 0x03a1913d }, /* use as headphone mic, without its own jack detect */
+ { 0x1a, 0x90170151 }, /* bass speaker */
+ { 0x1b, 0x03a1113c }, /* use as headset mic, without its own jack detect */
{}
},
.chained = true,
- .chain_id = ALC662_FIXUP_BASS_CHMAP,
+ .chain_id = ALC668_FIXUP_ASUS_Nx51_HEADSET_MODE,
},
[ALC891_FIXUP_HEADSET_MODE] = {
.type = HDA_FIXUP_FUNC,
Patches currently in stable-queue which might be from me(a)mixaill.tk are
queue-4.9/alsa-hda-fix-headset-microphone-detection-for-asus-n551-and-n751.patch
This is a note to let you know that I've just added the patch titled
ACPICA: iasl: Fix IORT SMMU GSI disassembling
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:
acpica-iasl-fix-iort-smmu-gsi-disassembling.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: Lv Zheng <lv.zheng(a)intel.com>
Date: Wed, 26 Apr 2017 16:18:49 +0800
Subject: ACPICA: iasl: Fix IORT SMMU GSI disassembling
From: Lv Zheng <lv.zheng(a)intel.com>
[ Upstream commit bb1e23e66e6237ff7a1824b37366540a89149c33 ]
ACPICA commit 637b88de24a78c20478728d9d66632b06fcaa5bf
If the IORT template is compiled and then iort.aml binary disassembled to
iort.dsl, SMMUv1 node lists incorrect offset for SMMU_Nsg_cfg_irpt Interrupt:
[0ECh 0236 8] SMMU_Nsg_irpt Interrupt : 0000000000000000
[0ECh 0236 8] SMMU_Nsg_cfg_irpt Interrupt : 0000000000000000
This is because iasl hasn't implemented SMMU GSI decoding yet.
This patch fixes this issue by preparing structures for decoding IORT SMMU
GSI. ACPICA BZ 1340, reported by Alexei Fedorov, fixed by Lv Zheng.
Link: https://github.com/acpica/acpica/commit/637b88de
Link: https://bugs.acpica.org/show_bug.cgi?id=1340
Reported-by: Alexei Fedorov <Alexei.Fedorov(a)arm.com>
Signed-off-by: Lv Zheng <lv.zheng(a)intel.com>
Signed-off-by: Bob Moore <robert.moore(a)intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/acpi/actbl2.h | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -783,6 +783,15 @@ struct acpi_iort_smmu {
#define ACPI_IORT_SMMU_DVM_SUPPORTED (1)
#define ACPI_IORT_SMMU_COHERENT_WALK (1<<1)
+/* Global interrupt format */
+
+struct acpi_iort_smmu_gsi {
+ u32 nsg_irpt;
+ u32 nsg_irpt_flags;
+ u32 nsg_cfg_irpt;
+ u32 nsg_cfg_irpt_flags;
+};
+
struct acpi_iort_smmu_v3 {
u64 base_address; /* SMMUv3 base address */
u32 flags;
Patches currently in stable-queue which might be from lv.zheng(a)intel.com are
queue-4.9/acpica-iasl-fix-iort-smmu-gsi-disassembling.patch
This is a note to let you know that I've just added the patch titled
ACPI/processor: Replace racy task affinity logic
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:
acpi-processor-replace-racy-task-affinity-logic.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: Thomas Gleixner <tglx(a)linutronix.de>
Date: Wed, 12 Apr 2017 22:07:34 +0200
Subject: ACPI/processor: Replace racy task affinity logic
From: Thomas Gleixner <tglx(a)linutronix.de>
[ Upstream commit 8153f9ac43897f9f4786b30badc134fcc1a4fb11 ]
acpi_processor_get_throttling() requires to invoke the getter function on
the target CPU. This is achieved by temporarily setting the affinity of the
calling user space thread to the requested CPU and reset it to the original
affinity afterwards.
That's racy vs. CPU hotplug and concurrent affinity settings for that
thread resulting in code executing on the wrong CPU and overwriting the
new affinity setting.
acpi_processor_get_throttling() is invoked in two ways:
1) The CPU online callback, which is already running on the target CPU and
obviously protected against hotplug and not affected by affinity
settings.
2) The ACPI driver probe function, which is not protected against hotplug
during modprobe.
Switch it over to work_on_cpu() and protect the probe function against CPU
hotplug.
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Fenghua Yu <fenghua.yu(a)intel.com>
Cc: Tony Luck <tony.luck(a)intel.com>
Cc: Herbert Xu <herbert(a)gondor.apana.org.au>
Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Cc: Sebastian Siewior <bigeasy(a)linutronix.de>
Cc: Lai Jiangshan <jiangshanlai(a)gmail.com>
Cc: linux-acpi(a)vger.kernel.org
Cc: Viresh Kumar <viresh.kumar(a)linaro.org>
Cc: Michael Ellerman <mpe(a)ellerman.id.au>
Cc: Tejun Heo <tj(a)kernel.org>
Cc: "David S. Miller" <davem(a)davemloft.net>
Cc: Len Brown <lenb(a)kernel.org>
Link: http://lkml.kernel.org/r/20170412201042.785920903@linutronix.de
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/acpi/processor_driver.c | 7 +++-
drivers/acpi/processor_throttling.c | 62 ++++++++++++++++++++----------------
2 files changed, 42 insertions(+), 27 deletions(-)
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -262,11 +262,16 @@ err_power_exit:
static int acpi_processor_start(struct device *dev)
{
struct acpi_device *device = ACPI_COMPANION(dev);
+ int ret;
if (!device)
return -ENODEV;
- return __acpi_processor_start(device);
+ /* Protect against concurrent CPU hotplug operations */
+ get_online_cpus();
+ ret = __acpi_processor_start(device);
+ put_online_cpus();
+ return ret;
}
static int acpi_processor_stop(struct device *dev)
--- a/drivers/acpi/processor_throttling.c
+++ b/drivers/acpi/processor_throttling.c
@@ -62,8 +62,8 @@ struct acpi_processor_throttling_arg {
#define THROTTLING_POSTCHANGE (2)
static int acpi_processor_get_throttling(struct acpi_processor *pr);
-int acpi_processor_set_throttling(struct acpi_processor *pr,
- int state, bool force);
+static int __acpi_processor_set_throttling(struct acpi_processor *pr,
+ int state, bool force, bool direct);
static int acpi_processor_update_tsd_coord(void)
{
@@ -891,7 +891,8 @@ static int acpi_processor_get_throttling
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Invalid throttling state, reset\n"));
state = 0;
- ret = acpi_processor_set_throttling(pr, state, true);
+ ret = __acpi_processor_set_throttling(pr, state, true,
+ true);
if (ret)
return ret;
}
@@ -901,36 +902,31 @@ static int acpi_processor_get_throttling
return 0;
}
-static int acpi_processor_get_throttling(struct acpi_processor *pr)
+static long __acpi_processor_get_throttling(void *data)
{
- cpumask_var_t saved_mask;
- int ret;
+ struct acpi_processor *pr = data;
+
+ return pr->throttling.acpi_processor_get_throttling(pr);
+}
+static int acpi_processor_get_throttling(struct acpi_processor *pr)
+{
if (!pr)
return -EINVAL;
if (!pr->flags.throttling)
return -ENODEV;
- if (!alloc_cpumask_var(&saved_mask, GFP_KERNEL))
- return -ENOMEM;
-
/*
- * Migrate task to the cpu pointed by pr.
+ * This is either called from the CPU hotplug callback of
+ * processor_driver or via the ACPI probe function. In the latter
+ * case the CPU is not guaranteed to be online. Both call sites are
+ * protected against CPU hotplug.
*/
- cpumask_copy(saved_mask, ¤t->cpus_allowed);
- /* FIXME: use work_on_cpu() */
- if (set_cpus_allowed_ptr(current, cpumask_of(pr->id))) {
- /* Can't migrate to the target pr->id CPU. Exit */
- free_cpumask_var(saved_mask);
+ if (!cpu_online(pr->id))
return -ENODEV;
- }
- ret = pr->throttling.acpi_processor_get_throttling(pr);
- /* restore the previous state */
- set_cpus_allowed_ptr(current, saved_mask);
- free_cpumask_var(saved_mask);
- return ret;
+ return work_on_cpu(pr->id, __acpi_processor_get_throttling, pr);
}
static int acpi_processor_get_fadt_info(struct acpi_processor *pr)
@@ -1080,8 +1076,15 @@ static long acpi_processor_throttling_fn
arg->target_state, arg->force);
}
-int acpi_processor_set_throttling(struct acpi_processor *pr,
- int state, bool force)
+static int call_on_cpu(int cpu, long (*fn)(void *), void *arg, bool direct)
+{
+ if (direct)
+ return fn(arg);
+ return work_on_cpu(cpu, fn, arg);
+}
+
+static int __acpi_processor_set_throttling(struct acpi_processor *pr,
+ int state, bool force, bool direct)
{
int ret = 0;
unsigned int i;
@@ -1130,7 +1133,8 @@ int acpi_processor_set_throttling(struct
arg.pr = pr;
arg.target_state = state;
arg.force = force;
- ret = work_on_cpu(pr->id, acpi_processor_throttling_fn, &arg);
+ ret = call_on_cpu(pr->id, acpi_processor_throttling_fn, &arg,
+ direct);
} else {
/*
* When the T-state coordination is SW_ALL or HW_ALL,
@@ -1163,8 +1167,8 @@ int acpi_processor_set_throttling(struct
arg.pr = match_pr;
arg.target_state = state;
arg.force = force;
- ret = work_on_cpu(pr->id, acpi_processor_throttling_fn,
- &arg);
+ ret = call_on_cpu(pr->id, acpi_processor_throttling_fn,
+ &arg, direct);
}
}
/*
@@ -1182,6 +1186,12 @@ int acpi_processor_set_throttling(struct
return ret;
}
+int acpi_processor_set_throttling(struct acpi_processor *pr, int state,
+ bool force)
+{
+ return __acpi_processor_set_throttling(pr, state, force, false);
+}
+
int acpi_processor_get_throttling_info(struct acpi_processor *pr)
{
int result = 0;
Patches currently in stable-queue which might be from tglx(a)linutronix.de are
queue-4.9/acpi-processor-fix-error-handling-in-__acpi_processor_start.patch
queue-4.9/x86-reboot-turn-off-kvm-when-halting-a-cpu.patch
queue-4.9/acpi-processor-replace-racy-task-affinity-logic.patch
queue-4.9/time-change-posix-clocks-ops-interfaces-to-use-timespec64.patch
queue-4.9/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch
queue-4.9/cpufreq-sh-replace-racy-task-affinity-logic.patch
queue-4.9/irqchip-mips-gic-separate-ipi-reservation-usage-tracking.patch
queue-4.9/x86-kaslr-fix-kexec-kernel-boot-crash-when-kaslr-randomization-fails.patch
This is a note to let you know that I've just added the patch titled
ACPI/processor: Fix error handling in __acpi_processor_start()
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:
acpi-processor-fix-error-handling-in-__acpi_processor_start.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: Thomas Gleixner <tglx(a)linutronix.de>
Date: Wed, 12 Apr 2017 22:07:33 +0200
Subject: ACPI/processor: Fix error handling in __acpi_processor_start()
From: Thomas Gleixner <tglx(a)linutronix.de>
[ Upstream commit a5cbdf693a60d5b86d4d21dfedd90f17754eb273 ]
When acpi_install_notify_handler() fails the cooling device stays
registered and the sysfs files created via acpi_pss_perf_init() are
leaked and the function returns success.
Undo acpi_pss_perf_init() and return a proper error code.
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Fenghua Yu <fenghua.yu(a)intel.com>
Cc: Tony Luck <tony.luck(a)intel.com>
Cc: Herbert Xu <herbert(a)gondor.apana.org.au>
Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Cc: Sebastian Siewior <bigeasy(a)linutronix.de>
Cc: Lai Jiangshan <jiangshanlai(a)gmail.com>
Cc: linux-acpi(a)vger.kernel.org
Cc: Viresh Kumar <viresh.kumar(a)linaro.org>
Cc: Michael Ellerman <mpe(a)ellerman.id.au>
Cc: Tejun Heo <tj(a)kernel.org>
Cc: "David S. Miller" <davem(a)davemloft.net>
Cc: Len Brown <lenb(a)kernel.org>
Link: http://lkml.kernel.org/r/20170412201042.695499645@linutronix.de
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/acpi/processor_driver.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -251,6 +251,9 @@ static int __acpi_processor_start(struct
if (ACPI_SUCCESS(status))
return 0;
+ result = -ENODEV;
+ acpi_pss_perf_exit(pr, device);
+
err_power_exit:
acpi_processor_power_exit(pr);
return result;
Patches currently in stable-queue which might be from tglx(a)linutronix.de are
queue-4.9/acpi-processor-fix-error-handling-in-__acpi_processor_start.patch
queue-4.9/x86-reboot-turn-off-kvm-when-halting-a-cpu.patch
queue-4.9/acpi-processor-replace-racy-task-affinity-logic.patch
queue-4.9/time-change-posix-clocks-ops-interfaces-to-use-timespec64.patch
queue-4.9/genirq-use-irqd_get_trigger_type-to-compare-the-trigger-type-for-shared-irqs.patch
queue-4.9/cpufreq-sh-replace-racy-task-affinity-logic.patch
queue-4.9/irqchip-mips-gic-separate-ipi-reservation-usage-tracking.patch
queue-4.9/x86-kaslr-fix-kexec-kernel-boot-crash-when-kaslr-randomization-fails.patch
This is a note to let you know that I've just added the patch titled
ACPI / power: Delay turning off unused power resources after suspend
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:
acpi-power-delay-turning-off-unused-power-resources-after-suspend.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: Sun, 30 Apr 2017 22:54:16 +0200
Subject: ACPI / power: Delay turning off unused power resources after suspend
From: Hans de Goede <hdegoede(a)redhat.com>
[ Upstream commit 8ece1d83346bcc431090d59a2184276192189cdd ]
Commit 660b1113e0f3 (ACPI / PM: Fix consistency check for power resources
during resume) introduced a check for ACPI power resources which have
been turned on by the BIOS during suspend and turns these back off again.
This is causing problems on a Dell Venue Pro 11 7130 (i5-4300Y) it causes
the following messages to show up in dmesg:
[ 131.014605] ACPI: Waking up from system sleep state S3
[ 131.150271] acpi LNXPOWER:07: Turning OFF
[ 131.150323] acpi LNXPOWER:06: Turning OFF
[ 131.150911] acpi LNXPOWER:00: Turning OFF
[ 131.169014] ACPI : EC: interrupt unblocked
[ 131.181811] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
[ 133.535728] pci_raw_set_power_state: 76 callbacks suppressed
[ 133.535735] iwlwifi 0000:01:00.0: Refused to change power state,
currently in D3
[ 133.597672] PM: noirq resume of devices complete after 2428.891 msecs
Followed by a bunch of iwlwifi errors later on and the pcie device
dropping from the bus (acpiphp thinks it has been unplugged).
Disabling the turning off of unused power resources fixes this. Instead
of adding a quirk for this system, this commit fixes this by moving the
disabling of unused power resources to later in the resume sequence
when the iwlwifi card has been moved out of D3 so the ref_count for
its power resource no longer is 0.
This new behavior seems to match the intend of the original commit which
commit-msg says: "(... which means that no devices are going to need them
any time soon) and we should turn them off".
This also avoids power resources which we need when bringing devices out
of D3 from getting bounced off and then back on again.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/acpi/power.c | 10 ++++++++++
drivers/acpi/sleep.c | 1 +
drivers/acpi/sleep.h | 1 +
3 files changed, 12 insertions(+)
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -864,6 +864,16 @@ void acpi_resume_power_resources(void)
mutex_unlock(&resource->resource_lock);
}
+
+ mutex_unlock(&power_resource_list_lock);
+}
+
+void acpi_turn_off_unused_power_resources(void)
+{
+ struct acpi_power_resource *resource;
+
+ mutex_lock(&power_resource_list_lock);
+
list_for_each_entry_reverse(resource, &acpi_power_resource_list, list_node) {
int result, state;
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -474,6 +474,7 @@ static void acpi_pm_start(u32 acpi_state
*/
static void acpi_pm_end(void)
{
+ acpi_turn_off_unused_power_resources();
acpi_scan_lock_release();
/*
* This is necessary in case acpi_pm_finish() is not called during a
--- a/drivers/acpi/sleep.h
+++ b/drivers/acpi/sleep.h
@@ -6,6 +6,7 @@ extern struct list_head acpi_wakeup_devi
extern struct mutex acpi_device_lock;
extern void acpi_resume_power_resources(void);
+extern void acpi_turn_off_unused_power_resources(void);
static inline acpi_status acpi_set_waking_vector(u32 wakeup_address)
{
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
ACPI / PMIC: xpower: Fix power_table addresses
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:
acpi-pmic-xpower-fix-power_table-addresses.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, 21 Apr 2017 13:48:08 +0200
Subject: ACPI / PMIC: xpower: Fix power_table addresses
From: Hans de Goede <hdegoede(a)redhat.com>
[ Upstream commit 2bde7c32b1db162692f05c6be066b5bcd3d9fdbe ]
The power table addresses should be contiguous, but there was a hole
where 0x34 was missing. On most devices this is not a problem as
addresses above 0x34 are used for the BUC# convertors which are not
used in the DSDTs I've access to but after the BUC# convertors
there is a field named GPI1 in the DSTDs, which does get used in some
cases and ended up turning BUC6 on and off due to the wrong addresses,
resulting in turning the entire device off (or causing it to reboot).
Removing the hole in the addresses fixes this, fixing one of my
Bay Trail tablets turning off while booting the mainline kernel.
While at it add comments with the field names used in the DSDTs to
make it easier to compare the register and bits used at each address
with the datasheet.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/acpi/pmic/intel_pmic_xpower.c | 50 +++++++++++++++++-----------------
1 file changed, 25 insertions(+), 25 deletions(-)
--- a/drivers/acpi/pmic/intel_pmic_xpower.c
+++ b/drivers/acpi/pmic/intel_pmic_xpower.c
@@ -28,97 +28,97 @@ static struct pmic_table power_table[] =
.address = 0x00,
.reg = 0x13,
.bit = 0x05,
- },
+ }, /* ALD1 */
{
.address = 0x04,
.reg = 0x13,
.bit = 0x06,
- },
+ }, /* ALD2 */
{
.address = 0x08,
.reg = 0x13,
.bit = 0x07,
- },
+ }, /* ALD3 */
{
.address = 0x0c,
.reg = 0x12,
.bit = 0x03,
- },
+ }, /* DLD1 */
{
.address = 0x10,
.reg = 0x12,
.bit = 0x04,
- },
+ }, /* DLD2 */
{
.address = 0x14,
.reg = 0x12,
.bit = 0x05,
- },
+ }, /* DLD3 */
{
.address = 0x18,
.reg = 0x12,
.bit = 0x06,
- },
+ }, /* DLD4 */
{
.address = 0x1c,
.reg = 0x12,
.bit = 0x00,
- },
+ }, /* ELD1 */
{
.address = 0x20,
.reg = 0x12,
.bit = 0x01,
- },
+ }, /* ELD2 */
{
.address = 0x24,
.reg = 0x12,
.bit = 0x02,
- },
+ }, /* ELD3 */
{
.address = 0x28,
.reg = 0x13,
.bit = 0x02,
- },
+ }, /* FLD1 */
{
.address = 0x2c,
.reg = 0x13,
.bit = 0x03,
- },
+ }, /* FLD2 */
{
.address = 0x30,
.reg = 0x13,
.bit = 0x04,
- },
+ }, /* FLD3 */
{
- .address = 0x38,
+ .address = 0x34,
.reg = 0x10,
.bit = 0x03,
- },
+ }, /* BUC1 */
{
- .address = 0x3c,
+ .address = 0x38,
.reg = 0x10,
.bit = 0x06,
- },
+ }, /* BUC2 */
{
- .address = 0x40,
+ .address = 0x3c,
.reg = 0x10,
.bit = 0x05,
- },
+ }, /* BUC3 */
{
- .address = 0x44,
+ .address = 0x40,
.reg = 0x10,
.bit = 0x04,
- },
+ }, /* BUC4 */
{
- .address = 0x48,
+ .address = 0x44,
.reg = 0x10,
.bit = 0x01,
- },
+ }, /* BUC5 */
{
- .address = 0x4c,
+ .address = 0x48,
.reg = 0x10,
.bit = 0x00
- },
+ }, /* BUC6 */
};
/* TMP0 - TMP5 are the same, all from GPADC */
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