This is a note to let you know that I've just added the patch titled
dmaengine: jz4740: disable/unprepare clk if probe fails
to the 4.14-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:
dmaengine-jz4740-disable-unprepare-clk-if-probe-fails.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
Date: Wed, 6 Dec 2017 14:28:27 +0100
Subject: dmaengine: jz4740: disable/unprepare clk if probe fails
From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
[ Upstream commit eb9436966fdc84cebdf222952a99898ab46d9bb0 ]
in error path of jz4740_dma_probe(), call clk_disable_unprepare() to clean
up.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 25ce6c35fea0 MIPS: jz4740: Remove custom DMA API
Signed-off-by: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/dma-jz4740.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/dma/dma-jz4740.c
+++ b/drivers/dma/dma-jz4740.c
@@ -555,7 +555,7 @@ static int jz4740_dma_probe(struct platf
ret = dma_async_device_register(dd);
if (ret)
- return ret;
+ goto err_clk;
irq = platform_get_irq(pdev, 0);
ret = request_irq(irq, jz4740_dma_irq, 0, dev_name(&pdev->dev), dmadev);
@@ -568,6 +568,8 @@ static int jz4740_dma_probe(struct platf
err_unregister:
dma_async_device_unregister(dd);
+err_clk:
+ clk_disable_unprepare(dmadev->clk);
return ret;
}
Patches currently in stable-queue which might be from Tobias.Jordan(a)elektrobit.com are
queue-4.14/dmaengine-jz4740-disable-unprepare-clk-if-probe-fails.patch
This is a note to let you know that I've just added the patch titled
dmaengine: ioat: Fix error handling path
to the 4.14-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:
dmaengine-ioat-fix-error-handling-path.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Fri, 17 Nov 2017 22:37:53 +0100
Subject: dmaengine: ioat: Fix error handling path
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 5c9afbda911ce20b3f2181d1e440a0222e1027dd ]
If the last test in 'ioat_dma_self_test()' fails, we must release all
the allocated resources and not just part of them.
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Acked-by: Dave Jiang <dave.jiang(a)intel.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/ioat/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/dma/ioat/init.c
+++ b/drivers/dma/ioat/init.c
@@ -390,7 +390,7 @@ static int ioat_dma_self_test(struct ioa
if (memcmp(src, dest, IOAT_TEST_SIZE)) {
dev_err(dev, "Self-test copy failed compare, disabling\n");
err = -ENODEV;
- goto free_resources;
+ goto unmap_dma;
}
unmap_dma:
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/dmaengine-ioat-fix-error-handling-path.patch
This is a note to let you know that I've just added the patch titled
dmaengine: at_hdmac: fix potential NULL pointer dereference in atc_prep_dma_interleaved
to the 4.14-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:
dmaengine-at_hdmac-fix-potential-null-pointer-dereference-in-atc_prep_dma_interleaved.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
Date: Mon, 20 Nov 2017 08:28:14 -0600
Subject: dmaengine: at_hdmac: fix potential NULL pointer dereference in atc_prep_dma_interleaved
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
[ Upstream commit 62a277d43d47e74972de44d33bd3763e31992414 ]
_xt_ is being dereferenced before it is null checked, hence there is a
potential null pointer dereference.
Fix this by moving the pointer dereference after _xt_ has been null
checked.
This issue was detected with the help of Coccinelle.
Fixes: 4483320e241c ("dmaengine: Use Pointer xt after NULL check.")
Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com>
Acked-by: Ludovic Desroches <ludovic.desroches(a)microchip.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/at_hdmac.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -708,7 +708,7 @@ atc_prep_dma_interleaved(struct dma_chan
unsigned long flags)
{
struct at_dma_chan *atchan = to_at_dma_chan(chan);
- struct data_chunk *first = xt->sgl;
+ struct data_chunk *first;
struct at_desc *desc = NULL;
size_t xfer_count;
unsigned int dwidth;
@@ -720,6 +720,8 @@ atc_prep_dma_interleaved(struct dma_chan
if (unlikely(!xt || xt->numf != 1 || !xt->frame_size))
return NULL;
+ first = xt->sgl;
+
dev_info(chan2dev(chan),
"%s: src=%pad, dest=%pad, numf=%d, frame_size=%d, flags=0x%lx\n",
__func__, &xt->src_start, &xt->dst_start, xt->numf,
Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are
queue-4.14/dmaengine-at_hdmac-fix-potential-null-pointer-dereference-in-atc_prep_dma_interleaved.patch
This is a note to let you know that I've just added the patch titled
clk: fix a panic error caused by accessing NULL pointer
to the 4.14-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:
clk-fix-a-panic-error-caused-by-accessing-null-pointer.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Cai Li <cai.li(a)spreadtrum.com>
Date: Tue, 21 Nov 2017 17:24:38 +0800
Subject: clk: fix a panic error caused by accessing NULL pointer
From: Cai Li <cai.li(a)spreadtrum.com>
[ Upstream commit 975b820b6836b6b6c42fb84cd2e772e2b41bca67 ]
In some cases the clock parent would be set NULL when doing re-parent,
it will cause a NULL pointer accessing if clk_set trace event is
enabled.
This patch sets the parent as "none" if the input parameter is NULL.
Fixes: dfc202ead312 (clk: Add tracepoints for hardware operations)
Signed-off-by: Cai Li <cai.li(a)spreadtrum.com>
Signed-off-by: Chunyan Zhang <chunyan.zhang(a)spreadtrum.com>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/trace/events/clk.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/trace/events/clk.h
+++ b/include/trace/events/clk.h
@@ -134,12 +134,12 @@ DECLARE_EVENT_CLASS(clk_parent,
TP_STRUCT__entry(
__string( name, core->name )
- __string( pname, parent->name )
+ __string( pname, parent ? parent->name : "none" )
),
TP_fast_assign(
__assign_str(name, core->name);
- __assign_str(pname, parent->name);
+ __assign_str(pname, parent ? parent->name : "none");
),
TP_printk("%s %s", __get_str(name), __get_str(pname))
Patches currently in stable-queue which might be from cai.li(a)spreadtrum.com are
queue-4.14/clk-fix-a-panic-error-caused-by-accessing-null-pointer.patch
This is a note to let you know that I've just added the patch titled
btrfs: Fix quota reservation leak on preallocated files
to the 4.14-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-quota-reservation-leak-on-preallocated-files.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Justin Maggard <jmaggard10(a)gmail.com>
Date: Mon, 30 Oct 2017 15:29:10 -0700
Subject: btrfs: Fix quota reservation leak on preallocated files
From: Justin Maggard <jmaggard10(a)gmail.com>
[ Upstream commit b430b7751286b3acff2d324553c8cec4f1e87764 ]
Commit c6887cd11149 ("Btrfs: don't do nocow check unless we have to")
changed the behavior of __btrfs_buffered_write() so that it first tries
to get a data space reservation, and then skips the relatively expensive
nocow check if the reservation succeeded.
If we have quotas enabled, the data space reservation also includes a
quota reservation. But in the rewrite case, the space has already been
accounted for in qgroups. So btrfs_check_data_free_space() increases
the quota reservation, but it never gets decreased when the data
actually gets written and overwrites the pre-existing data. So we're
left with both the qgroup and qgroup reservation accounting for the same
space.
This commit adds the missing btrfs_qgroup_free_data() call in the case
of BTRFS_ORDERED_PREALLOC extents.
Fixes: c6887cd11149 ("Btrfs: don't do nocow check unless we have to")
Signed-off-by: Justin Maggard <jmaggard(a)netgear.com>
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/inode.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -3016,6 +3016,8 @@ static int btrfs_finish_ordered_io(struc
compress_type = ordered_extent->compress_type;
if (test_bit(BTRFS_ORDERED_PREALLOC, &ordered_extent->flags)) {
BUG_ON(compress_type);
+ btrfs_qgroup_free_data(inode, NULL, ordered_extent->file_offset,
+ ordered_extent->len);
ret = btrfs_mark_extent_written(trans, BTRFS_I(inode),
ordered_extent->file_offset,
ordered_extent->file_offset +
Patches currently in stable-queue which might be from jmaggard10(a)gmail.com are
queue-4.14/btrfs-fix-quota-reservation-leak-on-preallocated-files.patch
This is a note to let you know that I've just added the patch titled
btrfs: Fix possible off-by-one in btrfs_search_path_in_tree
to the 4.14-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-possible-off-by-one-in-btrfs_search_path_in_tree.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Fri, 1 Dec 2017 11:19:42 +0200
Subject: btrfs: Fix possible off-by-one in btrfs_search_path_in_tree
From: Nikolay Borisov <nborisov(a)suse.com>
[ Upstream commit c8bcbfbd239ed60a6562964b58034ac8a25f4c31 ]
The name char array passed to btrfs_search_path_in_tree is of size
BTRFS_INO_LOOKUP_PATH_MAX (4080). So the actual accessible char indexes
are in the range of [0, 4079]. Currently the code uses the define but this
represents an off-by-one.
Implications:
Size of btrfs_ioctl_ino_lookup_args is 4096, so the new byte will be
written to extra space, not some padding that could be provided by the
allocator.
btrfs-progs store the arguments on stack, but kernel does own copy of
the ioctl buffer and the off-by-one overwrite does not affect userspace,
but the ending 0 might be lost.
Kernel ioctl buffer is allocated dynamically so we're overwriting
somebody else's memory, and the ioctl is privileged if args.objectid is
not 256. Which is in most cases, but resolving a subvolume stored in
another directory will trigger that path.
Before this patch the buffer was one byte larger, but then the -1 was
not added.
Fixes: ac8e9819d71f907 ("Btrfs: add search and inode lookup ioctls")
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
[ added implications ]
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2221,7 +2221,7 @@ static noinline int btrfs_search_path_in
if (!path)
return -ENOMEM;
- ptr = &name[BTRFS_INO_LOOKUP_PATH_MAX];
+ ptr = &name[BTRFS_INO_LOOKUP_PATH_MAX - 1];
key.objectid = tree_id;
key.type = BTRFS_ROOT_ITEM_KEY;
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.14/btrfs-fix-possible-off-by-one-in-btrfs_search_path_in_tree.patch
This is a note to let you know that I've just added the patch titled
Btrfs: disable FUA if mounted with nobarrier
to the 4.14-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-disable-fua-if-mounted-with-nobarrier.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Omar Sandoval <osandov(a)fb.com>
Date: Tue, 5 Dec 2017 22:54:02 -0800
Subject: Btrfs: disable FUA if mounted with nobarrier
From: Omar Sandoval <osandov(a)fb.com>
[ Upstream commit 1b9e619c5bc8235cfba3dc4ced2fb0e3554a05d4 ]
I was seeing disk flushes still happening when I mounted a Btrfs
filesystem with nobarrier for testing. This is because we use FUA to
write out the first super block, and on devices without FUA support, the
block layer translates FUA to a flush. Even on devices supporting true
FUA, using FUA when we asked for no barriers is surprising.
Fixes: 387125fc722a8ed ("Btrfs: fix barrier flushes")
Signed-off-by: Omar Sandoval <osandov(a)fb.com>
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/disk-io.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3391,6 +3391,7 @@ static int write_dev_supers(struct btrfs
int errors = 0;
u32 crc;
u64 bytenr;
+ int op_flags;
if (max_mirrors == 0)
max_mirrors = BTRFS_SUPER_MIRROR_MAX;
@@ -3433,13 +3434,10 @@ static int write_dev_supers(struct btrfs
* we fua the first super. The others we allow
* to go down lazy.
*/
- if (i == 0) {
- ret = btrfsic_submit_bh(REQ_OP_WRITE,
- REQ_SYNC | REQ_FUA | REQ_META | REQ_PRIO, bh);
- } else {
- ret = btrfsic_submit_bh(REQ_OP_WRITE,
- REQ_SYNC | REQ_META | REQ_PRIO, bh);
- }
+ op_flags = REQ_SYNC | REQ_META | REQ_PRIO;
+ if (i == 0 && !btrfs_test_opt(device->fs_info, NOBARRIER))
+ op_flags |= REQ_FUA;
+ ret = btrfsic_submit_bh(REQ_OP_WRITE, op_flags, bh);
if (ret)
errors++;
}
Patches currently in stable-queue which might be from osandov(a)fb.com are
queue-4.14/btrfs-disable-fua-if-mounted-with-nobarrier.patch
This is a note to let you know that I've just added the patch titled
brcmfmac: Avoid build error with make W=1
to the 4.14-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:
brcmfmac-avoid-build-error-with-make-w-1.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Date: Thu, 23 Nov 2017 17:57:04 +0200
Subject: brcmfmac: Avoid build error with make W=1
From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
[ Upstream commit 51ef7925e10688c57186d438e784532e063492e4 ]
When I run make W=1 on gcc (Debian 7.2.0-16) 7.2.0 I got an error for
the first run, all next ones are okay.
CC [M] drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union!
scripts/Makefile.build:310: recipe for target 'drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o' failed
Seems like something happened with W=1 and wrong kernel doc format.
As a quick fix remove dubious /** in the code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Acked-by: Arend van Spriel <arend.vanspriel(a)broadcom.com>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -2064,7 +2064,7 @@ static int brcmf_sdio_txpkt_hdalign(stru
return head_pad;
}
-/**
+/*
* struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
* bus layer usage.
*/
Patches currently in stable-queue which might be from andriy.shevchenko(a)linux.intel.com are
queue-4.14/pinctrl-denverton-fix-uart2-rts-pin-mode.patch
queue-4.14/iio-proximity-sx9500-assign-interrupt-from-gpioio.patch
queue-4.14/brcmfmac-avoid-build-error-with-make-w-1.patch
This is a note to let you know that I've just added the patch titled
bnxt_en: Need to unconditionally shut down RoCE in bnxt_shutdown
to the 4.14-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:
bnxt_en-need-to-unconditionally-shut-down-roce-in-bnxt_shutdown.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Ray Jui <ray.jui(a)broadcom.com>
Date: Fri, 1 Dec 2017 03:13:02 -0500
Subject: bnxt_en: Need to unconditionally shut down RoCE in bnxt_shutdown
From: Ray Jui <ray.jui(a)broadcom.com>
[ Upstream commit a7f3f939dd7d8398acebecd1ceb2e9e7ffbe91d2 ]
The current 'bnxt_shutdown' implementation only invokes
'bnxt_ulp_shutdown' to shut down RoCE in the case when the system is in
the path of power off (SYSTEM_POWER_OFF). While this may work in most
cases, it does not work in the smart NIC case, when Linux 'reboot'
command is initiated from the Linux that runs on the ARM cores of the
NIC card. In this particular case, Linux 'reboot' results in a system
'L3' level reset where the entire ARM and associated subsystems are
being reset, but at the same time, Nitro core is being kept in sane state
(to allow external PCIe connected servers to continue to work). Without
properly shutting down RoCE and freeing all associated resources, it
results in the ARM core to hang immediately after the 'reboot'
By always invoking 'bnxt_ulp_shutdown' in 'bnxt_shutdown', it fixes the
above issue
Fixes: 0efd2fc65c92 ("bnxt_en: Add a callback to inform RDMA driver during PCI shutdown.")
Signed-off-by: Ray Jui <ray.jui(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -8218,8 +8218,9 @@ static void bnxt_shutdown(struct pci_dev
if (netif_running(dev))
dev_close(dev);
+ bnxt_ulp_shutdown(bp);
+
if (system_state == SYSTEM_POWER_OFF) {
- bnxt_ulp_shutdown(bp);
bnxt_clear_int_mode(bp);
pci_wake_from_d3(pdev, bp->wol);
pci_set_power_state(pdev, PCI_D3hot);
Patches currently in stable-queue which might be from ray.jui(a)broadcom.com are
queue-4.14/bnxt_en-need-to-unconditionally-shut-down-roce-in-bnxt_shutdown.patch
This is a note to let you know that I've just added the patch titled
ASoC: rsnd: ssi: fix race condition in rsnd_ssi_pointer_update
to the 4.14-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-fix-race-condition-in-rsnd_ssi_pointer_update.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Jiada Wang <jiada_wang(a)mentor.com>
Date: Thu, 7 Dec 2017 22:15:38 -0800
Subject: ASoC: rsnd: ssi: fix race condition in rsnd_ssi_pointer_update
From: Jiada Wang <jiada_wang(a)mentor.com>
[ Upstream commit 33f801366bdf3f8b67dfe325b84f4051a090d01e ]
Currently there is race condition between set of byte_pos and wrap
it around when new buffer starts. If .pointer is called in-between
it will result in inconsistent pointer position be returned
from .pointer callback.
This patch increments buffer pointer atomically to avoid this issue.
Signed-off-by: Jiada Wang <jiada_wang(a)mentor.com>
Reviewed-by: Takashi Sakamoto <takashi.sakamoto(a)miraclelinux.com>
Acked-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)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/sh/rcar/ssi.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -449,25 +449,29 @@ static bool rsnd_ssi_pointer_update(stru
int byte)
{
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
+ bool ret = false;
+ int byte_pos;
- ssi->byte_pos += byte;
+ byte_pos = ssi->byte_pos + byte;
- if (ssi->byte_pos >= ssi->next_period_byte) {
+ if (byte_pos >= ssi->next_period_byte) {
struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
ssi->period_pos++;
ssi->next_period_byte += ssi->byte_per_period;
if (ssi->period_pos >= runtime->periods) {
- ssi->byte_pos = 0;
+ byte_pos = 0;
ssi->period_pos = 0;
ssi->next_period_byte = ssi->byte_per_period;
}
- return true;
+ ret = true;
}
- return false;
+ WRITE_ONCE(ssi->byte_pos, byte_pos);
+
+ return ret;
}
/*
@@ -838,7 +842,7 @@ static int rsnd_ssi_pointer(struct rsnd_
struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
- *pointer = bytes_to_frames(runtime, ssi->byte_pos);
+ *pointer = bytes_to_frames(runtime, READ_ONCE(ssi->byte_pos));
return 0;
}
Patches currently in stable-queue which might be from jiada_wang(a)mentor.com are
queue-4.14/asoc-rsnd-ssi-fix-race-condition-in-rsnd_ssi_pointer_update.patch
This is a note to let you know that I've just added the patch titled
ASoC: rockchip: disable clock on error
to the 4.14-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-rockchip-disable-clock-on-error.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Stefan Potyra <Stefan.Potyra(a)elektrobit.com>
Date: Wed, 6 Dec 2017 16:03:24 +0100
Subject: ASoC: rockchip: disable clock on error
From: Stefan Potyra <Stefan.Potyra(a)elektrobit.com>
[ Upstream commit c7b92172a61b91936be985cb9bc499a4ebc6489b ]
Disable the clocks in rk_spdif_probe when an error occurs after one
of the clocks has been enabled previously.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: f874b80e1571 ASoC: rockchip: Add rockchip SPDIF transceiver driver
Signed-off-by: Stefan Potyra <Stefan.Potyra(a)elektrobit.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/rockchip/rockchip_spdif.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
--- a/sound/soc/rockchip/rockchip_spdif.c
+++ b/sound/soc/rockchip/rockchip_spdif.c
@@ -322,26 +322,30 @@ static int rk_spdif_probe(struct platfor
spdif->mclk = devm_clk_get(&pdev->dev, "mclk");
if (IS_ERR(spdif->mclk)) {
dev_err(&pdev->dev, "Can't retrieve rk_spdif master clock\n");
- return PTR_ERR(spdif->mclk);
+ ret = PTR_ERR(spdif->mclk);
+ goto err_disable_hclk;
}
ret = clk_prepare_enable(spdif->mclk);
if (ret) {
dev_err(spdif->dev, "clock enable failed %d\n", ret);
- return ret;
+ goto err_disable_clocks;
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(regs))
- return PTR_ERR(regs);
+ if (IS_ERR(regs)) {
+ ret = PTR_ERR(regs);
+ goto err_disable_clocks;
+ }
spdif->regmap = devm_regmap_init_mmio_clk(&pdev->dev, "hclk", regs,
&rk_spdif_regmap_config);
if (IS_ERR(spdif->regmap)) {
dev_err(&pdev->dev,
"Failed to initialise managed register map\n");
- return PTR_ERR(spdif->regmap);
+ ret = PTR_ERR(spdif->regmap);
+ goto err_disable_clocks;
}
spdif->playback_dma_data.addr = res->start + SPDIF_SMPDR;
@@ -373,6 +377,10 @@ static int rk_spdif_probe(struct platfor
err_pm_runtime:
pm_runtime_disable(&pdev->dev);
+err_disable_clocks:
+ clk_disable_unprepare(spdif->mclk);
+err_disable_hclk:
+ clk_disable_unprepare(spdif->hclk);
return ret;
}
Patches currently in stable-queue which might be from Stefan.Potyra(a)elektrobit.com are
queue-4.14/asoc-rockchip-disable-clock-on-error.patch
This is a note to let you know that I've just added the patch titled
ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context
to the 4.14-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-omap2-fix-sram-virt-to-phys-translation-for-save_secure_ram_context.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Tony Lindgren <tony(a)atomide.com>
Date: Mon, 27 Nov 2017 08:57:26 -0800
Subject: ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit d09220a887f70368afa79e850c95e74890c0a32d ]
With the CMA changes from Joonsoo Kim <iamjoonsoo.kim(a)lge.com>, it
was noticed that n900 stopped booting. After investigating it turned
out that n900 save_secure_ram_context does some whacky virtual to
physical address translation for the SRAM data address.
As we now only have minimal parts of omap3 idle code copied to SRAM,
running save_secure_ram_context() in SRAM is not needed. It only gets
called on PM init. And it seems there's no need to ever call this from
SRAM idle code.
So let's just keep save_secure_ram_context() in DDR, and pass it the
physical address of the parameters. We can do everything else in
omap-secure.c like we already do for other secure code.
And since we don't have any documentation, I still have no clue what
the values for 0, 1 and 1 for the parameters might be. If somebody has
figured it out, please do send a patch to add some comments.
Debugged-by: Joonsoo Kim <iamjoonsoo.kim(a)lge.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-omap2/omap-secure.c | 19 +++++++++++++++++++
arch/arm/mach-omap2/omap-secure.h | 4 ++++
arch/arm/mach-omap2/pm.h | 4 ----
arch/arm/mach-omap2/pm34xx.c | 13 ++++---------
arch/arm/mach-omap2/sleep34xx.S | 26 ++++----------------------
5 files changed, 31 insertions(+), 35 deletions(-)
--- a/arch/arm/mach-omap2/omap-secure.c
+++ b/arch/arm/mach-omap2/omap-secure.c
@@ -73,6 +73,25 @@ phys_addr_t omap_secure_ram_mempool_base
return omap_secure_memblock_base;
}
+u32 omap3_save_secure_ram(void __iomem *addr, int size)
+{
+ u32 ret;
+ u32 param[5];
+
+ if (size != OMAP3_SAVE_SECURE_RAM_SZ)
+ return OMAP3_SAVE_SECURE_RAM_SZ;
+
+ param[0] = 4; /* Number of arguments */
+ param[1] = __pa(addr); /* Physical address for saving */
+ param[2] = 0;
+ param[3] = 1;
+ param[4] = 1;
+
+ ret = save_secure_ram_context(__pa(param));
+
+ return ret;
+}
+
/**
* rx51_secure_dispatcher: Routine to dispatch secure PPA API calls
* @idx: The PPA API index
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -31,6 +31,8 @@
/* Maximum Secure memory storage size */
#define OMAP_SECURE_RAM_STORAGE (88 * SZ_1K)
+#define OMAP3_SAVE_SECURE_RAM_SZ 0x803F
+
/* Secure low power HAL API index */
#define OMAP4_HAL_SAVESECURERAM_INDEX 0x1a
#define OMAP4_HAL_SAVEHW_INDEX 0x1b
@@ -65,6 +67,8 @@ extern u32 omap_smc2(u32 id, u32 falg, u
extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
+extern u32 save_secure_ram_context(u32 args_pa);
+extern u32 omap3_save_secure_ram(void __iomem *save_regs, int size);
extern u32 rx51_secure_dispatcher(u32 idx, u32 process, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -81,10 +81,6 @@ extern unsigned int omap3_do_wfi_sz;
/* ... and its pointer from SRAM after copy */
extern void (*omap3_do_wfi_sram)(void);
-/* save_secure_ram_context function pointer and size, for copy to SRAM */
-extern int save_secure_ram_context(u32 *addr);
-extern unsigned int save_secure_ram_context_sz;
-
extern void omap3_save_scratchpad_contents(void);
#define PM_RTA_ERRATUM_i608 (1 << 0)
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -48,6 +48,7 @@
#include "prm3xxx.h"
#include "pm.h"
#include "sdrc.h"
+#include "omap-secure.h"
#include "sram.h"
#include "control.h"
#include "vc.h"
@@ -66,7 +67,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static int (*_omap_save_secure_sram)(u32 *addr);
void (*omap3_do_wfi_sram)(void);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -121,8 +121,8 @@ static void omap3_save_secure_ram_contex
* will hang the system.
*/
pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
- ret = _omap_save_secure_sram((u32 *)(unsigned long)
- __pa(omap3_secure_ram_storage));
+ ret = omap3_save_secure_ram(omap3_secure_ram_storage,
+ OMAP3_SAVE_SECURE_RAM_SZ);
pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
/* Following is for error tracking, it should not happen */
if (ret) {
@@ -434,15 +434,10 @@ static int __init pwrdms_setup(struct po
*
* The minimum set of functions is pushed to SRAM for execution:
* - omap3_do_wfi for erratum i581 WA,
- * - save_secure_ram_context for security extensions.
*/
void omap_push_sram_idle(void)
{
omap3_do_wfi_sram = omap_sram_push(omap3_do_wfi, omap3_do_wfi_sz);
-
- if (omap_type() != OMAP2_DEVICE_TYPE_GP)
- _omap_save_secure_sram = omap_sram_push(save_secure_ram_context,
- save_secure_ram_context_sz);
}
static void __init pm_errata_configure(void)
@@ -553,7 +548,7 @@ int __init omap3_pm_init(void)
clkdm_add_wkdep(neon_clkdm, mpu_clkdm);
if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
omap3_secure_ram_storage =
- kmalloc(0x803F, GFP_KERNEL);
+ kmalloc(OMAP3_SAVE_SECURE_RAM_SZ, GFP_KERNEL);
if (!omap3_secure_ram_storage)
pr_err("Memory allocation failed when allocating for secure sram context\n");
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -93,20 +93,13 @@ ENTRY(enable_omap3630_toggle_l2_on_resto
ENDPROC(enable_omap3630_toggle_l2_on_restore)
/*
- * Function to call rom code to save secure ram context. This gets
- * relocated to SRAM, so it can be all in .data section. Otherwise
- * we need to initialize api_params separately.
+ * Function to call rom code to save secure ram context.
+ *
+ * r0 = physical address of the parameters
*/
- .data
- .align 3
ENTRY(save_secure_ram_context)
stmfd sp!, {r4 - r11, lr} @ save registers on stack
- adr r3, api_params @ r3 points to parameters
- str r0, [r3,#0x4] @ r0 has sdram address
- ldr r12, high_mask
- and r3, r3, r12
- ldr r12, sram_phy_addr_mask
- orr r3, r3, r12
+ mov r3, r0 @ physical address of parameters
mov r0, #25 @ set service ID for PPA
mov r12, r0 @ copy secure service ID in r12
mov r1, #0 @ set task id for ROM code in r1
@@ -120,18 +113,7 @@ ENTRY(save_secure_ram_context)
nop
nop
ldmfd sp!, {r4 - r11, pc}
- .align
-sram_phy_addr_mask:
- .word SRAM_BASE_P
-high_mask:
- .word 0xffff
-api_params:
- .word 0x4, 0x0, 0x0, 0x1, 0x1
ENDPROC(save_secure_ram_context)
-ENTRY(save_secure_ram_context_sz)
- .word . - save_secure_ram_context
-
- .text
/*
* ======================
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.14/arm-dts-fix-elm-interrupt-compiler-warning.patch
queue-4.14/arm-omap2-fix-sram-virt-to-phys-translation-for-save_secure_ram_context.patch
queue-4.14/arm-dts-fix-omap4-hang-with-gps-connected-to-usb-by-using-wakeupgen.patch
queue-4.14/arm-dts-logicpd-som-lv-fix-gpmc-addresses-for-nand-and-enet.patch
queue-4.14/arm-am33xx-prm-remove-am33xx_pwrdm_read_prev_pwrst-function.patch
queue-4.14/arm-dts-logicpd-somlv-fix-wl127x-pinmux.patch
queue-4.14/arm-dts-am4372-correct-the-interrupts_properties-of-mcasp.patch
queue-4.14/arm-dts-am437x-cm-t43-correct-the-dmas-property-of-spi0.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: logicpd-somlv: Fix wl127x pinmux
to the 4.14-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-logicpd-somlv-fix-wl127x-pinmux.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Adam Ford <aford173(a)gmail.com>
Date: Tue, 31 Oct 2017 13:45:59 -0500
Subject: ARM: dts: logicpd-somlv: Fix wl127x pinmux
From: Adam Ford <aford173(a)gmail.com>
[ Upstream commit cd7594ac3281722cb8f10d6f6c7e4287747c7a9d ]
The pin assignment for the wl127x interrupt was incorrect. I am
not sure how this every worked. This also eliminates a conflict with
the SMC911x ethernet driver and properly moves pinmuxes for the
related gpio to omap3_pmx_wkup from omap3_pmx_core.
Fixes: ab8dd3aed011 ("ARM: DTS: Add minimal Support for Logic PD
DM3730 SOM-LV")
Signed-off-by: Adam Ford <aford173(a)gmail.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/logicpd-som-lv.dtsi | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
--- a/arch/arm/boot/dts/logicpd-som-lv.dtsi
+++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi
@@ -121,7 +121,7 @@
&mmc3 {
interrupts-extended = <&intc 94 &omap3_pmx_core2 0x46>;
- pinctrl-0 = <&mmc3_pins>;
+ pinctrl-0 = <&mmc3_pins &wl127x_gpio>;
pinctrl-names = "default";
vmmc-supply = <&wl12xx_vmmc>;
non-removable;
@@ -132,8 +132,8 @@
wlcore: wlcore@2 {
compatible = "ti,wl1273";
reg = <2>;
- interrupt-parent = <&gpio5>;
- interrupts = <24 IRQ_TYPE_LEVEL_HIGH>; /* gpio 152 */
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; /* gpio 2 */
ref-clock-frequency = <26000000>;
};
};
@@ -157,8 +157,6 @@
OMAP3_CORE1_IOPAD(0x2166, PIN_INPUT_PULLUP | MUX_MODE3) /* sdmmc2_dat5.sdmmc3_dat1 */
OMAP3_CORE1_IOPAD(0x2168, PIN_INPUT_PULLUP | MUX_MODE3) /* sdmmc2_dat6.sdmmc3_dat2 */
OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT_PULLUP | MUX_MODE3) /* sdmmc2_dat6.sdmmc3_dat3 */
- OMAP3_CORE1_IOPAD(0x2184, PIN_INPUT_PULLUP | MUX_MODE4) /* mcbsp4_clkx.gpio_152 */
- OMAP3_CORE1_IOPAD(0x2a0c, PIN_OUTPUT | MUX_MODE4) /* sys_boot1.gpio_3 */
OMAP3_CORE1_IOPAD(0x21d0, PIN_INPUT_PULLUP | MUX_MODE3) /* mcspi1_cs1.sdmmc3_cmd */
OMAP3_CORE1_IOPAD(0x21d2, PIN_INPUT_PULLUP | MUX_MODE3) /* mcspi1_cs2.sdmmc_clk */
>;
@@ -228,6 +226,12 @@
OMAP3_WKUP_IOPAD(0x2a0e, PIN_OUTPUT | MUX_MODE4) /* sys_boot2.gpio_4 */
>;
};
+ wl127x_gpio: pinmux_wl127x_gpio_pin {
+ pinctrl-single,pins = <
+ OMAP3_WKUP_IOPAD(0x2a0c, PIN_INPUT | MUX_MODE4) /* sys_boot0.gpio_2 */
+ OMAP3_WKUP_IOPAD(0x2a0c, PIN_OUTPUT | MUX_MODE4) /* sys_boot1.gpio_3 */
+ >;
+ };
};
&omap3_pmx_core2 {
Patches currently in stable-queue which might be from aford173(a)gmail.com are
queue-4.14/arm-dts-logicpd-som-lv-fix-gpmc-addresses-for-nand-and-enet.patch
queue-4.14/arm-dts-logicpd-somlv-fix-wl127x-pinmux.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: logicpd-som-lv: Fix gpmc addresses for NAND and enet
to the 4.14-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-logicpd-som-lv-fix-gpmc-addresses-for-nand-and-enet.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Adam Ford <aford173(a)gmail.com>
Date: Tue, 31 Oct 2017 13:42:13 -0500
Subject: ARM: dts: logicpd-som-lv: Fix gpmc addresses for NAND and enet
From: Adam Ford <aford173(a)gmail.com>
[ Upstream commit 3c18bbf3d11d2005da08b57ff26f44ff1c2b12d0 ]
This patch fixes and issue where the NAND and GPMC based ethernet
controller stopped working. This also updates the GPMC settings
to be consistent with the Logic PD Torpedo development from the
commit listed above.
Fixes: 44e4716499b8 ("ARM: dts: omap3: Fix NAND device nodes")
Signed-off-by: Adam Ford <aford173(a)gmail.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts | 3 ++-
arch/arm/boot/dts/logicpd-som-lv.dtsi | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts
@@ -72,7 +72,8 @@
};
&gpmc {
- ranges = <1 0 0x08000000 0x1000000>; /* CS1: 16MB for LAN9221 */
+ ranges = <0 0 0x30000000 0x1000000 /* CS0: 16MB for NAND */
+ 1 0 0x2c000000 0x1000000>; /* CS1: 16MB for LAN9221 */
ethernet@gpmc {
pinctrl-names = "default";
--- a/arch/arm/boot/dts/logicpd-som-lv.dtsi
+++ b/arch/arm/boot/dts/logicpd-som-lv.dtsi
@@ -37,7 +37,7 @@
};
&gpmc {
- ranges = <0 0 0x00000000 0x1000000>; /* CS0: 16MB for NAND */
+ ranges = <0 0 0x30000000 0x1000000>; /* CS0: 16MB for NAND */
nand@0,0 {
compatible = "ti,omap2-nand";
Patches currently in stable-queue which might be from aford173(a)gmail.com are
queue-4.14/arm-dts-logicpd-som-lv-fix-gpmc-addresses-for-nand-and-enet.patch
queue-4.14/arm-dts-logicpd-somlv-fix-wl127x-pinmux.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen
to the 4.14-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-fix-omap4-hang-with-gps-connected-to-usb-by-using-wakeupgen.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Tony Lindgren <tony(a)atomide.com>
Date: Fri, 17 Nov 2017 08:56:58 -0800
Subject: ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit cf87634c8b24e24bf379b8c6807c8b0fb5f23567 ]
There's been a reproducable USB OHCI/EHCI cpuidle related hang on omap4
for a while that happens after about 20 - 40 minutes on an idle system
with some data feeding device being connected, like a USB GPS device or
a cellular modem.
This issue happens in cpuidle states C2 and C3 and does not happen if
cpuidle is limited to C1 state only. The symptoms are that the whole
system hangs and never wakes up from idle, and if a watchdog is
configured the system reboots after a while.
Turns out that OHCI/EHCI devices on omap4 are trying to use the GIC
interrupt controller directly as a parent instead of the WUGEN. We
need to pass the interrupts through WUGEN to GIC to provide the wakeup
events for the processor.
Let's fix the issue by removing the gic interrupt-parent and use the
default interrupt-parent wakeupgen instead. Note that omap5.dtsi had
this already fixes earlier by commit 7136d457f365 ("ARM: omap: convert
wakeupgen to stacked domains") but we somehow missed omap4 at that
point.
Fixes: 7136d457f365 ("ARM: omap: convert wakeupgen to stacked domains")
Cc: Dave Gerlach <d-gerlach(a)ti.com>
Cc: Nishanth Menon <nm(a)ti.com>
Cc: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk>
Reviewed-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/omap4.dtsi | 2 --
1 file changed, 2 deletions(-)
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -861,14 +861,12 @@
usbhsohci: ohci@4a064800 {
compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
- interrupt-parent = <&gic>;
interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
};
usbhsehci: ehci@4a064c00 {
compatible = "ti,ehci-omap";
reg = <0x4a064c00 0x400>;
- interrupt-parent = <&gic>;
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
};
};
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.14/arm-dts-fix-elm-interrupt-compiler-warning.patch
queue-4.14/arm-omap2-fix-sram-virt-to-phys-translation-for-save_secure_ram_context.patch
queue-4.14/arm-dts-fix-omap4-hang-with-gps-connected-to-usb-by-using-wakeupgen.patch
queue-4.14/arm-dts-logicpd-som-lv-fix-gpmc-addresses-for-nand-and-enet.patch
queue-4.14/arm-am33xx-prm-remove-am33xx_pwrdm_read_prev_pwrst-function.patch
queue-4.14/arm-dts-logicpd-somlv-fix-wl127x-pinmux.patch
queue-4.14/arm-dts-am4372-correct-the-interrupts_properties-of-mcasp.patch
queue-4.14/arm-dts-am437x-cm-t43-correct-the-dmas-property-of-spi0.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: Fix elm interrupt compiler warning
to the 4.14-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-fix-elm-interrupt-compiler-warning.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Tony Lindgren <tony(a)atomide.com>
Date: Mon, 4 Dec 2017 08:27:17 -0800
Subject: ARM: dts: Fix elm interrupt compiler warning
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit d364b038bc962f494cffb8f6cb6cddbe41bcb5b6 ]
Looks like the interrupt property is missing the controller and level
information causing:
Warning (interrupts_property): interrupts size is (4), expected multiple
of 12 in /ocp/elm@48078000
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/omap4.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -354,7 +354,7 @@
elm: elm@48078000 {
compatible = "ti,am3352-elm";
reg = <0x48078000 0x2000>;
- interrupts = <4>;
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "elm";
status = "disabled";
};
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.14/arm-dts-fix-elm-interrupt-compiler-warning.patch
queue-4.14/arm-omap2-fix-sram-virt-to-phys-translation-for-save_secure_ram_context.patch
queue-4.14/arm-dts-fix-omap4-hang-with-gps-connected-to-usb-by-using-wakeupgen.patch
queue-4.14/arm-dts-logicpd-som-lv-fix-gpmc-addresses-for-nand-and-enet.patch
queue-4.14/arm-am33xx-prm-remove-am33xx_pwrdm_read_prev_pwrst-function.patch
queue-4.14/arm-dts-logicpd-somlv-fix-wl127x-pinmux.patch
queue-4.14/arm-dts-am4372-correct-the-interrupts_properties-of-mcasp.patch
queue-4.14/arm-dts-am437x-cm-t43-correct-the-dmas-property-of-spi0.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: am437x-cm-t43: Correct the dmas property of spi0
to the 4.14-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-am437x-cm-t43-correct-the-dmas-property-of-spi0.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Wed, 1 Nov 2017 11:03:40 +0200
Subject: ARM: dts: am437x-cm-t43: Correct the dmas property of spi0
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
[ Upstream commit ca41e244517d6d3f1600c229ff7ca615049c1e9c ]
The DMA binding for eDMA needs 2 parameters, not 1.
The second, missing parameter is the tptc to be used for the channel.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/am437x-cm-t43.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/am437x-cm-t43.dts
+++ b/arch/arm/boot/dts/am437x-cm-t43.dts
@@ -301,8 +301,8 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&spi0_pins>;
- dmas = <&edma 16
- &edma 17>;
+ dmas = <&edma 16 0
+ &edma 17 0>;
dma-names = "tx0", "rx0";
flash: w25q64cvzpig@0 {
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.14/arm-dts-am4372-correct-the-interrupts_properties-of-mcasp.patch
queue-4.14/arm-dts-am437x-cm-t43-correct-the-dmas-property-of-spi0.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: am4372: Correct the interrupts_properties of McASP
to the 4.14-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-am4372-correct-the-interrupts_properties-of-mcasp.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Wed, 1 Nov 2017 11:03:31 +0200
Subject: ARM: dts: am4372: Correct the interrupts_properties of McASP
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
[ Upstream commit 627395a6f8091c0aa18f49dca7df59ba3ec147ef ]
Fixes the following warnings:
arch/arm/boot/dts/am437x-cm-t43.dtb: Warning (interrupts_property):
interrupts size is (8), expected multiple of 12 in
/ocp@44000000/mcasp@48038000
arch/arm/boot/dts/am437x-cm-t43.dtb: Warning (interrupts_property):
interrupts size is (8), expected multiple of 12 in
/ocp@44000000/mcasp@4803C000
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/am4372.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -927,7 +927,8 @@
reg = <0x48038000 0x2000>,
<0x46000000 0x400000>;
reg-names = "mpu", "dat";
- interrupts = <80>, <81>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "tx", "rx";
status = "disabled";
dmas = <&edma 8 2>,
@@ -941,7 +942,8 @@
reg = <0x4803C000 0x2000>,
<0x46400000 0x400000>;
reg-names = "mpu", "dat";
- interrupts = <82>, <83>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "tx", "rx";
status = "disabled";
dmas = <&edma 10 2>,
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.14/arm-dts-am4372-correct-the-interrupts_properties-of-mcasp.patch
queue-4.14/arm-dts-am437x-cm-t43-correct-the-dmas-property-of-spi0.patch
This is a note to let you know that I've just added the patch titled
ARM: AM33xx: PRM: Remove am33xx_pwrdm_read_prev_pwrst function
to the 4.14-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-am33xx-prm-remove-am33xx_pwrdm_read_prev_pwrst-function.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Keerthy <j-keerthy(a)ti.com>
Date: Fri, 10 Nov 2017 16:56:52 +0530
Subject: ARM: AM33xx: PRM: Remove am33xx_pwrdm_read_prev_pwrst function
From: Keerthy <j-keerthy(a)ti.com>
[ Upstream commit b6d6af7226465b6d11eac09d0be2ab78a4a9eb62 ]
Referring TRM Am335X series:
http://www.ti.com/lit/ug/spruh73p/spruh73p.pdf
The LastPowerStateEntered bitfield is present only for PM_CEFUSE
domain. This is not present in any of the other power domains. Hence
remove the generic am33xx_pwrdm_read_prev_pwrst hook which wrongly
reads the reserved bit fields for all the other power domains.
Reading the reserved bits leads to wrongly interpreting the low
power transitions for various power domains that do not have the
LastPowerStateEntered field. The pm debug counters values are wrong
currently as we are incrementing them based on the reserved bits.
Signed-off-by: Keerthy <j-keerthy(a)ti.com>
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-omap2/prm33xx.c | 12 ------------
1 file changed, 12 deletions(-)
--- a/arch/arm/mach-omap2/prm33xx.c
+++ b/arch/arm/mach-omap2/prm33xx.c
@@ -176,17 +176,6 @@ static int am33xx_pwrdm_read_pwrst(struc
return v;
}
-static int am33xx_pwrdm_read_prev_pwrst(struct powerdomain *pwrdm)
-{
- u32 v;
-
- v = am33xx_prm_read_reg(pwrdm->prcm_offs, pwrdm->pwrstst_offs);
- v &= AM33XX_LASTPOWERSTATEENTERED_MASK;
- v >>= AM33XX_LASTPOWERSTATEENTERED_SHIFT;
-
- return v;
-}
-
static int am33xx_pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm)
{
am33xx_prm_rmw_reg_bits(AM33XX_LOWPOWERSTATECHANGE_MASK,
@@ -357,7 +346,6 @@ struct pwrdm_ops am33xx_pwrdm_operations
.pwrdm_set_next_pwrst = am33xx_pwrdm_set_next_pwrst,
.pwrdm_read_next_pwrst = am33xx_pwrdm_read_next_pwrst,
.pwrdm_read_pwrst = am33xx_pwrdm_read_pwrst,
- .pwrdm_read_prev_pwrst = am33xx_pwrdm_read_prev_pwrst,
.pwrdm_set_logic_retst = am33xx_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = am33xx_pwrdm_read_logic_pwrst,
.pwrdm_read_logic_retst = am33xx_pwrdm_read_logic_retst,
Patches currently in stable-queue which might be from j-keerthy(a)ti.com are
queue-4.14/gpio-davinci-assign-first-bank-regs-for-unbanked-case.patch
queue-4.14/arm-am33xx-prm-remove-am33xx_pwrdm_read_prev_pwrst-function.patch
This is a note to let you know that I've just added the patch titled
509: fix printing uninitialized stack memory when OID is empty
to the 4.14-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:
509-fix-printing-uninitialized-stack-memory-when-oid-is-empty.patch
and it can be found in the queue-4.14 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 Fri Feb 23 11:45:09 CET 2018
From: Eric Biggers <ebiggers3(a)gmail.com>
Date: Fri, 8 Dec 2017 15:13:28 +0000
Subject: 509: fix printing uninitialized stack memory when OID is empty
From: Eric Biggers <ebiggers3(a)gmail.com>
[ Upstream commit 8dfd2f22d3bf3ab7714f7495ad5d897b8845e8c1 ]
Callers of sprint_oid() do not check its return value before printing
the result. In the case where the OID is zero-length, -EBADMSG was
being returned without anything being written to the buffer, resulting
in uninitialized stack memory being printed. Fix this by writing
"(bad)" to the buffer in the cases where -EBADMSG is returned.
Fixes: 4f73175d0375 ("X.509: Add utility functions to render OIDs as strings")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/oid_registry.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/lib/oid_registry.c
+++ b/lib/oid_registry.c
@@ -116,7 +116,7 @@ int sprint_oid(const void *data, size_t
int count;
if (v >= end)
- return -EBADMSG;
+ goto bad;
n = *v++;
ret = count = snprintf(buffer, bufsize, "%u.%u", n / 40, n % 40);
@@ -134,7 +134,7 @@ int sprint_oid(const void *data, size_t
num = n & 0x7f;
do {
if (v >= end)
- return -EBADMSG;
+ goto bad;
n = *v++;
num <<= 7;
num |= n & 0x7f;
@@ -148,6 +148,10 @@ int sprint_oid(const void *data, size_t
}
return ret;
+
+bad:
+ snprintf(buffer, bufsize, "(bad)");
+ return -EBADMSG;
}
EXPORT_SYMBOL_GPL(sprint_oid);
Patches currently in stable-queue which might be from ebiggers3(a)gmail.com are
queue-4.14/509-fix-printing-uninitialized-stack-memory-when-oid-is-empty.patch
This is a note to let you know that I've just added the patch titled
xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies.
to the 3.18-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:
xfrm-fix-stack-out-of-bounds-with-misconfigured-transport-mode-policies.patch
and it can be found in the queue-3.18 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 Fri Feb 23 12:01:27 CET 2018
From: Steffen Klassert <steffen.klassert(a)secunet.com>
Date: Fri, 8 Dec 2017 08:07:25 +0100
Subject: xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies.
From: Steffen Klassert <steffen.klassert(a)secunet.com>
[ Upstream commit 732706afe1cc46ef48493b3d2b69c98f36314ae4 ]
On policies with a transport mode template, we pass the addresses
from the flowi to xfrm_state_find(), assuming that the IP addresses
(and address family) don't change during transformation.
Unfortunately our policy template validation is not strict enough.
It is possible to configure policies with transport mode template
where the address family of the template does not match the selectors
address family. This lead to stack-out-of-bound reads because
we compare arddesses of the wrong family. Fix this by refusing
such a configuration, address family can not change on transport
mode.
We use the assumption that, on transport mode, the first templates
address family must match the address family of the policy selector.
Subsequent transport mode templates must mach the address family of
the previous template.
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/xfrm/xfrm_user.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1349,11 +1349,14 @@ static void copy_templates(struct xfrm_p
static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family)
{
+ u16 prev_family;
int i;
if (nr > XFRM_MAX_DEPTH)
return -EINVAL;
+ prev_family = family;
+
for (i = 0; i < nr; i++) {
/* We never validated the ut->family value, so many
* applications simply leave it at zero. The check was
@@ -1365,6 +1368,12 @@ static int validate_tmpl(int nr, struct
if (!ut[i].family)
ut[i].family = family;
+ if ((ut[i].mode == XFRM_MODE_TRANSPORT) &&
+ (ut[i].family != prev_family))
+ return -EINVAL;
+
+ prev_family = ut[i].family;
+
switch (ut[i].family) {
case AF_INET:
break;
Patches currently in stable-queue which might be from steffen.klassert(a)secunet.com are
queue-3.18/xfrm-fix-stack-out-of-bounds-with-misconfigured-transport-mode-policies.patch
queue-3.18/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
xen: XEN_ACPI_PROCESSOR is Dom0-only
to the 3.18-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:
xen-xen_acpi_processor-is-dom0-only.patch
and it can be found in the queue-3.18 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 Fri Feb 23 12:01:27 CET 2018
From: Jan Beulich <JBeulich(a)suse.com>
Date: Tue, 12 Dec 2017 03:18:11 -0700
Subject: xen: XEN_ACPI_PROCESSOR is Dom0-only
From: Jan Beulich <JBeulich(a)suse.com>
[ Upstream commit c4f9d9cb2c29ff04c6b4bb09b72802d8aedfc7cb ]
Add a respective dependency.
Signed-off-by: Jan Beulich <jbeulich(a)suse.com>
Reviewed-by: Juergen Gross <jgross(a)suse.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/xen/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -222,7 +222,7 @@ config XEN_ACPI_HOTPLUG_CPU
config XEN_ACPI_PROCESSOR
tristate "Xen ACPI processor"
- depends on XEN && X86 && ACPI_PROCESSOR && CPU_FREQ
+ depends on XEN && XEN_DOM0 && X86 && ACPI_PROCESSOR && CPU_FREQ
default m
help
This ACPI processor uploads Power Management information to the Xen
Patches currently in stable-queue which might be from JBeulich(a)suse.com are
queue-3.18/xen-xen_acpi_processor-is-dom0-only.patch
This is a note to let you know that I've just added the patch titled
x86/mm/kmmio: Fix mmiotrace for page unaligned addresses
to the 3.18-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:
x86-mm-kmmio-fix-mmiotrace-for-page-unaligned-addresses.patch
and it can be found in the queue-3.18 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 Fri Feb 23 12:01:27 CET 2018
From: Karol Herbst <kherbst(a)redhat.com>
Date: Mon, 27 Nov 2017 08:51:39 +0100
Subject: x86/mm/kmmio: Fix mmiotrace for page unaligned addresses
From: Karol Herbst <kherbst(a)redhat.com>
[ Upstream commit 6d60ce384d1d5ca32b595244db4077a419acc687 ]
If something calls ioremap() with an address not aligned to PAGE_SIZE, the
returned address might be not aligned as well. This led to a probe
registered on exactly the returned address, but the entire page was armed
for mmiotracing.
On calling iounmap() the address passed to unregister_kmmio_probe() was
PAGE_SIZE aligned by the caller leading to a complete freeze of the
machine.
We should always page align addresses while (un)registerung mappings,
because the mmiotracer works on top of pages, not mappings. We still keep
track of the probes based on their real addresses and lengths though,
because the mmiotrace still needs to know what are mapped memory regions.
Also move the call to mmiotrace_iounmap() prior page aligning the address,
so that all probes are unregistered properly, otherwise the kernel ends up
failing memory allocations randomly after disabling the mmiotracer.
Tested-by: Lyude <lyude(a)redhat.com>
Signed-off-by: Karol Herbst <kherbst(a)redhat.com>
Acked-by: Pekka Paalanen <ppaalanen(a)gmail.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: nouveau(a)lists.freedesktop.org
Link: http://lkml.kernel.org/r/20171127075139.4928-1-kherbst@redhat.com
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/mm/ioremap.c | 4 ++--
arch/x86/mm/kmmio.c | 12 +++++++-----
2 files changed, 9 insertions(+), 7 deletions(-)
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -296,11 +296,11 @@ void iounmap(volatile void __iomem *addr
(void __force *)addr < phys_to_virt(ISA_END_ADDRESS))
return;
+ mmiotrace_iounmap(addr);
+
addr = (volatile void __iomem *)
(PAGE_MASK & (unsigned long __force)addr);
- mmiotrace_iounmap(addr);
-
/* Use the vm area unlocked, assuming the caller
ensures there isn't another iounmap for the same address
in parallel. Reuse of the virtual address is prevented by
--- a/arch/x86/mm/kmmio.c
+++ b/arch/x86/mm/kmmio.c
@@ -434,17 +434,18 @@ int register_kmmio_probe(struct kmmio_pr
unsigned long flags;
int ret = 0;
unsigned long size = 0;
+ unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
unsigned int l;
pte_t *pte;
spin_lock_irqsave(&kmmio_lock, flags);
- if (get_kmmio_probe(p->addr)) {
+ if (get_kmmio_probe(addr)) {
ret = -EEXIST;
goto out;
}
- pte = lookup_address(p->addr, &l);
+ pte = lookup_address(addr, &l);
if (!pte) {
ret = -EINVAL;
goto out;
@@ -453,7 +454,7 @@ int register_kmmio_probe(struct kmmio_pr
kmmio_count++;
list_add_rcu(&p->list, &kmmio_probes);
while (size < size_lim) {
- if (add_kmmio_fault_page(p->addr + size))
+ if (add_kmmio_fault_page(addr + size))
pr_err("Unable to set page fault.\n");
size += page_level_size(l);
}
@@ -527,19 +528,20 @@ void unregister_kmmio_probe(struct kmmio
{
unsigned long flags;
unsigned long size = 0;
+ unsigned long addr = p->addr & PAGE_MASK;
const unsigned long size_lim = p->len + (p->addr & ~PAGE_MASK);
struct kmmio_fault_page *release_list = NULL;
struct kmmio_delayed_release *drelease;
unsigned int l;
pte_t *pte;
- pte = lookup_address(p->addr, &l);
+ pte = lookup_address(addr, &l);
if (!pte)
return;
spin_lock_irqsave(&kmmio_lock, flags);
while (size < size_lim) {
- release_kmmio_fault_page(p->addr + size, &release_list);
+ release_kmmio_fault_page(addr + size, &release_list);
size += page_level_size(l);
}
list_del_rcu(&p->list);
Patches currently in stable-queue which might be from kherbst(a)redhat.com are
queue-3.18/x86-mm-kmmio-fix-mmiotrace-for-page-unaligned-addresses.patch
This is a note to let you know that I've just added the patch titled
usb: build drivers/usb/common/ when USB_SUPPORT is set
to the 3.18-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:
usb-build-drivers-usb-common-when-usb_support-is-set.patch
and it can be found in the queue-3.18 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 Fri Feb 23 12:01:27 CET 2018
From: Randy Dunlap <rdunlap(a)infradead.org>
Date: Fri, 17 Nov 2017 11:00:45 -0800
Subject: usb: build drivers/usb/common/ when USB_SUPPORT is set
From: Randy Dunlap <rdunlap(a)infradead.org>
[ Upstream commit c9d24f78268be444e803fb2bb138a2f598de9c23 ]
PHY drivers can use ULPI interfaces when CONFIG_USB (which is host side
support) is not enabled, so also build drivers/usb/ when CONFIG_USB_SUPPORT
is enabled so that drivers/usb/common/ is built.
ERROR: "ulpi_unregister_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined!
ERROR: "__ulpi_register_driver" [drivers/phy/ti/phy-tusb1210.ko] undefined!
ERROR: "ulpi_read" [drivers/phy/ti/phy-tusb1210.ko] undefined!
ERROR: "ulpi_write" [drivers/phy/ti/phy-tusb1210.ko] undefined!
ERROR: "ulpi_unregister_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined!
ERROR: "__ulpi_register_driver" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined!
ERROR: "ulpi_write" [drivers/phy/qualcomm/phy-qcom-usb-hs.ko] undefined!
Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/Makefile | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -90,6 +90,7 @@ obj-$(CONFIG_TC) += tc/
obj-$(CONFIG_UWB) += uwb/
obj-$(CONFIG_USB_PHY) += usb/
obj-$(CONFIG_USB) += usb/
+obj-$(CONFIG_USB_SUPPORT) += usb/
obj-$(CONFIG_PCI) += usb/
obj-$(CONFIG_USB_GADGET) += usb/
obj-$(CONFIG_SERIO) += input/serio/
Patches currently in stable-queue which might be from rdunlap(a)infradead.org are
queue-3.18/usb-build-drivers-usb-common-when-usb_support-is-set.patch
This is a note to let you know that I've just added the patch titled
spi: sun4i: disable clocks in the remove function
to the 3.18-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:
spi-sun4i-disable-clocks-in-the-remove-function.patch
and it can be found in the queue-3.18 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 Fri Feb 23 12:01:27 CET 2018
From: Takuo Koguchi <takuo.koguchi(a)gmail.com>
Date: Thu, 7 Dec 2017 16:20:14 +0900
Subject: spi: sun4i: disable clocks in the remove function
From: Takuo Koguchi <takuo.koguchi(a)gmail.com>
[ Upstream commit c810daba0ab5226084a56893a789af427a801146 ]
mclk and hclk need to be disabled. Since pm_runtime_disable does
not disable the clocks, use pm_runtime_force_suspend instead.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Takuo Koguchi <takuo.koguchi.sw(a)hitachi.com>
Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.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>
---
drivers/spi/spi-sun4i.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -458,7 +458,7 @@ err_free_master:
static int sun4i_spi_remove(struct platform_device *pdev)
{
- pm_runtime_disable(&pdev->dev);
+ pm_runtime_force_suspend(&pdev->dev);
return 0;
}
Patches currently in stable-queue which might be from takuo.koguchi(a)gmail.com are
queue-3.18/spi-sun4i-disable-clocks-in-the-remove-function.patch