This is a note to let you know that I've just added the patch titled
block: fix an error code in add_partition()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
block-fix-an-error-code-in-add_partition.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Tue, 23 May 2017 17:28:36 +0300
Subject: block: fix an error code in add_partition()
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 7bd897cfce1eb373892d35d7f73201b0f9b221c4 ]
We don't set an error code on this path. It means that we return NULL
instead of an error pointer and the caller does a NULL dereference.
Fixes: 6d1d8050b4bc ("block, partition: add partition_meta_info to hd_struct")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
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/partition-generic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -309,8 +309,10 @@ struct hd_struct *add_partition(struct g
if (info) {
struct partition_meta_info *pinfo = alloc_part_info(disk);
- if (!pinfo)
+ if (!pinfo) {
+ err = -ENOMEM;
goto out_free_stats;
+ }
memcpy(pinfo, info, sizeof(*info));
p->info = pinfo;
}
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.4/block-fix-an-error-code-in-add_partition.patch
queue-4.4/pnfs-flexfiles-missing-error-code-in-ff_layout_alloc_lseg.patch
queue-4.4/drivers-misc-vmw_vmci-vmci_queue_pair.c-fix-a-couple-integer-overflow-tests.patch
queue-4.4/md-cluster-fix-potential-lock-issue-in-add_new_disk.patch
queue-4.4/ipmi_ssif-unlock-on-allocation-failure.patch
queue-4.4/powercap-fix-an-error-code-in-powercap_register_zone.patch
queue-4.4/libceph-null-deref-on-crush_decode-error-path.patch
This is a note to let you know that I've just added the patch titled
blk-mq: NVMe 512B/4K+T10 DIF/DIX format returns I/O error on dd with split op
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
blk-mq-nvme-512b-4k-t10-dif-dix-format-returns-i-o-error-on-dd-with-split-op.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Wen Xiong <wenxiong(a)linux.vnet.ibm.com>
Date: Wed, 10 May 2017 08:54:11 -0500
Subject: blk-mq: NVMe 512B/4K+T10 DIF/DIX format returns I/O error on dd with split op
From: Wen Xiong <wenxiong(a)linux.vnet.ibm.com>
[ Upstream commit f36ea50ca0043e7b1204feaf1d2ba6bd68c08d36 ]
When formatting NVMe to 512B/4K + T10 DIf/DIX, dd with split op returns
"Input/output error". Looks block layer split the bio after calling
bio_integrity_prep(bio). This patch fixes the issue.
Below is how we debug this issue:
(1)format nvme to 4K block # size with type 2 DIF
(2)dd with block size bigger than 1024k.
oflag=direct
dd: error writing '/dev/nvme0n1': Input/output error
We added some debug code in nvme device driver. It showed us the first
op and the second op have the same bi and pi address. This is not
correct.
1st op: nvme0n1 Op:Wr slba 0x505 length 0x100, PI ctrl=0x1400,
dsmgmt=0x0, AT=0x0 & RT=0x505
Guard 0x00b1, AT 0x0000, RT physical 0x00000505 RT virtual 0x00002828
2nd op: nvme0n1 Op:Wr slba 0x605 length 0x1, PI ctrl=0x1400, dsmgmt=0x0,
AT=0x0 & RT=0x605 ==> This op fails and subsequent 5 retires..
Guard 0x00b1, AT 0x0000, RT physical 0x00000605 RT virtual 0x00002828
With the fix, It showed us both of the first op and the second op have
correct bi and pi address.
1st op: nvme2n1 Op:Wr slba 0x505 length 0x100, PI ctrl=0x1400,
dsmgmt=0x0, AT=0x0 & RT=0x505
Guard 0x5ccb, AT 0x0000, RT physical 0x00000505 RT virtual
0x00002828
2nd op: nvme2n1 Op:Wr slba 0x605 length 0x1, PI ctrl=0x1400, dsmgmt=0x0,
AT=0x0 & RT=0x605
Guard 0xab4c, AT 0x0000, RT physical 0x00000605 RT virtual
0x00003028
Signed-off-by: Wen Xiong <wenxiong(a)linux.vnet.ibm.com>
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
@@ -1252,13 +1252,13 @@ static blk_qc_t blk_mq_make_request(stru
blk_queue_bounce(q, &bio);
+ blk_queue_split(q, &bio, q->bio_split);
+
if (bio_integrity_enabled(bio) && bio_integrity_prep(bio)) {
bio_io_error(bio);
return BLK_QC_T_NONE;
}
- blk_queue_split(q, &bio, q->bio_split);
-
if (!is_flush_fua && !blk_queue_nomerges(q) &&
blk_attempt_plug_merge(q, bio, &request_count, &same_queue_rq))
return BLK_QC_T_NONE;
Patches currently in stable-queue which might be from wenxiong(a)linux.vnet.ibm.com are
queue-4.4/blk-mq-nvme-512b-4k-t10-dif-dix-format-returns-i-o-error-on-dd-with-split-op.patch
This is a note to let you know that I've just added the patch titled
bio-integrity: Do not allocate integrity context for bio w/o data
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bio-integrity-do-not-allocate-integrity-context-for-bio-w-o-data.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Dmitry Monakhov <dmonakhov(a)openvz.org>
Date: Wed, 10 May 2017 19:20:44 +0400
Subject: bio-integrity: Do not allocate integrity context for bio w/o data
From: Dmitry Monakhov <dmonakhov(a)openvz.org>
[ Upstream commit 3116a23bb30272d74ea81baf5d0ee23f602dd15b ]
If bio has no data, such as ones from blkdev_issue_flush(),
then we have nothing to protect.
This patch prevent bugon like follows:
kfree_debugcheck: out of range ptr ac1fa1d106742a5ah
kernel BUG at mm/slab.c:2773!
invalid opcode: 0000 [#1] SMP
Modules linked in: bcache
CPU: 0 PID: 4428 Comm: xfs_io Tainted: G W 4.11.0-rc4-ext4-00041-g2ef0043-dirty #43
Hardware name: Virtuozzo KVM, BIOS seabios-1.7.5-11.vz7.4 04/01/2014
task: ffff880137786440 task.stack: ffffc90000ba8000
RIP: 0010:kfree_debugcheck+0x25/0x2a
RSP: 0018:ffffc90000babde0 EFLAGS: 00010082
RAX: 0000000000000034 RBX: ac1fa1d106742a5a RCX: 0000000000000007
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88013f3ccb40
RBP: ffffc90000babde8 R08: 0000000000000000 R09: 0000000000000000
R10: 00000000fcb76420 R11: 00000000725172ed R12: 0000000000000282
R13: ffffffff8150e766 R14: ffff88013a145e00 R15: 0000000000000001
FS: 00007fb09384bf40(0000) GS:ffff88013f200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd0172f9e40 CR3: 0000000137fa9000 CR4: 00000000000006f0
Call Trace:
kfree+0xc8/0x1b3
bio_integrity_free+0xc3/0x16b
bio_free+0x25/0x66
bio_put+0x14/0x26
blkdev_issue_flush+0x7a/0x85
blkdev_fsync+0x35/0x42
vfs_fsync_range+0x8e/0x9f
vfs_fsync+0x1c/0x1e
do_fsync+0x31/0x4a
SyS_fsync+0x10/0x14
entry_SYSCALL_64_fastpath+0x1f/0xc2
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Dmitry Monakhov <dmonakhov(a)openvz.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/bio-integrity.c | 3 +++
1 file changed, 3 insertions(+)
--- a/block/bio-integrity.c
+++ b/block/bio-integrity.c
@@ -175,6 +175,9 @@ bool bio_integrity_enabled(struct bio *b
if (!bio_is_rw(bio))
return false;
+ if (!bio_sectors(bio))
+ return false;
+
/* Already protected? */
if (bio_integrity(bio))
return false;
Patches currently in stable-queue which might be from dmonakhov(a)openvz.org are
queue-4.4/bio-integrity-do-not-allocate-integrity-context-for-bio-w-o-data.patch
This is a note to let you know that I've just added the patch titled
bcache: stop writeback thread after detaching
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bcache-stop-writeback-thread-after-detaching.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Tang Junhui <tang.junhui(a)zte.com.cn>
Date: Mon, 8 Jan 2018 12:21:19 -0800
Subject: bcache: stop writeback thread after detaching
From: Tang Junhui <tang.junhui(a)zte.com.cn>
[ Upstream commit 8d29c4426b9f8afaccf28de414fde8a722b35fdf ]
Currently, when a cached device detaching from cache, writeback thread is
not stopped, and writeback_rate_update work is not canceled. For example,
after the following command:
echo 1 >/sys/block/sdb/bcache/detach
you can still see the writeback thread. Then you attach the device to the
cache again, bcache will create another writeback thread, for example,
after below command:
echo ba0fb5cd-658a-4533-9806-6ce166d883b9 > /sys/block/sdb/bcache/attach
then you will see 2 writeback threads.
This patch stops writeback thread and cancels writeback_rate_update work
when cached device detaching from cache.
Compare with patch v1, this v2 patch moves code down into the register
lock for safety in case of any future changes as Coly and Mike suggested.
[edit by mlyle: commit log spelling/formatting]
Signed-off-by: Tang Junhui <tang.junhui(a)zte.com.cn>
Reviewed-by: Michael Lyle <mlyle(a)lyle.org>
Signed-off-by: Michael Lyle <mlyle(a)lyle.org>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bcache/super.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -890,6 +890,12 @@ static void cached_dev_detach_finish(str
mutex_lock(&bch_register_lock);
+ cancel_delayed_work_sync(&dc->writeback_rate_update);
+ if (!IS_ERR_OR_NULL(dc->writeback_thread)) {
+ kthread_stop(dc->writeback_thread);
+ dc->writeback_thread = NULL;
+ }
+
memset(&dc->sb.set_uuid, 0, 16);
SET_BDEV_STATE(&dc->sb, BDEV_STATE_NONE);
Patches currently in stable-queue which might be from tang.junhui(a)zte.com.cn are
queue-4.4/bcache-segregate-flash-only-volume-write-streams.patch
queue-4.4/bcache-stop-writeback-thread-after-detaching.patch
This is a note to let you know that I've just added the patch titled
bcache: segregate flash only volume write streams
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bcache-segregate-flash-only-volume-write-streams.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Tang Junhui <tang.junhui(a)zte.com.cn>
Date: Mon, 8 Jan 2018 12:21:21 -0800
Subject: bcache: segregate flash only volume write streams
From: Tang Junhui <tang.junhui(a)zte.com.cn>
[ Upstream commit 4eca1cb28d8b0574ca4f1f48e9331c5f852d43b9 ]
In such scenario that there are some flash only volumes
, and some cached devices, when many tasks request these devices in
writeback mode, the write IOs may fall to the same bucket as bellow:
| cached data | flash data | cached data | cached data| flash data|
then after writeback of these cached devices, the bucket would
be like bellow bucket:
| free | flash data | free | free | flash data |
So, there are many free space in this bucket, but since data of flash
only volumes still exists, so this bucket cannot be reclaimable,
which would cause waste of bucket space.
In this patch, we segregate flash only volume write streams from
cached devices, so data from flash only volumes and cached devices
can store in different buckets.
Compare to v1 patch, this patch do not add a additionally open bucket
list, and it is try best to segregate flash only volume write streams
from cached devices, sectors of flash only volumes may still be mixed
with dirty sectors of cached device, but the number is very small.
[mlyle: fixed commit log formatting, permissions, line endings]
Signed-off-by: Tang Junhui <tang.junhui(a)zte.com.cn>
Reviewed-by: Michael Lyle <mlyle(a)lyle.org>
Signed-off-by: Michael Lyle <mlyle(a)lyle.org>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bcache/alloc.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
--- a/drivers/md/bcache/alloc.c
+++ b/drivers/md/bcache/alloc.c
@@ -514,15 +514,21 @@ struct open_bucket {
/*
* We keep multiple buckets open for writes, and try to segregate different
- * write streams for better cache utilization: first we look for a bucket where
- * the last write to it was sequential with the current write, and failing that
- * we look for a bucket that was last used by the same task.
+ * write streams for better cache utilization: first we try to segregate flash
+ * only volume write streams from cached devices, secondly we look for a bucket
+ * where the last write to it was sequential with the current write, and
+ * failing that we look for a bucket that was last used by the same task.
*
* The ideas is if you've got multiple tasks pulling data into the cache at the
* same time, you'll get better cache utilization if you try to segregate their
* data and preserve locality.
*
- * For example, say you've starting Firefox at the same time you're copying a
+ * For example, dirty sectors of flash only volume is not reclaimable, if their
+ * dirty sectors mixed with dirty sectors of cached device, such buckets will
+ * be marked as dirty and won't be reclaimed, though the dirty data of cached
+ * device have been written back to backend device.
+ *
+ * And say you've starting Firefox at the same time you're copying a
* bunch of files. Firefox will likely end up being fairly hot and stay in the
* cache awhile, but the data you copied might not be; if you wrote all that
* data to the same buckets it'd get invalidated at the same time.
@@ -539,7 +545,10 @@ static struct open_bucket *pick_data_buc
struct open_bucket *ret, *ret_task = NULL;
list_for_each_entry_reverse(ret, &c->data_buckets, list)
- if (!bkey_cmp(&ret->key, search))
+ if (UUID_FLASH_ONLY(&c->uuids[KEY_INODE(&ret->key)]) !=
+ UUID_FLASH_ONLY(&c->uuids[KEY_INODE(search)]))
+ continue;
+ else if (!bkey_cmp(&ret->key, search))
goto found;
else if (ret->last_write_point == write_point)
ret_task = ret;
Patches currently in stable-queue which might be from tang.junhui(a)zte.com.cn are
queue-4.4/bcache-segregate-flash-only-volume-write-streams.patch
queue-4.4/bcache-stop-writeback-thread-after-detaching.patch
This is a note to let you know that I've just added the patch titled
ath5k: fix memory leak on buf on failed eeprom read
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ath5k-fix-memory-leak-on-buf-on-failed-eeprom-read.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Colin Ian King <colin.king(a)canonical.com>
Date: Wed, 3 May 2017 15:26:00 +0100
Subject: ath5k: fix memory leak on buf on failed eeprom read
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 8fed6823e06e43ee9cf7c0ffecec2f9111ce6201 ]
The AR5K_EEPROM_READ macro returns with -EIO if a read error
occurs causing a memory leak on the allocated buffer buf. Fix
this by explicitly calling ath5k_hw_nvram_read and exiting on
the via the freebuf label that performs the necessary free'ing
of buf when a read error occurs.
Detected by CoverityScan, CID#1248782 ("Resource Leak")
Signed-off-by: Colin Ian King <colin.king(a)canonical.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/ath5k/debug.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath5k/debug.c
+++ b/drivers/net/wireless/ath/ath5k/debug.c
@@ -939,7 +939,10 @@ static int open_file_eeprom(struct inode
}
for (i = 0; i < eesize; ++i) {
- AR5K_EEPROM_READ(i, val);
+ if (!ath5k_hw_nvram_read(ah, i, &val)) {
+ ret = -EIO;
+ goto freebuf;
+ }
buf[i] = val;
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.4/wl1251-check-return-from-call-to-wl1251_acx_arp_ip_filter.patch
queue-4.4/netxen_nic-set-rcode-to-the-return-status-from-the-call-to-netxen_issue_cmd.patch
queue-4.4/btrfs-fix-incorrect-error-return-ret-being-passed-to-mapping_set_error.patch
queue-4.4/ath5k-fix-memory-leak-on-buf-on-failed-eeprom-read.patch
This is a note to let you know that I've just added the patch titled
ata: libahci: properly propagate return value of platform_get_irq()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ata-libahci-properly-propagate-return-value-of-platform_get_irq.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
Date: Tue, 16 May 2017 14:06:12 +0200
Subject: ata: libahci: properly propagate return value of platform_get_irq()
From: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
[ Upstream commit c034640a32f8456018d9c8c83799ead683046b95 ]
When platform_get_irq() fails, it returns an error code, which
libahci_platform and replaces it by -EINVAL. This commit fixes that by
propagating the error code. It fixes the situation where
platform_get_irq() returns -EPROBE_DEFER because the interrupt
controller is not available yet, and generally looks like the right
thing to do.
We pay attention to not show the "no irq" message when we are in an
EPROBE_DEFER situation, because the driver probing will be retried
later on, once the interrupt controller becomes available to provide
the interrupt.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
Reviewed-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/libahci_platform.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -514,8 +514,9 @@ int ahci_platform_init_host(struct platf
irq = platform_get_irq(pdev, 0);
if (irq <= 0) {
- dev_err(dev, "no irq\n");
- return -EINVAL;
+ if (irq != -EPROBE_DEFER)
+ dev_err(dev, "no irq\n");
+ return irq;
}
hpriv->irq = irq;
Patches currently in stable-queue which might be from thomas.petazzoni(a)free-electrons.com are
queue-4.4/ata-libahci-properly-propagate-return-value-of-platform_get_irq.patch
This is a note to let you know that I've just added the patch titled
async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
async_tx-fix-dma_prep_fence-usage-in-do_async_gen_syndrome.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Anup Patel <anup.patel(a)broadcom.com>
Date: Mon, 15 May 2017 10:34:53 +0530
Subject: async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
From: Anup Patel <anup.patel(a)broadcom.com>
[ Upstream commit baae03a0e2497f49704628fd0aaf993cf98e1b99 ]
The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output
of Tx descriptor is to be used by next/dependent Tx descriptor.
The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome()
when calling dma->device_prep_dma_pq() under following conditions:
1. ASYNC_TX_FENCE not set in submit->flags
2. DMA_PREP_FENCE not set in dma_flags
3. src_cnt (= (disks - 2)) is greater than dma_maxpq(dma, dma_flags)
This patch fixes DMA_PREP_FENCE usage in do_async_gen_syndrome() taking
inspiration from do_async_xor() implementation.
Signed-off-by: Anup Patel <anup.patel(a)broadcom.com>
Reviewed-by: Ray Jui <ray.jui(a)broadcom.com>
Reviewed-by: Scott Branden <scott.branden(a)broadcom.com>
Acked-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/async_tx/async_pq.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -62,9 +62,6 @@ do_async_gen_syndrome(struct dma_chan *c
dma_addr_t dma_dest[2];
int src_off = 0;
- if (submit->flags & ASYNC_TX_FENCE)
- dma_flags |= DMA_PREP_FENCE;
-
while (src_cnt > 0) {
submit->flags = flags_orig;
pq_src_cnt = min(src_cnt, dma_maxpq(dma, dma_flags));
@@ -83,6 +80,8 @@ do_async_gen_syndrome(struct dma_chan *c
if (cb_fn_orig)
dma_flags |= DMA_PREP_INTERRUPT;
}
+ if (submit->flags & ASYNC_TX_FENCE)
+ dma_flags |= DMA_PREP_FENCE;
/* Drivers force forward progress in case they can not provide
* a descriptor
Patches currently in stable-queue which might be from anup.patel(a)broadcom.com are
queue-4.4/async_tx-fix-dma_prep_fence-usage-in-do_async_gen_syndrome.patch
This is a note to let you know that I've just added the patch titled
ASoC: rsnd: SSI PIO adjust to 24bit mode
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-rsnd-ssi-pio-adjust-to-24bit-mode.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Date: Wed, 24 May 2017 01:17:10 +0000
Subject: ASoC: rsnd: SSI PIO adjust to 24bit mode
From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
[ Upstream commit 7819a942de7b993771bd9377babc80485fe7606b ]
commit 90431eb49bff ("ASoC: rsnd: don't use PDTA bit for 24bit on SSI")
fixups 24bit mode data alignment, but PIO was not cared.
This patch fixes PIO mode 24bit data alignment
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.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/sh/rcar/ssi.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -453,6 +453,13 @@ static void __rsnd_ssi_interrupt(struct
struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
u32 *buf = (u32 *)(runtime->dma_area +
rsnd_dai_pointer_offset(io, 0));
+ int shift = 0;
+
+ switch (runtime->sample_bits) {
+ case 32:
+ shift = 8;
+ break;
+ }
/*
* 8/16/32 data can be assesse to TDR/RDR register
@@ -460,9 +467,9 @@ static void __rsnd_ssi_interrupt(struct
* see rsnd_ssi_init()
*/
if (rsnd_io_is_play(io))
- rsnd_mod_write(mod, SSITDR, *buf);
+ rsnd_mod_write(mod, SSITDR, (*buf) << shift);
else
- *buf = rsnd_mod_read(mod, SSIRDR);
+ *buf = (rsnd_mod_read(mod, SSIRDR) >> shift);
elapsed = rsnd_dai_pointer_update(io, sizeof(*buf));
}
Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are
queue-4.4/asoc-rsnd-ssi-pio-adjust-to-24bit-mode.patch
This is a note to let you know that I've just added the patch titled
ASoC: Intel: sst: Fix the return value of 'sst_send_byte_stream_mrfld()'
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-intel-sst-fix-the-return-value-of-sst_send_byte_stream_mrfld.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Sat, 6 Jan 2018 21:18:24 +0100
Subject: ASoC: Intel: sst: Fix the return value of 'sst_send_byte_stream_mrfld()'
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit eaadb1caa966a91128297b754e90b7c92b350a00 ]
In some error handling paths, an error code is assiegned to 'ret'.
However, the function always return 0.
Fix it and return the error code if such an error paths is taken.
Fixes: 3d9ff34622ba ("ASoC: Intel: sst: add stream operations")
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
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_stream.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/soc/intel/atom/sst/sst_stream.c
+++ b/sound/soc/intel/atom/sst/sst_stream.c
@@ -221,7 +221,7 @@ int sst_send_byte_stream_mrfld(struct in
sst_free_block(sst_drv_ctx, block);
out:
test_and_clear_bit(pvt_id, &sst_drv_ctx->pvt_id);
- return 0;
+ return ret;
}
/*
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.4/cpuidle-dt-add-missing-of_node_put.patch
queue-4.4/edac-mv64x60-fix-an-error-handling-path.patch
queue-4.4/smb2-fix-share-type-handling.patch
queue-4.4/asoc-intel-sst-fix-the-return-value-of-sst_send_byte_stream_mrfld.patch
This is a note to let you know that I've just added the patch titled
ASoC: Intel: cht_bsw_rt5645: Analog Mic support
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
asoc-intel-cht_bsw_rt5645-analog-mic-support.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Tue, 2 Jan 2018 19:53:14 +0100
Subject: ASoC: Intel: cht_bsw_rt5645: Analog Mic support
From: Hans de Goede <hdegoede(a)redhat.com>
[ Upstream commit b70b309950418437bbd2a30afd169c4f09dee3e5 ]
Various Cherry Trail boards with a rt5645 codec have an analog mic
connected to IN2P + IN2N. The mic on this boards also needs micbias to
be enabled, on some boards micbias1 is used and on others micbias2, so
we enable both.
This commit adds a new "Int Analog Mic" DAPM widget for this, so that we
do not end up enabling micbias on boards with a digital mic which uses
the already present "Int Mic" widget. Some existing UCM files already
refer to "Int Mic" for their "Internal Analog Microphones" SectionDevice,
but these don't work anyways since they enable the RECMIX BST1 Switch
instead of the BST2 switch.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.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/boards/cht_bsw_rt5645.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/sound/soc/intel/boards/cht_bsw_rt5645.c
+++ b/sound/soc/intel/boards/cht_bsw_rt5645.c
@@ -96,6 +96,7 @@ static const struct snd_soc_dapm_widget
SND_SOC_DAPM_HP("Headphone", NULL),
SND_SOC_DAPM_MIC("Headset Mic", NULL),
SND_SOC_DAPM_MIC("Int Mic", NULL),
+ SND_SOC_DAPM_MIC("Int Analog Mic", NULL),
SND_SOC_DAPM_SPK("Ext Spk", NULL),
SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0,
platform_clock_control, SND_SOC_DAPM_POST_PMD),
@@ -106,6 +107,8 @@ static const struct snd_soc_dapm_route c
{"IN1N", NULL, "Headset Mic"},
{"DMIC L1", NULL, "Int Mic"},
{"DMIC R1", NULL, "Int Mic"},
+ {"IN2P", NULL, "Int Analog Mic"},
+ {"IN2N", NULL, "Int Analog Mic"},
{"Headphone", NULL, "HPOL"},
{"Headphone", NULL, "HPOR"},
{"Ext Spk", NULL, "SPOL"},
@@ -119,6 +122,9 @@ static const struct snd_soc_dapm_route c
{"Headphone", NULL, "Platform Clock"},
{"Headset Mic", NULL, "Platform Clock"},
{"Int Mic", NULL, "Platform Clock"},
+ {"Int Analog Mic", NULL, "Platform Clock"},
+ {"Int Analog Mic", NULL, "micbias1"},
+ {"Int Analog Mic", NULL, "micbias2"},
{"Ext Spk", NULL, "Platform Clock"},
};
@@ -147,6 +153,7 @@ static const struct snd_kcontrol_new cht
SOC_DAPM_PIN_SWITCH("Headphone"),
SOC_DAPM_PIN_SWITCH("Headset Mic"),
SOC_DAPM_PIN_SWITCH("Int Mic"),
+ SOC_DAPM_PIN_SWITCH("Int Analog Mic"),
SOC_DAPM_PIN_SWITCH("Ext Spk"),
};
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.4/ata-libahci-properly-propagate-return-value-of-platform_get_irq.patch
queue-4.4/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch
This is a note to let you know that I've just added the patch titled
arp: honour gratuitous ARP _replies_
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arp-honour-gratuitous-arp-_replies_.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Ihar Hrachyshka <ihrachys(a)redhat.com>
Date: Tue, 16 May 2017 07:53:43 -0700
Subject: arp: honour gratuitous ARP _replies_
From: Ihar Hrachyshka <ihrachys(a)redhat.com>
[ Upstream commit 23d268eb240954e6e78f7cfab04f2b1e79f84489 ]
When arp_accept is 1, gratuitous ARPs are supposed to override matching
entries irrespective of whether they arrive during locktime. This was
implemented in commit 56022a8fdd87 ("ipv4: arp: update neighbour address
when a gratuitous arp is received and arp_accept is set")
There is a glitch in the patch though. RFC 2002, section 4.6, "ARP,
Proxy ARP, and Gratuitous ARP", defines gratuitous ARPs so that they can
be either of Request or Reply type. Those Reply gratuitous ARPs can be
triggered with standard tooling, for example, arping -A option does just
that.
This patch fixes the glitch, making both Request and Reply flavours of
gratuitous ARPs to behave identically.
As per RFC, if gratuitous ARPs are of Reply type, their Target Hardware
Address field should also be set to the link-layer address to which this
cache entry should be updated. The field is present in ARP over Ethernet
but not in IEEE 1394. In this patch, I don't consider any broadcasted
ARP replies as gratuitous if the field is not present, to conform the
standard. It's not clear whether there is such a thing for IEEE 1394 as
a gratuitous ARP reply; until it's cleared up, we will ignore such
broadcasts. Note that they will still update existing ARP cache entries,
assuming they arrive out of locktime time interval.
Signed-off-by: Ihar Hrachyshka <ihrachys(a)redhat.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>
---
net/ipv4/arp.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -658,6 +658,7 @@ static int arp_process(struct net *net,
unsigned char *arp_ptr;
struct rtable *rt;
unsigned char *sha;
+ unsigned char *tha = NULL;
__be32 sip, tip;
u16 dev_type = dev->type;
int addr_type;
@@ -729,6 +730,7 @@ static int arp_process(struct net *net,
break;
#endif
default:
+ tha = arp_ptr;
arp_ptr += dev->addr_len;
}
memcpy(&tip, arp_ptr, 4);
@@ -839,8 +841,18 @@ static int arp_process(struct net *net,
It is possible, that this option should be enabled for some
devices (strip is candidate)
*/
- is_garp = arp->ar_op == htons(ARPOP_REQUEST) && tip == sip &&
- addr_type == RTN_UNICAST;
+ is_garp = tip == sip && addr_type == RTN_UNICAST;
+
+ /* Unsolicited ARP _replies_ also require target hwaddr to be
+ * the same as source.
+ */
+ if (is_garp && arp->ar_op == htons(ARPOP_REPLY))
+ is_garp =
+ /* IPv4 over IEEE 1394 doesn't provide target
+ * hardware address field in its ARP payload.
+ */
+ tha &&
+ !memcmp(tha, sha, dev->addr_len);
if (!n &&
((arp->ar_op == htons(ARPOP_REPLY) &&
Patches currently in stable-queue which might be from ihrachys(a)redhat.com are
queue-4.4/arp-honour-gratuitous-arp-_replies_.patch
queue-4.4/neighbour-update-neigh-timestamps-iff-update-is-effective.patch
This is a note to let you know that I've just added the patch titled
arm64: futex: Fix undefined behaviour with FUTEX_OP_OPARG_SHIFT usage
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-futex-fix-undefined-behaviour-with-futex_op_oparg_shift-usage.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Will Deacon <will.deacon(a)arm.com>
Date: Wed, 5 Apr 2017 11:14:05 +0100
Subject: arm64: futex: Fix undefined behaviour with FUTEX_OP_OPARG_SHIFT usage
From: Will Deacon <will.deacon(a)arm.com>
[ Upstream commit 5f16a046f8e144c294ef98cd29d9458b5f8273e5 ]
FUTEX_OP_OPARG_SHIFT instructs the futex code to treat the 12-bit oparg
field as a shift value, potentially leading to a left shift value that
is negative or with an absolute value that is significantly larger then
the size of the type. UBSAN chokes with:
================================================================================
UBSAN: Undefined behaviour in ./arch/arm64/include/asm/futex.h:60:13
shift exponent -1 is negative
CPU: 1 PID: 1449 Comm: syz-executor0 Not tainted 4.11.0-rc4-00005-g977eb52-dirty #11
Hardware name: linux,dummy-virt (DT)
Call trace:
[<ffff200008094778>] dump_backtrace+0x0/0x538 arch/arm64/kernel/traps.c:73
[<ffff200008094cd0>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228
[<ffff200008c194a8>] __dump_stack lib/dump_stack.c:16 [inline]
[<ffff200008c194a8>] dump_stack+0x120/0x188 lib/dump_stack.c:52
[<ffff200008cc24b8>] ubsan_epilogue+0x18/0x98 lib/ubsan.c:164
[<ffff200008cc3098>] __ubsan_handle_shift_out_of_bounds+0x250/0x294 lib/ubsan.c:421
[<ffff20000832002c>] futex_atomic_op_inuser arch/arm64/include/asm/futex.h:60 [inline]
[<ffff20000832002c>] futex_wake_op kernel/futex.c:1489 [inline]
[<ffff20000832002c>] do_futex+0x137c/0x1740 kernel/futex.c:3231
[<ffff200008320504>] SYSC_futex kernel/futex.c:3281 [inline]
[<ffff200008320504>] SyS_futex+0x114/0x268 kernel/futex.c:3249
[<ffff200008084770>] el0_svc_naked+0x24/0x28
================================================================================
syz-executor1 uses obsolete (PF_INET,SOCK_PACKET)
sock: process `syz-executor0' is using obsolete setsockopt SO_BSDCOMPAT
This patch attempts to fix some of this by:
* Making encoded_op an unsigned type, so we can shift it left even if
the top bit is set.
* Casting to signed prior to shifting right when extracting oparg
and cmparg
* Consider only the bottom 5 bits of oparg when using it as a left-shift
value.
Whilst I think this catches all of the issues, I'd much prefer to remove
this stuff, as I think it's unused and the bugs are copy-pasted between
a bunch of architectures.
Reviewed-by: Robin Murphy <robin.murphy(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/futex.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/arch/arm64/include/asm/futex.h
+++ b/arch/arm64/include/asm/futex.h
@@ -53,16 +53,16 @@
: "memory")
static inline int
-futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr)
+futex_atomic_op_inuser(unsigned int encoded_op, u32 __user *uaddr)
{
int op = (encoded_op >> 28) & 7;
int cmp = (encoded_op >> 24) & 15;
- int oparg = (encoded_op << 8) >> 20;
- int cmparg = (encoded_op << 20) >> 20;
+ int oparg = (int)(encoded_op << 8) >> 20;
+ int cmparg = (int)(encoded_op << 20) >> 20;
int oldval = 0, ret, tmp;
if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
- oparg = 1 << oparg;
+ oparg = 1U << (oparg & 0x1f);
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;
Patches currently in stable-queue which might be from will.deacon(a)arm.com are
queue-4.4/arm64-futex-fix-undefined-behaviour-with-futex_op_oparg_shift-usage.patch
This is a note to let you know that I've just added the patch titled
ARM: imx: Add MXC_CPU_IMX6ULL and cpu_is_imx6ull
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-imx-add-mxc_cpu_imx6ull-and-cpu_is_imx6ull.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Leonard Crestez <leonard.crestez(a)nxp.com>
Date: Tue, 6 Jun 2017 20:50:42 +0300
Subject: ARM: imx: Add MXC_CPU_IMX6ULL and cpu_is_imx6ull
From: Leonard Crestez <leonard.crestez(a)nxp.com>
[ Upstream commit b3ea575770c7eeb259c77b6861cd14d00eb309df ]
Support for imx6ull is already present but it's based on
of_machine_is_compatible("fsl,imx6ull") checks. Add it to the MXC_CPU_*
enumeration as well.
This also fixes /sys/devices/soc0/soc_id reading "Unknown".
Signed-off-by: Leonard Crestez <leonard.crestez(a)nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Shawn Guo <shawnguo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-imx/cpu.c | 3 +++
arch/arm/mach-imx/mxc.h | 6 ++++++
2 files changed, 9 insertions(+)
--- a/arch/arm/mach-imx/cpu.c
+++ b/arch/arm/mach-imx/cpu.c
@@ -133,6 +133,9 @@ struct device * __init imx_soc_device_in
case MXC_CPU_IMX6UL:
soc_id = "i.MX6UL";
break;
+ case MXC_CPU_IMX6ULL:
+ soc_id = "i.MX6ULL";
+ break;
case MXC_CPU_IMX7D:
soc_id = "i.MX7D";
break;
--- a/arch/arm/mach-imx/mxc.h
+++ b/arch/arm/mach-imx/mxc.h
@@ -39,6 +39,7 @@
#define MXC_CPU_IMX6SX 0x62
#define MXC_CPU_IMX6Q 0x63
#define MXC_CPU_IMX6UL 0x64
+#define MXC_CPU_IMX6ULL 0x65
#define MXC_CPU_IMX7D 0x72
#define IMX_DDR_TYPE_LPDDR2 1
@@ -171,6 +172,11 @@ static inline bool cpu_is_imx6ul(void)
return __mxc_cpu_type == MXC_CPU_IMX6UL;
}
+static inline bool cpu_is_imx6ull(void)
+{
+ return __mxc_cpu_type == MXC_CPU_IMX6ULL;
+}
+
static inline bool cpu_is_imx6q(void)
{
return __mxc_cpu_type == MXC_CPU_IMX6Q;
Patches currently in stable-queue which might be from leonard.crestez(a)nxp.com are
queue-4.4/arm-imx-add-mxc_cpu_imx6ull-and-cpu_is_imx6ull.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: ls1021a: add "fsl,ls1021a-esdhc" compatible string to esdhc node
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-ls1021a-add-fsl-ls1021a-esdhc-compatible-string-to-esdhc-node.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
Date: Thu, 16 Nov 2017 13:15:26 +0100
Subject: ARM: dts: ls1021a: add "fsl,ls1021a-esdhc" compatible string to esdhc node
From: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
[ Upstream commit d5c7b4d5ac2237a6da7ced3adfe6b8bf769f8cc6 ]
Commit a22950c888e3 (mmc: sdhci-of-esdhc: add quirk
SDHCI_QUIRK_BROKEN_TIMEOUT_VAL for ls1021a) added logic to the driver to
enable the broken timeout val quirk for ls1021a, but did not add the
corresponding compatible string to the device tree, so it didn't really
have any effect. Fix that.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
Signed-off-by: Shawn Guo <shawnguo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/ls1021a.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -132,7 +132,7 @@
};
esdhc: esdhc@1560000 {
- compatible = "fsl,esdhc";
+ compatible = "fsl,ls1021a-esdhc", "fsl,esdhc";
reg = <0x0 0x1560000 0x0 0x10000>;
interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <0>;
Patches currently in stable-queue which might be from rasmus.villemoes(a)prevas.dk are
queue-4.4/arm-dts-ls1021a-add-fsl-ls1021a-esdhc-compatible-string-to-esdhc-node.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: imx6qdl-wandboard: Fix audio channel swap
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-imx6qdl-wandboard-fix-audio-channel-swap.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Fabio Estevam <fabio.estevam(a)nxp.com>
Date: Sun, 14 May 2017 11:50:50 -0300
Subject: ARM: dts: imx6qdl-wandboard: Fix audio channel swap
From: Fabio Estevam <fabio.estevam(a)nxp.com>
[ Upstream commit 79935915300c5eb88a0e94fa9148a7505c14a02a ]
When running a stress playback/stop loop test on a mx6wandboard channel
swaps can be noticed randomly.
Increasing the SGTL5000 LRCLK pad strength to its maximum value fixes
the issue, so add the 'lrclk-strength' property to avoid the audio
channel swaps.
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Shawn Guo <shawnguo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -88,6 +88,7 @@
clocks = <&clks 201>;
VDDA-supply = <®_2p5v>;
VDDIO-supply = <®_3p3v>;
+ lrclk-strength = <3>;
};
};
Patches currently in stable-queue which might be from fabio.estevam(a)nxp.com are
queue-4.4/arm-dts-imx6qdl-wandboard-fix-audio-channel-swap.patch
queue-4.4/arm-dts-imx53-qsrb-pulldown-pmic-irq-pin.patch
queue-4.4/arm-imx-add-mxc_cpu_imx6ull-and-cpu_is_imx6ull.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: imx53-qsrb: Pulldown PMIC IRQ pin
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-imx53-qsrb-pulldown-pmic-irq-pin.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Fabio Estevam <fabio.estevam(a)nxp.com>
Date: Wed, 12 Apr 2017 18:31:18 -0300
Subject: ARM: dts: imx53-qsrb: Pulldown PMIC IRQ pin
From: Fabio Estevam <fabio.estevam(a)nxp.com>
[ Upstream commit 2fe4bff3516924a37e083e3211364abe59db1161 ]
Currently the following errors are seen:
[ 14.015056] mc13xxx 0-0008: Failed to read IRQ status: -6
[ 27.321093] mc13xxx 0-0008: Failed to read IRQ status: -6
[ 27.411681] mc13xxx 0-0008: Failed to read IRQ status: -6
[ 27.456281] mc13xxx 0-0008: Failed to read IRQ status: -6
[ 30.527106] mc13xxx 0-0008: Failed to read IRQ status: -6
[ 36.596900] mc13xxx 0-0008: Failed to read IRQ status: -6
Also when reading the interrupts via 'cat /proc/interrupts' the
PMIC GPIO interrupt counter does not stop increasing.
The reason for the storm of interrupts is that the PUS field of
register IOMUXC_SW_PAD_CTL_PAD_CSI0_DAT5 is currently configured as:
10 : 100k pullup
and the PMIC interrupt is being registered as IRQ_TYPE_LEVEL_HIGH type,
which is the correct type as per the MC34708 datasheet.
Use the default power on value for the IOMUX, which sets PUS field as:
00: 360k pull down
This prevents the spurious PMIC interrupts from happening.
Commit e1ffceb078c6 ("ARM: imx53: qsrb: fix PMIC interrupt level")
correctly described the irq type as IRQ_TYPE_LEVEL_HIGH, but
missed to update the IOMUX of the PMIC GPIO as pull down.
Fixes: e1ffceb078c6 ("ARM: imx53: qsrb: fix PMIC interrupt level")
Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Shawn Guo <shawnguo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/imx53-qsrb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/imx53-qsrb.dts
+++ b/arch/arm/boot/dts/imx53-qsrb.dts
@@ -23,7 +23,7 @@
imx53-qsrb {
pinctrl_pmic: pmicgrp {
fsl,pins = <
- MX53_PAD_CSI0_DAT5__GPIO5_23 0x1e4 /* IRQ */
+ MX53_PAD_CSI0_DAT5__GPIO5_23 0x1c4 /* IRQ */
>;
};
};
Patches currently in stable-queue which might be from fabio.estevam(a)nxp.com are
queue-4.4/arm-dts-imx6qdl-wandboard-fix-audio-channel-swap.patch
queue-4.4/arm-dts-imx53-qsrb-pulldown-pmic-irq-pin.patch
queue-4.4/arm-imx-add-mxc_cpu_imx6ull-and-cpu_is_imx6ull.patch
This is a note to let you know that I've just added the patch titled
ARM: davinci: da8xx: Create DSP device only when assigned memory
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-davinci-da8xx-create-dsp-device-only-when-assigned-memory.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Suman Anna <s-anna(a)ti.com>
Date: Tue, 16 May 2017 17:13:45 -0500
Subject: ARM: davinci: da8xx: Create DSP device only when assigned memory
From: Suman Anna <s-anna(a)ti.com>
[ Upstream commit f97f03578b997a8ec2b9bc4928f958a865137268 ]
The DSP device on Davinci platforms does not have an MMU and requires
specific DDR memory to boot. This memory is reserved using the rproc_mem
kernel boot parameter and is assigned to the device on non-DT boots.
The remoteproc core uses the DMA API and so will fall back to assigning
random memory if this memory is not assigned to the device, but the DSP
remote processor boot will not be successful in such cases. So, check
that memory has been reserved and assigned to the device specifically
before even creating the DSP device.
Signed-off-by: Suman Anna <s-anna(a)ti.com>
Signed-off-by: Sekhar Nori <nsekhar(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-davinci/devices-da8xx.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -795,6 +795,8 @@ static struct platform_device da8xx_dsp
.resource = da8xx_rproc_resources,
};
+static bool rproc_mem_inited __initdata;
+
#if IS_ENABLED(CONFIG_DA8XX_REMOTEPROC)
static phys_addr_t rproc_base __initdata;
@@ -833,6 +835,8 @@ void __init da8xx_rproc_reserve_cma(void
ret = dma_declare_contiguous(&da8xx_dsp.dev, rproc_size, rproc_base, 0);
if (ret)
pr_err("%s: dma_declare_contiguous failed %d\n", __func__, ret);
+ else
+ rproc_mem_inited = true;
}
#else
@@ -847,6 +851,12 @@ int __init da8xx_register_rproc(void)
{
int ret;
+ if (!rproc_mem_inited) {
+ pr_warn("%s: memory not reserved for DSP, not registering DSP device\n",
+ __func__);
+ return -ENOMEM;
+ }
+
ret = platform_device_register(&da8xx_dsp);
if (ret)
pr_err("%s: can't register DSP device: %d\n", __func__, ret);
Patches currently in stable-queue which might be from s-anna(a)ti.com are
queue-4.4/arm-davinci-da8xx-create-dsp-device-only-when-assigned-memory.patch
This is a note to let you know that I've just added the patch titled
af_key: Fix slab-out-of-bounds in pfkey_compile_policy.
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
af_key-fix-slab-out-of-bounds-in-pfkey_compile_policy.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Steffen Klassert <steffen.klassert(a)secunet.com>
Date: Fri, 5 May 2017 07:40:42 +0200
Subject: af_key: Fix slab-out-of-bounds in pfkey_compile_policy.
From: Steffen Klassert <steffen.klassert(a)secunet.com>
[ Upstream commit d90c902449a7561f1b1d58ba5a0d11728ce8b0b2 ]
The sadb_x_sec_len is stored in the unit 'byte divided by eight'.
So we have to multiply this value by eight before we can do
size checks. Otherwise we may get a slab-out-of-bounds when
we memcpy the user sec_ctx.
Fixes: df71837d502 ("[LSM-IPSec]: Security association restriction.")
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/key/af_key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3305,7 +3305,7 @@ static struct xfrm_policy *pfkey_compile
p += pol->sadb_x_policy_len*8;
sec_ctx = (struct sadb_x_sec_ctx *)p;
if (len < pol->sadb_x_policy_len*8 +
- sec_ctx->sadb_x_sec_len) {
+ sec_ctx->sadb_x_sec_len*8) {
*dir = -EINVAL;
goto out;
}
Patches currently in stable-queue which might be from steffen.klassert(a)secunet.com are
queue-4.4/ipsec-check-return-value-of-skb_to_sgvec-always.patch
queue-4.4/skbuff-return-emsgsize-in-skb_to_sgvec-to-prevent-overflow.patch
queue-4.4/xfrm-fix-state-migration-copy-replay-sequence-numbers.patch
queue-4.4/af_key-fix-slab-out-of-bounds-in-pfkey_compile_policy.patch
This is a note to let you know that I've just added the patch titled
ACPICA: Events: Add runtime stub support for event APIs
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
acpica-events-add-runtime-stub-support-for-event-apis.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Lv Zheng <lv.zheng(a)intel.com>
Date: Mon, 5 Jun 2017 16:40:02 +0800
Subject: ACPICA: Events: Add runtime stub support for event APIs
From: Lv Zheng <lv.zheng(a)intel.com>
[ Upstream commit 861ba6351c520328e94a78c923b415faa9116287 ]
ACPICA commit 99bc3beca92c6574ea1d69de42e54f872e6373ce
It is reported that on Linux, RTC driver complains wrong errors on
hardware reduced platform:
[ 4.085420] ACPI Warning: Could not enable fixed event - real_time_clock (4) (20160422/evxface-654)
This patch fixes this by correctly adding runtime reduced hardware check.
Reported by Chandan Tagore, fixed by Lv Zheng.
Link: https://github.com/acpica/acpica/commit/99bc3bec
Tested-by: Chandan Tagore <tagore.chandan(a)gmail.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>
---
drivers/acpi/acpica/evxfevnt.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
--- a/drivers/acpi/acpica/evxfevnt.c
+++ b/drivers/acpi/acpica/evxfevnt.c
@@ -180,6 +180,12 @@ acpi_status acpi_enable_event(u32 event,
ACPI_FUNCTION_TRACE(acpi_enable_event);
+ /* If Hardware Reduced flag is set, there are no fixed events */
+
+ if (acpi_gbl_reduced_hardware) {
+ return_ACPI_STATUS(AE_OK);
+ }
+
/* Decode the Fixed Event */
if (event > ACPI_EVENT_MAX) {
@@ -237,6 +243,12 @@ acpi_status acpi_disable_event(u32 event
ACPI_FUNCTION_TRACE(acpi_disable_event);
+ /* If Hardware Reduced flag is set, there are no fixed events */
+
+ if (acpi_gbl_reduced_hardware) {
+ return_ACPI_STATUS(AE_OK);
+ }
+
/* Decode the Fixed Event */
if (event > ACPI_EVENT_MAX) {
@@ -290,6 +302,12 @@ acpi_status acpi_clear_event(u32 event)
ACPI_FUNCTION_TRACE(acpi_clear_event);
+ /* If Hardware Reduced flag is set, there are no fixed events */
+
+ if (acpi_gbl_reduced_hardware) {
+ return_ACPI_STATUS(AE_OK);
+ }
+
/* Decode the Fixed Event */
if (event > ACPI_EVENT_MAX) {
Patches currently in stable-queue which might be from lv.zheng(a)intel.com are
queue-4.4/acpica-disassembler-abort-on-an-invalid-unknown-aml-opcode.patch
queue-4.4/acpica-events-add-runtime-stub-support-for-event-apis.patch
This is a note to let you know that I've just added the patch titled
ACPICA: Disassembler: Abort on an invalid/unknown AML opcode
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
acpica-disassembler-abort-on-an-invalid-unknown-aml-opcode.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: Bob Moore <robert.moore(a)intel.com>
Date: Mon, 5 Jun 2017 16:40:34 +0800
Subject: ACPICA: Disassembler: Abort on an invalid/unknown AML opcode
From: Bob Moore <robert.moore(a)intel.com>
[ Upstream commit 6f0527b77d9e0129dd8e50945b0d610ed943d6b2 ]
ACPICA commit ed0389cb11a61e63c568ac1f67948fc6a7bd1aeb
An invalid opcode indicates something seriously wrong with the
input AML file. The AML parser is immediately confused and lost,
causing the resulting parse tree to be ill-formed. The actual
disassembly can then cause numerous unrelated errors and faults.
This change aborts the disassembly upon discovery of such an
opcode during the AML parse phase.
Link: https://github.com/acpica/acpica/commit/ed0389cb
Signed-off-by: Bob Moore <robert.moore(a)intel.com>
Signed-off-by: Lv Zheng <lv.zheng(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>
---
drivers/acpi/acpica/psobject.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/drivers/acpi/acpica/psobject.c
+++ b/drivers/acpi/acpica/psobject.c
@@ -121,6 +121,9 @@ static acpi_status acpi_ps_get_aml_opcod
(u32)(aml_offset +
sizeof(struct acpi_table_header)));
+ ACPI_ERROR((AE_INFO,
+ "Aborting disassembly, AML byte code is corrupt"));
+
/* Dump the context surrounding the invalid opcode */
acpi_ut_dump_buffer(((u8 *)walk_state->parser_state.
@@ -129,6 +132,14 @@ static acpi_status acpi_ps_get_aml_opcod
sizeof(struct acpi_table_header) -
16));
acpi_os_printf(" */\n");
+
+ /*
+ * Just abort the disassembly, cannot continue because the
+ * parser is essentially lost. The disassembler can then
+ * randomly fail because an ill-constructed parse tree
+ * can result.
+ */
+ return_ACPI_STATUS(AE_AML_BAD_OPCODE);
#endif
}
@@ -293,6 +304,9 @@ acpi_ps_create_op(struct acpi_walk_state
if (status == AE_CTRL_PARSE_CONTINUE) {
return_ACPI_STATUS(AE_CTRL_PARSE_CONTINUE);
}
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
/* Create Op structure and append to parent's argument list */
Patches currently in stable-queue which might be from robert.moore(a)intel.com are
queue-4.4/acpica-disassembler-abort-on-an-invalid-unknown-aml-opcode.patch
queue-4.4/acpica-events-add-runtime-stub-support-for-event-apis.patch
I'm announcing the release of the 3.18.104 kernel.
Only users who had build errors in 3.18.103 need to upgrade, this is a
single-bugfix-only release.
The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2 +-
drivers/net/ethernet/freescale/fec_main.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
Greg Kroah-Hartman (2):
net: fec: fix build error in fec driver
Linux 3.18.104