From: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri(a)xilinx.com>
[ Upstream commit 21b511ddee09a78909035ec47a6a594349fe3296 ]
As part of unprepare_transfer_hardware, SPI controller will be disabled
which will indirectly deassert the CS line. This will create a problem
in some of the devices where message will be transferred with
cs_change flag set(CS should not be deasserted).
As per SPI controller implementation, if SPI controller is disabled then
all output enables are inactive and all pins are set to input mode which
means CS will go to default state high(deassert). This leads to an issue
when core explicitly ask not to deassert the CS (cs_change = 1). This
patch fix the above issue by checking the Slave select status bits from
configuration register before disabling the SPI.
Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri(a)xilinx.com>
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra(a)xilinx.com>
Link: https://lore.kernel.org/r/20220606062525.18447-1-amit.kumar-mahapatra@xilin…
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
drivers/spi/spi-cadence.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-cadence.c b/drivers/spi/spi-cadence.c
index ceb16e70d235..90b18c32f859 100644
--- a/drivers/spi/spi-cadence.c
+++ b/drivers/spi/spi-cadence.c
@@ -69,6 +69,7 @@
#define CDNS_SPI_BAUD_DIV_SHIFT 3 /* Baud rate divisor shift in CR */
#define CDNS_SPI_SS_SHIFT 10 /* Slave Select field shift in CR */
#define CDNS_SPI_SS0 0x1 /* Slave Select zero */
+#define CDNS_SPI_NOSS 0x3C /* No Slave select */
/*
* SPI Interrupt Registers bit Masks
@@ -449,15 +450,20 @@ static int cdns_prepare_transfer_hardware(struct spi_master *master)
* @master: Pointer to the spi_master structure which provides
* information about the controller.
*
- * This function disables the SPI master controller.
+ * This function disables the SPI master controller when no slave selected.
*
* Return: 0 always
*/
static int cdns_unprepare_transfer_hardware(struct spi_master *master)
{
struct cdns_spi *xspi = spi_master_get_devdata(master);
+ u32 ctrl_reg;
- cdns_spi_write(xspi, CDNS_SPI_ER, CDNS_SPI_ER_DISABLE);
+ /* Disable the SPI if slave is deselected */
+ ctrl_reg = cdns_spi_read(xspi, CDNS_SPI_CR);
+ ctrl_reg = (ctrl_reg & CDNS_SPI_CR_SSCTRL) >> CDNS_SPI_SS_SHIFT;
+ if (ctrl_reg == CDNS_SPI_NOSS)
+ cdns_spi_write(xspi, CDNS_SPI_ER, CDNS_SPI_ER_DISABLE);
return 0;
}
--
2.35.1
When a driver registers with a bus, it will attempt to match with every
device on the bus through the __driver_attach() function. Currently, if
the bus_type.match() function encounters an error that is not
-EPROBE_DEFER, __driver_attach() will return a negative error code, which
causes the driver registration logic to stop trying to match with the
remaining devices on the bus.
This behavior is not correct; a failure while matching a driver to a
device does not mean that the driver won't be able to match and bind
with other devices on the bus. Update the logic in __driver_attach()
to reflect this.
Fixes: 656b8035b0ee ("ARM: 8524/1: driver cohandle -EPROBE_DEFER from bus_type.match()")
Cc: stable(a)vger.kernel.org
Cc: Saravana Kannan <saravanak(a)google.com>
Signed-off-by: Isaac J. Manjarres <isaacmanjarres(a)google.com>
---
drivers/base/dd.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
This problem was not reported anywhere, but rather it was something that
I noticed while looking at this function.
--Isaac
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index ec69b43f926a..6669daf1f31f 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -1162,7 +1162,11 @@ static int __driver_attach(struct device *dev, void *data)
return 0;
} else if (ret < 0) {
dev_dbg(dev, "Bus failed to match device: %d\n", ret);
- return ret;
+ /*
+ * Driver could not match with device, but may match with
+ * another device on the bus.
+ */
+ return 0;
} /* ret > 0 means positive match */
if (driver_allows_async_probing(drv)) {
--
2.37.3.968.ga6b4b080e4-goog
Hi,
This is v2 of the series, addressing a small issue pointed out in the
original submission and adds a third patch to switch to using BIT_ULL.
See individual changes for further details. The original cover letter
follows.
A recent change has added a SERIAL_8250_16550A_VARIANTS option, which
lets one request the 8250 driver not to probe for 16550A device features
so as to reduce the driver's device startup time in virtual machines.
This has turned out problematic to a more recent update for the OxSemi
Tornado series PCIe devices, whose new baud rate generator handling code
actually requires switching hardware into the enhanced mode for correct
operation, which actually requires 16550A device features to have been
probed for.
This small patch series fixes the issue by letting individual device
subdrivers to request full 16550A device feature probing by means of a
flag regardless of the SERIAL_8250_16550A_VARIANTS setting chosen.
The changes have been verified with an OXPCIe952 device, in the native
UART mode and a 64-bit RISC-V system as well as in the legacy UART mode
and a 32-bit x86 system.
Credit to Anders for reporting this issue and then working through the
resolution.
Maciej
Hi,
A recent change has added a SERIAL_8250_16550A_VARIANTS option, which
lets one request the 8250 driver not to probe for 16550A device features
so as to reduce the driver's device startup time in virtual machines.
This has turned out problematic to a more recent update for the OxSemi
Tornado series PCIe devices, whose new baud rate generator handling code
actually requires switching hardware into the enhanced mode for correct
operation, which actually requires 16550A device features to have been
probed for.
This small patch series fixes the issue by letting individual device
subdrivers to request full 16550A device feature probing by means of a
flag regardless of the SERIAL_8250_16550A_VARIANTS setting chosen.
The changes have been verified with an OXPCIe952 device, in the native
UART mode and a 64-bit RISC-V system as well as in the legacy UART mode
and a 32-bit x86 system.
Credit to Anders for reporting this issue and then working through the
resolution.
Maciej
The check_object_size() helper under CONFIG_HARDENED_USERCOPY is
designed to skip any checks where the length is known at compile time as
a reasonable heuristic to avoid "likely known-good" cases. However, it can
only do this when the copy_*_user() helpers are, themselves, inline too.
Using find_vmap_area() requires taking a spinlock. The check_object_size()
helper can call find_vmap_area() when the destination is in vmap memory.
If show_regs() is called in interrupt context, it will attempt a call to
copy_from_user_nmi(), which may call check_object_size() and then
find_vmap_area(). If something in normal context happens to be in the
middle of calling find_vmap_area() (with the spinlock held), the interrupt
handler will hang forever.
The copy_from_user_nmi() call is actually being called with a fixed-size
length, so check_object_size() should never have been called in
the first place. Given the narrow constraints, just replace the
__copy_from_user_inatomic() call with an open-coded version that calls
only into the sanitizers and not check_object_size(), followed by a call
to raw_copy_from_user().
Reported-by: Yu Zhao <yuzhao(a)google.com>
Link: https://lore.kernel.org/all/CAOUHufaPshtKrTWOz7T7QFYUNVGFm0JBjvM700Nhf9qEL9…
Reported-by: dev(a)der-flo.net
Suggested-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Josh Poimboeuf <jpoimboe(a)kernel.org>
Cc: Dave Hansen <dave.hansen(a)linux.intel.com>
Cc: x86(a)kernel.org
Fixes: 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns")
Cc: stable(a)vger.kernel.org
Signed-off-by: Kees Cook <keescook(a)chromium.org>
---
v2: drop the call explicitly instead of using inline to do it
v1: https://lore.kernel.org/lkml/20220916135953.1320601-1-keescook@chromium.org
---
arch/x86/lib/usercopy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/lib/usercopy.c b/arch/x86/lib/usercopy.c
index ad0139d25401..d2aff9b176cf 100644
--- a/arch/x86/lib/usercopy.c
+++ b/arch/x86/lib/usercopy.c
@@ -44,7 +44,8 @@ copy_from_user_nmi(void *to, const void __user *from, unsigned long n)
* called from other contexts.
*/
pagefault_disable();
- ret = __copy_from_user_inatomic(to, from, n);
+ instrument_copy_from_user(to, from, n);
+ ret = raw_copy_from_user(to, from, n);
pagefault_enable();
return ret;
--
2.34.1
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 80d82ca9562bb881f2884ccb33b5530d40144450
Gitweb: https://git.kernel.org/tip/80d82ca9562bb881f2884ccb33b5530d40144450
Author: Kees Cook <keescook(a)chromium.org>
AuthorDate: Mon, 19 Sep 2022 13:16:48 -07:00
Committer: Dave Hansen <dave.hansen(a)linux.intel.com>
CommitterDate: Tue, 20 Sep 2022 14:43:49 -07:00
x86/uaccess: Avoid check_object_size() in copy_from_user_nmi()
The check_object_size() helper under CONFIG_HARDENED_USERCOPY is
designed to skip any checks where the length is known at compile time as
a reasonable heuristic to avoid "likely known-good" cases. However, it can
only do this when the copy_*_user() helpers are, themselves, inline too.
Using find_vmap_area() requires taking a spinlock. The check_object_size()
helper can call find_vmap_area() when the destination is in vmap memory.
If show_regs() is called in interrupt context, it will attempt a call to
copy_from_user_nmi(), which may call check_object_size() and then
find_vmap_area(). If something in normal context happens to be in the
middle of calling find_vmap_area() (with the spinlock held), the interrupt
handler will hang forever.
The copy_from_user_nmi() call is actually being called with a fixed-size
length, so check_object_size() should never have been called in
the first place. Given the narrow constraints, just replace the
__copy_from_user_inatomic() call with an open-coded version that calls
only into the sanitizers and not check_object_size(), followed by a call
to raw_copy_from_user().
Fixes: 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns")
Reported-by: Yu Zhao <yuzhao(a)google.com>
Reported-by: dev(a)der-flo.net
Suggested-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Acked-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Tested-by: Florian Lehner <dev(a)der-flo.net>
Cc: stable(a)vger.kernel.org
Link: https://lore.kernel.org/all/CAOUHufaPshtKrTWOz7T7QFYUNVGFm0JBjvM700Nhf9qEL9…
Link: https://lkml.kernel.org/r/20220919201648.2250764-1-keescook@chromium.org
---
arch/x86/lib/usercopy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/lib/usercopy.c b/arch/x86/lib/usercopy.c
index ad0139d..d2aff9b 100644
--- a/arch/x86/lib/usercopy.c
+++ b/arch/x86/lib/usercopy.c
@@ -44,7 +44,8 @@ copy_from_user_nmi(void *to, const void __user *from, unsigned long n)
* called from other contexts.
*/
pagefault_disable();
- ret = __copy_from_user_inatomic(to, from, n);
+ instrument_copy_from_user(to, from, n);
+ ret = raw_copy_from_user(to, from, n);
pagefault_enable();
return ret;