Pull ACPI updates from Rafael Wysocki:
"These update the ACPICA code in the kernel to upstream revision
20210105, fix and clean up the handling of device properties, add
support for setting global profile of the platform, clean up device
enumeration, the CPPC library, the APEI support and more, update the
documentation, consolidate the printing of messages in several places
and make assorted janitorial changes.
Specifics:
- Update ACPICA code in the kernel to upstream revision 20201113 with
changes as follows:
* Remove the MTMR (Mid-Timer) table (Al Stone).
* Remove the VRTC table (Al Stone).
* Add type casts for string functions (Bob Moore).
* Update all copyrights to 2021 (Bob Moore).
* Fix exception code class checks (Maximilian Luz).
* Clean up exception code class checks (Maximilian Luz).
* Fix -Wfallthrough (Nick Desaulniers).
- Add support for setting and reading global profile of the platform
along with documentation (Mark Pearson, Hans de Goede, Jiaxun
Yang).
- Fix fwnode properties matching and clean up the code handling
device properties and its documentation (Rafael Wysocki, Andy
Shevchenko).
- Clean up ACPI-based device enumeration code (Rafael Wysocki).
- Clean up the CPPC support library code (Ionela Voinescu).
- Clean up the APEI support code (Yang Li, Yazen Ghannam).
- Update GPIO-related properties documentation (Flavio Suligoi).
- Consolidate and clean up the printing of messages in several places
(Rafael Wysocki).
- Fix error code path in configfs handling code (Qinglang Miao).
- Use DEVICE_ATTR_<RW|RO|WO> macros where applicable (Dwaipayan Ray).
- Replace tests for !ACPI_FAILURE with tests for ACPI_SUCCESS in
multiple places (Bjorn Helgaas)"
* tag 'acpi-5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (44 commits)
ACPI: property: Satisfy kernel doc validator (part 2)
ACPI: property: Satisfy kernel doc validator (part 1)
ACPI: property: Make acpi_node_prop_read() static
ACPI: property: Remove dead code
ACPI: property: Fix fwnode string properties matching
ACPI: OSL: Clean up printing messages
ACPI: OSL: Rework acpi_check_resource_conflict()
ACPI: APEI: ERST: remove unneeded semicolon
ACPI: thermal: Clean up printing messages
ACPI: video: Clean up printing messages
ACPI: button: Clean up printing messages
ACPI: battery: Clean up printing messages
ACPI: AC: Clean up printing messages
ACPI: bus: Drop ACPI_BUS_COMPONENT which is not used any more
ACPI: utils: Clean up printing messages
ACPI: scan: Clean up printing messages
ACPI: bus: Clean up printing messages
ACPI: PM: Clean up printing messages
ACPI: power: Clean up printing messages
ACPI: APEI: Add is_generic_error() to identify GHES sources
...
Pull ARM SoC platform removals from Arnd Bergmann:
"There are a lot of platforms that have not seen any interesting code
changes in the past five years or more.
I made a list and asked around which ones are no longer in use, and
received confirmation about six ARM platforms and the TI C6x
architecture that have all reached the end of their life upstream,
with no known users remaining:
- efm32 - added in 2011, first Cortex-M, no notable changes after 2013
- picoxcell - added in 2011, abandoned after 2012 acquisition
- prima2 - added in 20111, no notable changes since 2015
- tango - added in 2015, sporadic changes until 2017, but abandoned
- u300 - added in 2009, no notable changes since 2013
- zx - added in 2015 for both 32, 2017 for 64 bit, no notable changes
- arch/c6x - added in 2011, but work stalled soon after that
A number of other platforms on the original list turned out to still
have users. In some cases there are out-of-tree patches and users that
plan to contribute them in the future, in other cases the code is
complete and works reliably"
Link: https://lore.kernel.org/lkml/CAK8P3a2DZ8xQp7R=H=wewHnT2=a_=M53QsZOueMVEf7tOZLKNg@mail.gmail.com/
* tag 'arm-platform-removal-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
ARM: remove u300 platform
ARM: remove tango platform
ARM: remove zte zx platform
ARM: remove sirf prima2/atlas platforms
c6x: remove architecture
MAINTAINERS: Remove deleted platform efm32
ARM: drop efm32 platform
ARM: Remove PicoXcell platform support
ARM: dts: Remove PicoXcell platforms
The Ericsson U300 platform was one of two ARM929 based SoC platforms for
mobile phones in ST-Ericsson after the merger of Ericsson with ST-NXP
into ST-Ericsson, the other one being the ST Nomadik.
The platform was not widely adopted in Linux based systems and was
replaced with the far superior ST-Ericsson U8500 in 2011, but Linus
Walleij kept maintaining the code for the whole time.
Linus continues to use the Nomadik machine, but decided to drop
u300 from the kernel as part of this year's spring cleaning.
Thanks for having maintained it all these years.
Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/lkml/CACRpkdbJkiHR9FSfJTH_5d_qRU1__dRXHM1TL40iqNRKbGQfrQ@mail.gmail.com/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
If spi->controller->max_speed_hz is zero, a non-zero spi->max_speed_hz
will be overwritten by zero. Make sure spi->controller->max_speed_hz
is not zero when clamping spi->max_speed_hz.
Put the spi->controller->max_speed_hz non-zero check higher in the if,
so that we avoid a superfluous init to zero when both spi->max_speed_hz
and spi->controller->max_speed_hz are zero.
Fixes: 9326e4f1e5 ("spi: Limit the spi device max speed to controller's max speed")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201216092321.413262-1-tudor.ambarus@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch fixes the return value for altera_spi_txrx. It should return
1 for interrupt transfer mode, and return 0 for polling transfer mode.
The altera_spi_txrx() implements the spi_controller.transfer_one
callback. According to the spi-summary.rst, the transfer_one should
return 0 when transfer is finished, return 1 when transfer is still in
progress.
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Link: https://lore.kernel.org/r/1609219662-27057-2-git-send-email-yilun.xu@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
if cur_bpw <= 8 and xfer_len < 4 then the value of fthlv will be 1 and
SPI registers content may have been lost.
* If SPI data register is accessed as a 16-bit register and DSIZE <= 8bit,
better to select FTHLV = 2, 4, 6 etc
* If SPI data register is accessed as a 32-bit register and DSIZE > 8bit,
better to select FTHLV = 2, 4, 6 etc, while if DSIZE <= 8bit,
better to select FTHLV = 4, 8, 12 etc
Signed-off-by: Roman Guskov <rguskov@dh-electronics.com>
Fixes: dcbe0d84df ("spi: add driver for STM32 SPI controller")
Reviewed-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20201221123532.27272-1-rguskov@dh-electronics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If we get a timeout sending then this happens:
spi_transfer_one_message()
->transfer_one() AKA spi_geni_transfer_one()
setup_fifo_xfer()
mas->cur_xfer = non-NULL
spi_transfer_wait() => TIMES OUT
if (msg->status != -EINPROGRESS)
goto out
if (ret != 0 ...)
spi_set_cs()
->set_cs AKA spi_geni_set_cs()
# mas->cur_xfer is non-NULL
The above happens _before_ the SPI core calls ->handle_err() AKA
handle_fifo_timeout().
Unfortunately that won't work so well on geni. If we got a timeout
transferring then it's likely that our interrupt handler is blocked,
but we need that same interrupt handler to run and the command channel
to be unblocked in order to adjust the chip select. Trying to set the
chip select doesn't crash us but ends up confusing our state machine
and leads to messages like: Premature done. rx_rem = 32 bpw8
Let's just drop the chip select request in this case. We can detect
the case because cur_xfer is non-NULL--it would have been set to NULL
in the interrupt handler if the previous transfer had finished. Sure,
we might leave the chip select in the wrong state but it's likely it
was going to fail anyway and this avoids getting the driver even more
confused about what it's doing.
The SPI core in general assumes that setting chip select is a simple
operation that doesn't fail. Yet another reason to just reconfigure
the chip select line as GPIOs.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20201217142842.v3.3.I07afdedcc49655c5d26880f8df9170aac5792378@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
If we got a timeout when trying to send an abort command then it means
that we just got 3 timeouts in a row:
1. The original timeout that caused handle_fifo_timeout() to be
called.
2. A one second timeout waiting for the cancel command to finish.
3. A one second timeout waiting for the abort command to finish.
SPI is clocked by the controller, so nothing (aside from a hardware
fault or a totally broken sequencer) should be causing the actual
commands to fail in hardware. However, even though the hardware
itself is not expected to fail (and it'd be hard to predict how we
should handle things if it did), it's easy to hit the timeout case by
simply blocking our interrupt handler from running for a long period
of time. Obviously the system is in pretty bad shape if a interrupt
handler is blocked for > 2 seconds, but there are certainly bugs (even
bugs in other unrelated drivers) that can make this happen.
Let's make things a bit more robust against this case. If we fail to
abort we'll set a flag and then we'll block all future transfers until
we have no more interrupts pending.
Fixes: 561de45f72 ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20201217142842.v3.2.Ibade998ed587e070388b4bf58801f1107a40eb53@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
In commit 7ba9bdcb91 ("spi: spi-geni-qcom: Don't keep a local state
variable") we changed handle_fifo_timeout() so that we set
"mas->cur_xfer" to NULL to make absolutely sure that we don't mess
with the buffers from the previous transfer in the timeout case.
Unfortunately, this caused the IRQ handler to dereference NULL in some
cases. One case:
CPU0 CPU1
---- ----
setup_fifo_xfer()
geni_se_setup_m_cmd()
<hardware starts transfer>
<transfer completes in hardware>
<hardware sets M_RX_FIFO_WATERMARK_EN in m_irq>
...
handle_fifo_timeout()
spin_lock_irq(mas->lock)
mas->cur_xfer = NULL
geni_se_cancel_m_cmd()
spin_unlock_irq(mas->lock)
geni_spi_isr()
spin_lock(mas->lock)
if (m_irq & M_RX_FIFO_WATERMARK_EN)
geni_spi_handle_rx()
mas->cur_xfer NULL dereference!
tl;dr: Seriously delayed interrupts for RX/TX can lead to timeout
handling setting mas->cur_xfer to NULL.
Let's check for the NULL transfer in the TX and RX cases and reset the
watermark or clear out the fifo respectively to put the hardware back
into a sane state.
NOTE: things still could get confused if we get timeouts all the way
through handle_fifo_timeout() and then start a new transfer because
interrupts from the old transfer / cancel / abort could still be
pending. A future patch will help this corner case.
Fixes: 561de45f72 ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20201217142842.v3.1.I99ee04f0cb823415df59bd4f550d6ff5756e43d6@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
The Canaan Kendryte K210 RISC-V SoC includes a DW apb_ssi v4 controller
which is documented to have a 32 words deep TX and RX FIFO. The FIFO
length detection in spi_hw_init() correctly detects this value.
However, when the controller RX FIFO is filled up to 32 entries
(RXFLR = 32), an RX FIFO overrun error occurs. This likely due to a
hardware bug which can be avoided by force setting the fifo_len field of
struct dw_spi to 31.
Define the dw_spi_canaan_k210_init() function to force set fifo_len to
31 when the device node compatible string is "canaan,k210-spi".
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Acked-by: Serge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/20201206011817.11700-4-damien.lemoal@wdc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward
define a 32-bits maximum transfer size synthesis parameter
(SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration
(SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32,
the layout of the ctrlr0 register changes, moving the data frame format
field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size
can be up to 32-bits.
To support this new format, introduce the DW SPI capability flag
DW_SPI_CAP_DFS32 to indicate that a controller is configured with
SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis
parameter not accessible through a register, the detection of this
parameter value is done in spi_hw_init() by writing and reading the
ctrlr0 register and testing the value of bits [3..0]. These bits are
ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection.
If a DFS32 capable SPI controller is detected, the new field dfs_offset
in struct dw_spi is set to SPI_DFS32_OFFSET (16).
dw_spi_update_config() is modified to set the data frame size field at
the correct position is the CTRLR0 register, as indicated by the
dfs_offset field of the dw_spi structure.
The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave
controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI
capability flag set. However, for these ssi controllers, the dfs_offset
field is set to 0 as before (as per specifications).
Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag
set, dw_spi_add_host() extends the value of bits_per_word_mask from
16-bits to 32-bits. dw_reader() and dw_writer() are also modified to
handle 32-bits iTX/RX FIFO words.
Suggested-by: Sean Anderson <seanga2@gmail.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Acked-by: Serge Semin <fancer.lancer@gmail.com>
Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Starting with the move of the atmel-quadspi driver under SPI,
the following error could be seen when mounting a 16MByte ubifs:
UBIFS error (ubi0:0 pid 1893): check_lpt_type.constprop.6: invalid type (15) in LPT node type
1/4 fixes AHB accesses. The rest of the patches are small optimizations.
Tested on both sama5d2 and sam9x60.
Tudor Ambarus (4):
spi: atmel-quadspi: Fix AHB memory accesses
spi: atmel-quadspi: Drop superfluous set of QSPI_IFR_APBTFRTYP_READ
spi: atmel-quadspi: Write QSPI_IAR only when needed
spi: atmel-quadspi: Move common code outside of if else
drivers/spi/atmel-quadspi.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
--
2.25.1
base-commit: 3650b228f8
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
If the call to devm_spi_register_controller() fails on probe of the
Qualcomm Atheros AR934x/QCA95xx SPI driver, the spi_controller struct is
erroneously not freed. Fix by switching over to the new
devm_spi_alloc_master() helper.
Moreover, the controller's clock is enabled on probe but not disabled if
any of the subsequent probe steps fail.
Finally, there's an ordering issue in ar934x_spi_remove() wherein the
clock is disabled even though the controller is not yet unregistered.
It is unregistered after ar934x_spi_remove() by the devres framework.
As long as it is not unregistered, SPI transfers may still be ongoing
and disabling the clock may break them. It is not possible to use
devm_spi_register_controller() in this case, so move to the non-devm
variant.
All of these bugs have existed since the driver was first introduced,
so it seems fair to fix them together in a single commit.
Fixes: 047980c582 ("spi: add driver for ar934x spi controller")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v5.7+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v5.7+
Cc: Chuanhong Guo <gch981213@gmail.com>
Link: https://lore.kernel.org/r/1d58367d74d55741e0c2730a51a2b65012c8ab33.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If the calls to device_reset() or devm_spi_register_controller() fail on
probe of the MediaTek MT7621 SPI driver, the spi_controller struct is
erroneously not freed. Fix by switching over to the new
devm_spi_alloc_master() helper.
Additionally, there's an ordering issue in mt7621_spi_remove() wherein
the spi_controller is unregistered after disabling the SYS clock.
The correct order is to call spi_unregister_controller() *before* this
teardown step because bus accesses may still be ongoing until that
function returns.
All of these bugs have existed since the driver was first introduced,
so it seems fair to fix them together in a single commit.
Fixes: 1ab7f2a435 ("staging: mt7621-spi: add mt7621 support")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: <stable@vger.kernel.org> # v4.17+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v4.17+
Link: https://lore.kernel.org/r/72b680796149f5fcda0b3f530ffb7ee73b04f224.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
If the call to devm_spi_register_master() fails on probe of the GPIO SPI
driver, the spi_master struct is erroneously not freed:
After allocating the spi_master, its reference count is 1. The driver
unconditionally decrements the reference count on unbind using a devm
action. Before calling devm_spi_register_master(), the driver
unconditionally increments the reference count because on success,
that function will decrement the reference count on unbind. However on
failure, devm_spi_register_master() does *not* decrement the reference
count, so the spi_master is leaked.
The issue was introduced by commits 8b797490b4 ("spi: gpio: Make sure
spi_master_put() is called in every error path") and 79567c1a32 ("spi:
gpio: Use devm_spi_register_master()"), which sought to plug leaks
introduced by 9b00bc7b90 ("spi: spi-gpio: Rewrite to use GPIO
descriptors") but missed this remaining leak.
The situation was later aggravated by commit d3b0ffa1d7 ("spi: gpio:
prevent memory leak in spi_gpio_probe"), which introduced a
use-after-free because it releases a reference on the spi_master if
devm_add_action_or_reset() fails even though the function already
does that.
Fix by switching over to the new devm_spi_alloc_master() helper.
Fixes: 9b00bc7b90 ("spi: spi-gpio: Rewrite to use GPIO descriptors")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: <stable@vger.kernel.org> # v4.17+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v5.1-: 8b797490b4: spi: gpio: Make sure spi_master_put() is called in every error path
Cc: <stable@vger.kernel.org> # v5.1-: 45beec3519: spi: bitbang: Introduce spi_bitbang_init()
Cc: <stable@vger.kernel.org> # v5.1-: 79567c1a32: spi: gpio: Use devm_spi_register_master()
Cc: <stable@vger.kernel.org> # v5.4-: d3b0ffa1d7: spi: gpio: prevent memory leak in spi_gpio_probe
Cc: <stable@vger.kernel.org> # v4.17+
Cc: Navid Emamdoost <navid.emamdoost@gmail.com>
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
Link: https://lore.kernel.org/r/86eaed27431c3d709e3748eb76ceecbfc790dd37.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
spi_geni_remove() accesses the driver's private data after calling
spi_unregister_master() even though that function releases the last
reference on the spi_master and thereby frees the private data.
Moreover, since commit 1a9e489e61 ("spi: spi-geni-qcom: Use OPP API to
set clk/perf state"), spi_geni_probe() leaks the spi_master allocation
if the calls to dev_pm_opp_set_clkname() or dev_pm_opp_of_add_table()
fail.
Fix by switching over to the new devm_spi_alloc_master() helper which
keeps the private data accessible until the driver has unbound and also
avoids the spi_master leak on probe.
Fixes: 561de45f72 ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: <stable@vger.kernel.org> # v4.20+: 5e844cc37a: spi: Introduce device-managed SPI controller allocation
Cc: <stable@vger.kernel.org> # v4.20+
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Cc: Girish Mahadevan <girishm@codeaurora.org>
Link: https://lore.kernel.org/r/dfa1d8c41b8acdfad87ec8654cd124e6e3cb3f31.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Following error was seen when mounting a 16MByte ubifs:
UBIFS error (ubi0:0 pid 1893): check_lpt_type.constprop.6: invalid type (15) in LPT node type
QSPI_IFR.TFRTYP was not set correctly. When data transfer is enabled
and one wants to access the serial memory through AHB in order to:
- read in the serial memory, but not a memory data, for example
a JEDEC-ID, QSPI_IFR.TFRTYP must be written to '0' (both sama5d2
and sam9x60).
- read in the serial memory, and particularly a memory data,
TFRTYP must be written to '1' (both sama5d2 and sam9x60).
- write in the serial memory, but not a memory data, for example
writing the configuration or the QSPI_SR, TFRTYP must be written
to '2' for sama5d2 and to '0' for sam9x60.
- write in the serial memory in particular to program a memory data,
TFRTYP must be written to '3' for sama5d2 and to '1' for sam9x60.
Fix the setting of the QSPI_IFR.TFRTYP field.
Fixes: 2d30ac5ed6 ("mtd: spi-nor: atmel-quadspi: Use spi-mem interface for atmel-quadspi driver")
Cc: <stable@vger.kernel.org> # v5.0+
Reported-by: Tom Burkart <tom@aussec.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20201207135959.154124-2-tudor.ambarus@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
