From: Victor Gu <xigu(a)marvell.com>
The PCI configuration space read/write functions were special casing
the situation where PCI_SLOT(devfn) != 0, and returned
PCIBIOS_DEVICE_NOT_FOUND in this case.
However, while this is what is intended for the root bus, it is not
intended for the child busses, as it prevents discovering devices with
PCI_SLOT(x) != 0. Therefore, we return PCIBIOS_DEVICE_NOT_FOUND only
if we're on the root bus.
Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller driver")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Victor Gu <xigu(a)marvell.com>
Reviewed-by: Wilson Ding <dingwei(a)marvell.com>
Reviewed-by: Nadav Haklai <nadavh(a)marvell.com>
[Thomas: tweak commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
---
Changes since v2:
- The logic has been factorized into a advk_pcie_valid_device()
helper in a previous patch, so this patch was adjusted accordingly.
---
drivers/pci/host/pci-aardvark.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c
index ccd0304a0c21..be140dc7109b 100644
--- a/drivers/pci/host/pci-aardvark.c
+++ b/drivers/pci/host/pci-aardvark.c
@@ -433,7 +433,7 @@ static int advk_pcie_wait_pio(struct advk_pcie *pcie)
static int advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,
int devfn)
{
- if (PCI_SLOT(devfn) != 0)
+ if ((bus->number == pcie->root_bus_nr) && PCI_SLOT(devfn) != 0)
return false;
return true;
--
2.14.3
From: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
In other to mimic other PCIe host controller drivers, introduce an
advk_pcie_valid_device() helper, used in the configuration read/write
functions.
This patch by itself is not a fix, but it is required for a follow-up
patch that is a fix, hence the Fixes tag and the Cc to stable.
Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller driver")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
---
Changes since v2:
- New patch
---
drivers/pci/host/pci-aardvark.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/host/pci-aardvark.c b/drivers/pci/host/pci-aardvark.c
index b04d37b3c5de..ccd0304a0c21 100644
--- a/drivers/pci/host/pci-aardvark.c
+++ b/drivers/pci/host/pci-aardvark.c
@@ -430,6 +430,15 @@ static int advk_pcie_wait_pio(struct advk_pcie *pcie)
return -ETIMEDOUT;
}
+static int advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,
+ int devfn)
+{
+ if (PCI_SLOT(devfn) != 0)
+ return false;
+
+ return true;
+}
+
static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn,
int where, int size, u32 *val)
{
@@ -437,7 +446,7 @@ static int advk_pcie_rd_conf(struct pci_bus *bus, u32 devfn,
u32 reg;
int ret;
- if (PCI_SLOT(devfn) != 0) {
+ if (!advk_pcie_valid_device(pcie, bus, devfn)) {
*val = 0xffffffff;
return PCIBIOS_DEVICE_NOT_FOUND;
}
@@ -491,7 +500,7 @@ static int advk_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
int offset;
int ret;
- if (PCI_SLOT(devfn) != 0)
+ if (!advk_pcie_valid_device(pcie, bus, devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
if (where % size)
--
2.14.3
Despite the efforts made to correctly read the NDA and CUBC registers,
the order in which the registers are read could sometimes lead to an
inconsistent state.
Re-using the timeline from the comments, this following timing of
registers reads could lead to reading NDA with value "@desc2" and
CUBC with value "MAX desc1":
INITD -------- ------------
|____________________|
_______________________ _______________
NDA @desc2 \/ @desc3
_______________________/\_______________
__________ ___________ _______________
CUBC 0 \/ MAX desc1 \/ MAX desc2
__________/\___________/\_______________
| | | |
Events:(1)(2) (3)(4)
(1) check_nda = @desc2
(2) initd = 1
(3) cur_ubc = MAX desc1
(4) cur_nda = @desc2
This is allowed by the condition ((check_nda == cur_nda) && initd),
despite cur_ubc and cur_nda being in the precise state we don't want.
This error leads to incorrect residue computation.
Fix it by inversing the order in which CUBC and INITD are read. This
makes sure that NDA and CUBC are always read together either _before_
INITD goes to 0 or _after_ it is back at 1.
The case where NDA is read before INITD is at 0 and CUBC is read after
INITD is back at 1 will be rejected by check_nda and cur_nda being
different.
Fixes: 53398f488821 ("dmaengine: at_xdmac: fix residue corruption")
Cc: stable(a)vger.kernel.org
Signed-off-by: Maxime Jayat <maxime.jayat(a)mobile-devices.fr>
---
Hi,
I had a bug where the serial ports on the Atmel SAMA5D2 were sometimes
returning the same data twice, for up to 4096 bytes.
After investigation, I noticed that the ring buffer used in
atmel_serial (in rx dma mode) had sometimes a incorrect "head" value,
which made the ring buffer do a complete extraneous loop of data
pushed to the tty layer.
I tracked it down to the residue of the dma being wrong, and after
more head scratching, I found this bug in the reading of the
registers.
Before fixing this, I was able to reproduce the bug reliably in a few
minutes. With this patch applied, the bug did not reappear after
several hours in testing.
drivers/dma/at_xdmac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index c00e3923d7d8..94236ec9d410 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -1471,10 +1471,10 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
for (retry = 0; retry < AT_XDMAC_RESIDUE_MAX_RETRIES; retry++) {
check_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 0xfffffffc;
rmb();
- initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & AT_XDMAC_CC_INITD);
- rmb();
cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
rmb();
+ initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & AT_XDMAC_CC_INITD);
+ rmb();
cur_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 0xfffffffc;
rmb();
--
2.14.1
Make the default for PHYSICAL_START always 64-bit, ensuring that a
correct sign-extended value is used if a 32-bit image is loaded by a
64-bit system, and matching how the load address is set in platform
Makefile fragments (arch/mips/*/Platform) in the absence of the
PHYSICAL_START configuration option.
Of course PHYSICAL_START itself is a misnomer as the load address is
virtual rather than physical (or otherwise sign-extension would not
apply).
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Fixes: 7aa1c8f47e7e ("MIPS: kdump: Add support")
Cc: stable(a)vger.kernel.org # 3.8+
---
Hi James,
As discussed in the context of commit 27c524d17430 ("MIPS: Use the entry
point from the ELF file header"). This may require verifying by someone
who actually uses this feature. I have cc-ed Maxim, the original author,
in case he has anything to add.
I'm not sure if we want to do anything about the physical vs virtual load
address confusion.
Please consider.
Maciej
---
arch/mips/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
linux-mips-physical-start.diff
Index: linux-jhogan-test/arch/mips/Kconfig
===================================================================
--- linux-jhogan-test.orig/arch/mips/Kconfig 2018-03-21 17:22:12.000000000 +0000
+++ linux-jhogan-test/arch/mips/Kconfig 2018-03-23 09:19:25.049100000 +0000
@@ -2849,8 +2849,7 @@ config CRASH_DUMP
config PHYSICAL_START
hex "Physical address where the kernel is loaded"
- default "0xffffffff84000000" if 64BIT
- default "0x84000000" if 32BIT
+ default "0xffffffff84000000"
depends on CRASH_DUMP
help
This gives the CKSEG0 or KSEG0 address where the kernel is loaded.
On Mon, Mar 19, 2018 at 02:13:23PM -0400, Kash Pande wrote:
> On 2018-03-16 11:22 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.28 release.
> > There are 109 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Mar 18 15:22:53 UTC 2018.
> > Anything received after that time might be too late.
>
> Any chance to get the k10temp change for Threadripper 1900X offset
> reporting included [https://patchwork.kernel.org/patch/10175457/]?
>
Ryzen and Threadripper are only supported in v4.15+.
Guenter
This is a note to let you know that I've just added the patch titled
staging: lustre: ptlrpc: kfree used instead of kvfree
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
staging-lustre-ptlrpc-kfree-used-instead-of-kvfree.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c3eec59659cf25916647d2178c541302bb4822ad Mon Sep 17 00:00:00 2001
From: Nadav Amit <namit(a)vmware.com>
Date: Tue, 5 Sep 2017 20:25:25 +0000
Subject: staging: lustre: ptlrpc: kfree used instead of kvfree
From: Nadav Amit <namit(a)vmware.com>
commit c3eec59659cf25916647d2178c541302bb4822ad upstream.
rq_reqbuf is allocated using kvmalloc() but released in one occasion
using kfree() instead of kvfree().
The issue was found using grep based on a similar bug.
Fixes: d7e09d0397e8 ("add Lustre file system client support")
Fixes: ee0ec1946ec2 ("lustre: ptlrpc: Replace uses of OBD_{ALLOC,FREE}_LARGE")
Cc: Peng Tao <bergwolf(a)gmail.com>
Cc: Oleg Drokin <oleg.drokin(a)intel.com>
Cc: James Simmons <jsimmons(a)infradead.org>
Signed-off-by: Nadav Amit <namit(a)vmware.com>
Signed-off-by: Andreas Dilger <andreas.dilger(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/lustre/lustre/ptlrpc/sec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/lustre/lustre/ptlrpc/sec.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/sec.c
@@ -838,7 +838,7 @@ void sptlrpc_request_out_callback(struct
if (req->rq_pool || !req->rq_reqbuf)
return;
- kfree(req->rq_reqbuf);
+ kvfree(req->rq_reqbuf);
req->rq_reqbuf = NULL;
req->rq_reqbuf_len = 0;
}
Patches currently in stable-queue which might be from namit(a)vmware.com are
queue-4.9/staging-lustre-ptlrpc-kfree-used-instead-of-kvfree.patch
This is a note to let you know that I've just added the patch titled
iio: ABI: Fix name of timestamp sysfs file
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iio-abi-fix-name-of-timestamp-sysfs-file.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b9a3589332c2a25fb7edad25a26fcaada3209126 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Tue, 5 Dec 2017 11:57:27 +0100
Subject: iio: ABI: Fix name of timestamp sysfs file
From: Linus Walleij <linus.walleij(a)linaro.org>
commit b9a3589332c2a25fb7edad25a26fcaada3209126 upstream.
The name of the file is "current_timetamp_clock" not
"timestamp_clock".
Fixes: bc2b7dab629a ("iio:core: timestamping clock selection support")
Cc: Gregor Boirie <gregor.boirie(a)parrot.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Documentation/ABI/testing/sysfs-bus-iio | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -32,7 +32,7 @@ Description:
Description of the physical chip / device for device X.
Typically a part number.
-What: /sys/bus/iio/devices/iio:deviceX/timestamp_clock
+What: /sys/bus/iio/devices/iio:deviceX/current_timestamp_clock
KernelVersion: 4.5
Contact: linux-iio(a)vger.kernel.org
Description:
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.9/iio-abi-fix-name-of-timestamp-sysfs-file.patch
This is a note to let you know that I've just added the patch titled
staging: lustre: ptlrpc: kfree used instead of kvfree
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:
staging-lustre-ptlrpc-kfree-used-instead-of-kvfree.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 c3eec59659cf25916647d2178c541302bb4822ad Mon Sep 17 00:00:00 2001
From: Nadav Amit <namit(a)vmware.com>
Date: Tue, 5 Sep 2017 20:25:25 +0000
Subject: staging: lustre: ptlrpc: kfree used instead of kvfree
From: Nadav Amit <namit(a)vmware.com>
commit c3eec59659cf25916647d2178c541302bb4822ad upstream.
rq_reqbuf is allocated using kvmalloc() but released in one occasion
using kfree() instead of kvfree().
The issue was found using grep based on a similar bug.
Fixes: d7e09d0397e8 ("add Lustre file system client support")
Fixes: ee0ec1946ec2 ("lustre: ptlrpc: Replace uses of OBD_{ALLOC,FREE}_LARGE")
Cc: Peng Tao <bergwolf(a)gmail.com>
Cc: Oleg Drokin <oleg.drokin(a)intel.com>
Cc: James Simmons <jsimmons(a)infradead.org>
Signed-off-by: Nadav Amit <namit(a)vmware.com>
Signed-off-by: Andreas Dilger <andreas.dilger(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/lustre/lustre/ptlrpc/sec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/lustre/lustre/ptlrpc/sec.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/sec.c
@@ -824,7 +824,7 @@ void sptlrpc_request_out_callback(struct
if (req->rq_pool || !req->rq_reqbuf)
return;
- kfree(req->rq_reqbuf);
+ kvfree(req->rq_reqbuf);
req->rq_reqbuf = NULL;
req->rq_reqbuf_len = 0;
}
Patches currently in stable-queue which might be from namit(a)vmware.com are
queue-4.4/staging-lustre-ptlrpc-kfree-used-instead-of-kvfree.patch