The spi-cpha and spi-cpol properties are device specific and should be
accepted only if device really needs them. Drop them from common
spi-peripheral-props.yaml schema, mention in few panel drivers which use
them and include instead in the SPI controller bindings. The controller
bindings will provide CPHA/CPOL type validation and one place for
description. Each device schema must list the properties if they are
applicable.
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220722191539.90641-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Tomer Maimon <tmaimon77@gmail.com>:
This patch set adds Arbel NPCM8XX Flash Interface Unit (FIU) support to FIU NPCM
driver and modify direct read dummy configuration.
NPCM8XX FIU supports four controllers.
The NPCM FIU driver tested on NPCM845 evaluation board.
Recent Qualcomm Geni SPI nodes, e.g. on SM8450, come also with three
interconnects. This fixes dtbs_check warnings like:
sm8450-qrd.dtb: spi@a98000: interconnects: [[46, 1, 0, 46, 4, 0], [47, 2, 0, 48, 12, 0], [49, 1, 0, 50, 1, 0]] is too long
sm8450-qrd.dtb: spi@a98000: interconnect-names: ['qup-core', 'qup-config', 'qup-memory'] is too long
Fixes: 5bdcae1fe1 ("spi: dt-bindings: qcom,spi-geni-qcom: convert to dtschema")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220720163841.7283-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Adding FIU NPCM8XX support to NPCM FIU driver.
NPCM8XX FIU supports four controllers.
As part of adding NPCM8XX support:
- Add NPCM8XX specific compatible string.
- Using an internal burst configuration register instead of a GCR
register.
- Support FIU1 controller.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Link: https://lore.kernel.org/r/20220718081146.256070-4-tmaimon77@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from nandhini.srikandan@intel.com <nandhini.srikandan@intel.com>:
This patch enables support for DW SPI on Intel Thunder Bay. This patch
set also enables master mode for latest Designware SPI versions. The
driver is tested on Keem Bay and Thunder Bay evaluation board.
Merge series from Yang Yingliang <yangyingliang@huawei.com>:
Patch #1 fix a UAF in mchp_corespi_remove().
Patch #2 and #3 some cleanups to simpify code.
After calling spi_unregister_master(), the refcount of master will
be decrease to 0, and it will be freed in spi_controller_release(),
the device data also will be freed, so it will lead a UAF when using
'tspi'. To fix this, get the master before unregister and put it when
finish using it.
Fixes: 26c8634182 ("spi: tegra20-slink: Don't use resource-managed spi_register helper")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20220713094024.1508869-1-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>:
This patch series addresses an issue in the spi-amd driver and, while
there, performs some additional cleanups, like simplifying the error
handling in the probe function and removing an unused struct member.
For improving code readability, it also adds some kernel-doc comments.
Enabling the SPI CS35L41 audio codec driver for Steam Deck [1]
revealed a problem with the current AMD SPI controller driver
implementation, consisting of an unrecoverable system hang.
The issue can be prevented if we ensure the max transfer size
and the max message size do not exceed the FIFO buffer size.
According to the implementation of the downstream driver, the
AMD SPI controller is not able to handle more than 70 bytes per
transfer, which corresponds to the size of the FIFO buffer.
Hence, let's fix this by setting the SPI limits mentioned above.
[1] https://lore.kernel.org/r/20220621213819.262537-1-cristian.ciocaltea@collabora.com
Reported-by: Anastasios Vacharakis <vacharakis@o2mail.de>
Fixes: bbb336f39e ("spi: spi-amd: Add AMD SPI controller driver support")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20220706100626.1234731-2-cristian.ciocaltea@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Chanho Park <chanho61.park@samsung.com>:
Add to support Exynos Auto v9 SoC's spi. By supporting USI(Universal
Serial Interface) mode, the SoC can support up to 12 spi ports. Thus, we
need to increase MAX_SPI_PORTS from 6 to 12. The spi of the SoC can
support loopback mode unlike previous exynos SoCs. To separate the
feature, we need to add .has_loopback to the s3c64xx_spi_port_config.
Furthermore, it uses 4 as the default internal clock divider. We also
need to clk_div field of the structure and assign "2" as the default
value to the existing SoC's port config.
Device tree definitions of exynosautov9-spi will be added in separated
patchset to include usi(i2c/uart/spi) nodes all together.
Merge series from David Jander <david@protonic.nl>:
These patches optimize the spi_sync call for the common case that the
worker thread is idle and the queue is empty. It also opens the
possibility to potentially further optimize the async path also, since
it doesn't need to take into account the direct sync path anymore.
As an example for the performance gain, on an i.MX8MM SoC with a SPI CAN
controller attached (MCP2518FD), the time the interrupt line stays
active (which corresponds roughly with the time it takes to send 3
relatively short consecutive spi_sync messages) is reduced from 98us to
only 72us by this patch.
A note about message ordering:
This patch series should not change the behavior of message ordering when
coming from the same context. This means that if a client driver issues
one or more spi_async() messages immediately followed by a spi_sync()
message in the same context, it can still rely on these messages being
sent out in the order they were fired.
This fixes the sequence of dma_release_channel.
Since commit f52b03c707 ("spi: s3c64xx: requests spi-dma channel only
during data transfer"),
dma_release_channel has been located in the s3c64xx_spi_transfer_one
but this makes invalid return of can_dma callback.
__spi_unmap_msg will check whether the request is requested by dma or
not via can_dma callback. When it is calling to check it, the channels
will be already released at the end of s3c64xx_spi_transfer_one so the
callback function will return always "false". So, they can't be unmapped
from __spi_unmap_msg call. To fix this, we need to add
unprepare_transfer_hardware callback and move the dma_release_channel
from s3c64xx_spi_transfer_one to there.
Fixes: f52b03c707 ("spi: s3c64xx: requests spi-dma channel only during data transfer")
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Link: https://lore.kernel.org/r/20220627013845.138350-1-chanho61.park@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
