UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/drivers/spi/spi-axi-spi-engine.c

603 lines
15 KiB
C
Raw Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 177 Based on 1 normalized pattern(s): licensed under the gpl 2 extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 135 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Richard Fontana <rfontana@redhat.com> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Steve Winslow <swinslow@gmail.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190528170026.071193225@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-29 00:57:06 +08:00
// SPDX-License-Identifier: GPL-2.0-only
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
/*
* SPI-Engine SPI controller driver
* Copyright 2015 Analog Devices Inc.
* Author: Lars-Peter Clausen <lars@metafoo.de>
*/
#include <linux/clk.h>
spi: axi-spi-engine: use common AXI macros [ Upstream commit 88c2b56c2690061121cad03f0f551db465287575 ] This avoid duplicating the same macros in multiple drivers by reusing the common AXI macros for the version register. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240202213132.3863124-2-dlechner@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-03 05:31:32 +08:00
#include <linux/fpga/adi-axi-common.h>
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
#include <linux/idr.h>
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/of.h>
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/spi/spi.h>
#define SPI_ENGINE_REG_RESET 0x40
#define SPI_ENGINE_REG_INT_ENABLE 0x80
#define SPI_ENGINE_REG_INT_PENDING 0x84
#define SPI_ENGINE_REG_INT_SOURCE 0x88
#define SPI_ENGINE_REG_SYNC_ID 0xc0
#define SPI_ENGINE_REG_CMD_FIFO_ROOM 0xd0
#define SPI_ENGINE_REG_SDO_FIFO_ROOM 0xd4
#define SPI_ENGINE_REG_SDI_FIFO_LEVEL 0xd8
#define SPI_ENGINE_REG_CMD_FIFO 0xe0
#define SPI_ENGINE_REG_SDO_DATA_FIFO 0xe4
#define SPI_ENGINE_REG_SDI_DATA_FIFO 0xe8
#define SPI_ENGINE_REG_SDI_DATA_FIFO_PEEK 0xec
#define SPI_ENGINE_INT_CMD_ALMOST_EMPTY BIT(0)
#define SPI_ENGINE_INT_SDO_ALMOST_EMPTY BIT(1)
#define SPI_ENGINE_INT_SDI_ALMOST_FULL BIT(2)
#define SPI_ENGINE_INT_SYNC BIT(3)
#define SPI_ENGINE_CONFIG_CPHA BIT(0)
#define SPI_ENGINE_CONFIG_CPOL BIT(1)
#define SPI_ENGINE_CONFIG_3WIRE BIT(2)
#define SPI_ENGINE_INST_TRANSFER 0x0
#define SPI_ENGINE_INST_ASSERT 0x1
#define SPI_ENGINE_INST_WRITE 0x2
#define SPI_ENGINE_INST_MISC 0x3
#define SPI_ENGINE_CMD_REG_CLK_DIV 0x0
#define SPI_ENGINE_CMD_REG_CONFIG 0x1
#define SPI_ENGINE_MISC_SYNC 0x0
#define SPI_ENGINE_MISC_SLEEP 0x1
#define SPI_ENGINE_TRANSFER_WRITE 0x1
#define SPI_ENGINE_TRANSFER_READ 0x2
#define SPI_ENGINE_CMD(inst, arg1, arg2) \
(((inst) << 12) | ((arg1) << 8) | (arg2))
#define SPI_ENGINE_CMD_TRANSFER(flags, n) \
SPI_ENGINE_CMD(SPI_ENGINE_INST_TRANSFER, (flags), (n))
#define SPI_ENGINE_CMD_ASSERT(delay, cs) \
SPI_ENGINE_CMD(SPI_ENGINE_INST_ASSERT, (delay), (cs))
#define SPI_ENGINE_CMD_WRITE(reg, val) \
SPI_ENGINE_CMD(SPI_ENGINE_INST_WRITE, (reg), (val))
#define SPI_ENGINE_CMD_SLEEP(delay) \
SPI_ENGINE_CMD(SPI_ENGINE_INST_MISC, SPI_ENGINE_MISC_SLEEP, (delay))
#define SPI_ENGINE_CMD_SYNC(id) \
SPI_ENGINE_CMD(SPI_ENGINE_INST_MISC, SPI_ENGINE_MISC_SYNC, (id))
struct spi_engine_program {
unsigned int length;
uint16_t instructions[];
};
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
/**
* struct spi_engine_message_state - SPI engine per-message state
*/
struct spi_engine_message_state {
/** Instructions for executing this message. */
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
struct spi_engine_program *p;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
/** Number of elements in cmd_buf array. */
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
unsigned cmd_length;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
/** Array of commands not yet written to CMD FIFO. */
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
const uint16_t *cmd_buf;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
/** Next xfer with tx_buf not yet fully written to TX FIFO. */
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
struct spi_transfer *tx_xfer;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
/** Size of tx_buf in bytes. */
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
unsigned int tx_length;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
/** Bytes not yet written to TX FIFO. */
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
const uint8_t *tx_buf;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
/** Next xfer with rx_buf not yet fully written to RX FIFO. */
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
struct spi_transfer *rx_xfer;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
/** Size of tx_buf in bytes. */
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
unsigned int rx_length;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
/** Bytes not yet written to the RX FIFO. */
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
uint8_t *rx_buf;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
/** ID to correlate SYNC interrupts with this message. */
u8 sync_id;
};
struct spi_engine {
struct clk *clk;
struct clk *ref_clk;
spinlock_t lock;
void __iomem *base;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
struct spi_message *msg;
struct ida sync_ida;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
unsigned int completed_id;
unsigned int int_enable;
};
static void spi_engine_program_add_cmd(struct spi_engine_program *p,
bool dry, uint16_t cmd)
{
if (!dry)
p->instructions[p->length] = cmd;
p->length++;
}
static unsigned int spi_engine_get_config(struct spi_device *spi)
{
unsigned int config = 0;
if (spi->mode & SPI_CPOL)
config |= SPI_ENGINE_CONFIG_CPOL;
if (spi->mode & SPI_CPHA)
config |= SPI_ENGINE_CONFIG_CPHA;
if (spi->mode & SPI_3WIRE)
config |= SPI_ENGINE_CONFIG_3WIRE;
return config;
}
static unsigned int spi_engine_get_clk_div(struct spi_engine *spi_engine,
struct spi_device *spi, struct spi_transfer *xfer)
{
unsigned int clk_div;
clk_div = DIV_ROUND_UP(clk_get_rate(spi_engine->ref_clk),
xfer->speed_hz * 2);
if (clk_div > 255)
clk_div = 255;
else if (clk_div > 0)
clk_div -= 1;
return clk_div;
}
static void spi_engine_gen_xfer(struct spi_engine_program *p, bool dry,
struct spi_transfer *xfer)
{
unsigned int len = xfer->len;
while (len) {
unsigned int n = min(len, 256U);
unsigned int flags = 0;
if (xfer->tx_buf)
flags |= SPI_ENGINE_TRANSFER_WRITE;
if (xfer->rx_buf)
flags |= SPI_ENGINE_TRANSFER_READ;
spi_engine_program_add_cmd(p, dry,
SPI_ENGINE_CMD_TRANSFER(flags, n - 1));
len -= n;
}
}
static void spi_engine_gen_sleep(struct spi_engine_program *p, bool dry,
spi: spi-axi: extend support for the `delay` field The AXI SPI engine driver uses the `delay_usecs` field from `spi_transfer` to configure delays, which the controller will execute. This change extends the logic to also include the `delay` value, in case it is used (instead if `delay_usecs`). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20190926105147.7839-20-alexandru.ardelean@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-26 18:51:47 +08:00
struct spi_engine *spi_engine, unsigned int clk_div,
struct spi_transfer *xfer)
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
{
unsigned int spi_clk = clk_get_rate(spi_engine->ref_clk);
unsigned int t;
spi: spi-axi: extend support for the `delay` field The AXI SPI engine driver uses the `delay_usecs` field from `spi_transfer` to configure delays, which the controller will execute. This change extends the logic to also include the `delay` value, in case it is used (instead if `delay_usecs`). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20190926105147.7839-20-alexandru.ardelean@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-26 18:51:47 +08:00
int delay;
spi: spi-axi-spi-engine: remove usage of delay_usecs The 'delay_usecs' field was handled for backwards compatibility in case there were some users that still configured SPI delay transfers with this field. They should all be removed by now. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210308145502.1075689-2-aardelean@deviqon.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-08 22:54:53 +08:00
delay = spi_delay_to_ns(&xfer->delay, xfer);
if (delay < 0)
return;
delay /= 1000;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
if (delay == 0)
return;
t = DIV_ROUND_UP(delay * spi_clk, (clk_div + 1) * 2);
while (t) {
unsigned int n = min(t, 256U);
spi_engine_program_add_cmd(p, dry, SPI_ENGINE_CMD_SLEEP(n - 1));
t -= n;
}
}
static void spi_engine_gen_cs(struct spi_engine_program *p, bool dry,
struct spi_device *spi, bool assert)
{
unsigned int mask = 0xff;
if (assert)
spi: Replace all spi->chip_select and spi->cs_gpiod references with function call Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select & spi->cs_gpiod and replaced all spi->chip_select and spi->cs_gpiod references with get or set API calls. While adding multi-cs support in further patches the chip_select & cs_gpiod members of the spi_device structure would be converted to arrays & the "idx" parameter of the APIs would be used as array index i.e., spi->chip_select[idx] & spi->cs_gpiod[idx] respectively. Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com> Acked-by: Heiko Stuebner <heiko@sntech.de> # Rockchip drivers Reviewed-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> # Aspeed driver Reviewed-by: Dhruva Gole <d-gole@ti.com> # SPI Cadence QSPI Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> # spi-stm32-qspi Acked-by: William Zhang <william.zhang@broadcom.com> # bcm63xx-hsspi driver Reviewed-by: Serge Semin <fancer.lancer@gmail.com> # DW SSI part Link: https://lore.kernel.org/r/167847070432.26.15076794204368669839@mailman-core.alsa-project.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-11 01:32:03 +08:00
mask ^= BIT(spi_get_chipselect(spi, 0));
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi_engine_program_add_cmd(p, dry, SPI_ENGINE_CMD_ASSERT(1, mask));
}
static int spi_engine_compile_message(struct spi_engine *spi_engine,
struct spi_message *msg, bool dry, struct spi_engine_program *p)
{
struct spi_device *spi = msg->spi;
struct spi_transfer *xfer;
int clk_div, new_clk_div;
bool cs_change = true;
clk_div = -1;
spi_engine_program_add_cmd(p, dry,
SPI_ENGINE_CMD_WRITE(SPI_ENGINE_CMD_REG_CONFIG,
spi_engine_get_config(spi)));
list_for_each_entry(xfer, &msg->transfers, transfer_list) {
new_clk_div = spi_engine_get_clk_div(spi_engine, spi, xfer);
if (new_clk_div != clk_div) {
clk_div = new_clk_div;
spi_engine_program_add_cmd(p, dry,
SPI_ENGINE_CMD_WRITE(SPI_ENGINE_CMD_REG_CLK_DIV,
clk_div));
}
if (cs_change)
spi_engine_gen_cs(p, dry, spi, true);
spi_engine_gen_xfer(p, dry, xfer);
spi: spi-axi: extend support for the `delay` field The AXI SPI engine driver uses the `delay_usecs` field from `spi_transfer` to configure delays, which the controller will execute. This change extends the logic to also include the `delay` value, in case it is used (instead if `delay_usecs`). Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20190926105147.7839-20-alexandru.ardelean@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-26 18:51:47 +08:00
spi_engine_gen_sleep(p, dry, spi_engine, clk_div, xfer);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
cs_change = xfer->cs_change;
if (list_is_last(&xfer->transfer_list, &msg->transfers))
cs_change = !cs_change;
if (cs_change)
spi_engine_gen_cs(p, dry, spi, false);
}
return 0;
}
static void spi_engine_xfer_next(struct spi_engine *spi_engine,
struct spi_transfer **_xfer)
{
struct spi_message *msg = spi_engine->msg;
struct spi_transfer *xfer = *_xfer;
if (!xfer) {
xfer = list_first_entry(&msg->transfers,
struct spi_transfer, transfer_list);
} else if (list_is_last(&xfer->transfer_list, &msg->transfers)) {
xfer = NULL;
} else {
xfer = list_next_entry(xfer, transfer_list);
}
*_xfer = xfer;
}
static void spi_engine_tx_next(struct spi_engine *spi_engine)
{
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
struct spi_engine_message_state *st = spi_engine->msg->state;
struct spi_transfer *xfer = st->tx_xfer;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
do {
spi_engine_xfer_next(spi_engine, &xfer);
} while (xfer && !xfer->tx_buf);
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
st->tx_xfer = xfer;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
if (xfer) {
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
st->tx_length = xfer->len;
st->tx_buf = xfer->tx_buf;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
} else {
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
st->tx_buf = NULL;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
}
}
static void spi_engine_rx_next(struct spi_engine *spi_engine)
{
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
struct spi_engine_message_state *st = spi_engine->msg->state;
struct spi_transfer *xfer = st->rx_xfer;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
do {
spi_engine_xfer_next(spi_engine, &xfer);
} while (xfer && !xfer->rx_buf);
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
st->rx_xfer = xfer;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
if (xfer) {
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
st->rx_length = xfer->len;
st->rx_buf = xfer->rx_buf;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
} else {
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
st->rx_buf = NULL;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
}
}
static bool spi_engine_write_cmd_fifo(struct spi_engine *spi_engine)
{
void __iomem *addr = spi_engine->base + SPI_ENGINE_REG_CMD_FIFO;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
struct spi_engine_message_state *st = spi_engine->msg->state;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
unsigned int n, m, i;
const uint16_t *buf;
n = readl_relaxed(spi_engine->base + SPI_ENGINE_REG_CMD_FIFO_ROOM);
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
while (n && st->cmd_length) {
m = min(n, st->cmd_length);
buf = st->cmd_buf;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
for (i = 0; i < m; i++)
writel_relaxed(buf[i], addr);
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
st->cmd_buf += m;
st->cmd_length -= m;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
n -= m;
}
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
return st->cmd_length != 0;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
}
static bool spi_engine_write_tx_fifo(struct spi_engine *spi_engine)
{
void __iomem *addr = spi_engine->base + SPI_ENGINE_REG_SDO_DATA_FIFO;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
struct spi_engine_message_state *st = spi_engine->msg->state;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
unsigned int n, m, i;
const uint8_t *buf;
n = readl_relaxed(spi_engine->base + SPI_ENGINE_REG_SDO_FIFO_ROOM);
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
while (n && st->tx_length) {
m = min(n, st->tx_length);
buf = st->tx_buf;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
for (i = 0; i < m; i++)
writel_relaxed(buf[i], addr);
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
st->tx_buf += m;
st->tx_length -= m;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
n -= m;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
if (st->tx_length == 0)
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi_engine_tx_next(spi_engine);
}
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
return st->tx_length != 0;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
}
static bool spi_engine_read_rx_fifo(struct spi_engine *spi_engine)
{
void __iomem *addr = spi_engine->base + SPI_ENGINE_REG_SDI_DATA_FIFO;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
struct spi_engine_message_state *st = spi_engine->msg->state;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
unsigned int n, m, i;
uint8_t *buf;
n = readl_relaxed(spi_engine->base + SPI_ENGINE_REG_SDI_FIFO_LEVEL);
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
while (n && st->rx_length) {
m = min(n, st->rx_length);
buf = st->rx_buf;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
for (i = 0; i < m; i++)
buf[i] = readl_relaxed(addr);
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
st->rx_buf += m;
st->rx_length -= m;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
n -= m;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
if (st->rx_length == 0)
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi_engine_rx_next(spi_engine);
}
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
return st->rx_length != 0;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
}
static irqreturn_t spi_engine_irq(int irq, void *devid)
{
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
struct spi_controller *host = devid;
struct spi_engine *spi_engine = spi_controller_get_devdata(host);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
unsigned int disable_int = 0;
unsigned int pending;
pending = readl_relaxed(spi_engine->base + SPI_ENGINE_REG_INT_PENDING);
if (pending & SPI_ENGINE_INT_SYNC) {
writel_relaxed(SPI_ENGINE_INT_SYNC,
spi_engine->base + SPI_ENGINE_REG_INT_PENDING);
spi_engine->completed_id = readl_relaxed(
spi_engine->base + SPI_ENGINE_REG_SYNC_ID);
}
spin_lock(&spi_engine->lock);
if (pending & SPI_ENGINE_INT_CMD_ALMOST_EMPTY) {
if (!spi_engine_write_cmd_fifo(spi_engine))
disable_int |= SPI_ENGINE_INT_CMD_ALMOST_EMPTY;
}
if (pending & SPI_ENGINE_INT_SDO_ALMOST_EMPTY) {
if (!spi_engine_write_tx_fifo(spi_engine))
disable_int |= SPI_ENGINE_INT_SDO_ALMOST_EMPTY;
}
if (pending & (SPI_ENGINE_INT_SDI_ALMOST_FULL | SPI_ENGINE_INT_SYNC)) {
if (!spi_engine_read_rx_fifo(spi_engine))
disable_int |= SPI_ENGINE_INT_SDI_ALMOST_FULL;
}
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
if (pending & SPI_ENGINE_INT_SYNC && spi_engine->msg) {
struct spi_engine_message_state *st = spi_engine->msg->state;
if (spi_engine->completed_id == st->sync_id) {
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
struct spi_message *msg = spi_engine->msg;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
struct spi_engine_message_state *st = msg->state;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
ida_free(&spi_engine->sync_ida, st->sync_id);
kfree(st->p);
kfree(st);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
msg->status = 0;
msg->actual_length = msg->frame_length;
spi_engine->msg = NULL;
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
spi_finalize_current_message(host);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
disable_int |= SPI_ENGINE_INT_SYNC;
}
}
if (disable_int) {
spi_engine->int_enable &= ~disable_int;
writel_relaxed(spi_engine->int_enable,
spi_engine->base + SPI_ENGINE_REG_INT_ENABLE);
}
spin_unlock(&spi_engine->lock);
return IRQ_HANDLED;
}
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
static int spi_engine_transfer_one_message(struct spi_controller *host,
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
struct spi_message *msg)
{
struct spi_engine_program p_dry, *p;
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
struct spi_engine *spi_engine = spi_controller_get_devdata(host);
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
struct spi_engine_message_state *st;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
unsigned int int_enable = 0;
unsigned long flags;
size_t size;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
int ret;
st = kzalloc(sizeof(*st), GFP_KERNEL);
if (!st)
return -ENOMEM;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
p_dry.length = 0;
spi_engine_compile_message(spi_engine, msg, true, &p_dry);
size = sizeof(*p->instructions) * (p_dry.length + 1);
p = kzalloc(sizeof(*p) + size, GFP_KERNEL);
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
if (!p) {
kfree(st);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
return -ENOMEM;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
}
ret = ida_alloc_range(&spi_engine->sync_ida, 0, U8_MAX, GFP_KERNEL);
if (ret < 0) {
kfree(p);
kfree(st);
return ret;
}
st->sync_id = ret;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi_engine_compile_message(spi_engine, msg, false, p);
spin_lock_irqsave(&spi_engine->lock, flags);
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
spi_engine_program_add_cmd(p, false, SPI_ENGINE_CMD_SYNC(st->sync_id));
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
msg->state = st;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi_engine->msg = msg;
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
st->p = p;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
st->cmd_buf = p->instructions;
st->cmd_length = p->length;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
if (spi_engine_write_cmd_fifo(spi_engine))
int_enable |= SPI_ENGINE_INT_CMD_ALMOST_EMPTY;
spi_engine_tx_next(spi_engine);
if (spi_engine_write_tx_fifo(spi_engine))
int_enable |= SPI_ENGINE_INT_SDO_ALMOST_EMPTY;
spi_engine_rx_next(spi_engine);
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
if (st->rx_length != 0)
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
int_enable |= SPI_ENGINE_INT_SDI_ALMOST_FULL;
int_enable |= SPI_ENGINE_INT_SYNC;
writel_relaxed(int_enable,
spi_engine->base + SPI_ENGINE_REG_INT_ENABLE);
spi_engine->int_enable = int_enable;
spin_unlock_irqrestore(&spi_engine->lock, flags);
return 0;
}
static int spi_engine_probe(struct platform_device *pdev)
{
struct spi_engine *spi_engine;
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
struct spi_controller *host;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
unsigned int version;
int irq;
int ret;
irq = platform_get_irq(pdev, 0);
spi: Do not check for 0 return after calling platform_get_irq() It is not possible for platform_get_irq() to return 0. Use the return value from platform_get_irq(). Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> # Link: https://lore.kernel.org/r/20230802093238.975906-1-ruanjinjie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-02 17:32:38 +08:00
if (irq < 0)
return irq;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi: axi-spi-engine: use devm_spi_alloc_host() [ Upstream commit e12cd96e8e93044646fdf4b2c9a1de62cfa01e7c ] This modifies the AXI SPI Engine driver to use devm_spi_alloc_host() instead of spi_alloc_host() to simplify the code a bit. In addition to simplifying the error paths in the probe function, we can also remove spi_controller_get/put() calls in the remove function since devm_spi_alloc_host() sets a flag to no longer decrement the controller reference count in the spi_unregister_controller() function. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-4-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:12:55 +08:00
host = devm_spi_alloc_host(&pdev->dev, sizeof(*spi_engine));
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
if (!host)
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
return -ENOMEM;
spi: axi-spi-engine: simplify driver data allocation [ Upstream commit 9e4ce5220eedea2cc440f3961dec1b5122e815b2 ] This simplifies the private data allocation in the AXI SPI Engine driver by making use of the feature built into the spi_alloc_host() function instead of doing it manually. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-3-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:12:54 +08:00
spi_engine = spi_controller_get_devdata(host);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spin_lock_init(&spi_engine->lock);
spi: axi-spi-engine: move msg state to new struct [ Upstream commit 7f970ecb77b6759d37ee743fc36fc0daba960e75 ] This moves the message state in the AXI SPI Engine driver to a new struct spi_engine_msg_state. Previously, the driver state contained various pointers that pointed to memory owned by a struct spi_message. However, it did not set any of these pointers to NULL when a message was completed. This could lead to use after free bugs. Example of how this could happen: 1. SPI core calls into spi_engine_transfer_one_message() with msg1. 2. Assume something was misconfigured and spi_engine_tx_next() is not called enough times in interrupt callbacks for msg1 such that spi_engine->tx_xfer is never set to NULL before the msg1 completes. 3. SYNC interrupt is received and spi_finalize_current_message() is called for msg1. spi_engine->msg is set to NULL but no other message-specific state is reset. 4. Caller that sent msg1 is notified of the completion and frees msg1 and the associated xfers and tx/rx buffers. 4. SPI core calls into spi_engine_transfer_one_message() with msg2. 5. When spi_engine_tx_next() is called for msg2, spi_engine->tx_xfer is still be pointing to an xfer from msg1, which was already freed. spi_engine_xfer_next() tries to access xfer->transfer_list of one of the freed xfers and we get a segfault or undefined behavior. To avoid issues like this, instead of putting per-message state in the driver state struct, we can make use of the struct spi_message::state field to store a pointer to a new struct spi_engine_msg_state. This way, all of the state that belongs to specific message stays with that message and we don't have to remember to manually reset all aspects of the message state when a message is completed. Rather, a new state is allocated for each message. Most of the changes are just renames where the state is accessed. One place where this wasn't straightforward was the sync_id member. This has been changed to use ida_alloc_range() since we needed to separate the per-message sync_id from the per-controller next available sync_id. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-9-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:13:00 +08:00
ida_init(&spi_engine->sync_ida);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi: spi-axi-spi-engine: Use helper function devm_clk_get_enabled() [ Upstream commit a08199b309f833fd4221ab5ee2391c791fe26385 ] Since commit 7ef9651e9792 ("clk: Provide new devm_clk helpers for prepared and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be replaced by devm_clk_get_enabled() when driver enables (and possibly prepares) the clocks for the whole lifetime of the device. Moreover, it is no longer necessary to unprepare and disable the clocks explicitly. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Li Zetao <lizetao1@huawei.com> Link: https://lore.kernel.org/r/20230823133938.1359106-6-lizetao1@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-23 21:39:18 +08:00
spi_engine->clk = devm_clk_get_enabled(&pdev->dev, "s_axi_aclk");
spi: axi-spi-engine: use devm_spi_alloc_host() [ Upstream commit e12cd96e8e93044646fdf4b2c9a1de62cfa01e7c ] This modifies the AXI SPI Engine driver to use devm_spi_alloc_host() instead of spi_alloc_host() to simplify the code a bit. In addition to simplifying the error paths in the probe function, we can also remove spi_controller_get/put() calls in the remove function since devm_spi_alloc_host() sets a flag to no longer decrement the controller reference count in the spi_unregister_controller() function. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-4-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:12:55 +08:00
if (IS_ERR(spi_engine->clk))
return PTR_ERR(spi_engine->clk);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi: spi-axi-spi-engine: Use helper function devm_clk_get_enabled() [ Upstream commit a08199b309f833fd4221ab5ee2391c791fe26385 ] Since commit 7ef9651e9792 ("clk: Provide new devm_clk helpers for prepared and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be replaced by devm_clk_get_enabled() when driver enables (and possibly prepares) the clocks for the whole lifetime of the device. Moreover, it is no longer necessary to unprepare and disable the clocks explicitly. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Li Zetao <lizetao1@huawei.com> Link: https://lore.kernel.org/r/20230823133938.1359106-6-lizetao1@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-23 21:39:18 +08:00
spi_engine->ref_clk = devm_clk_get_enabled(&pdev->dev, "spi_clk");
spi: axi-spi-engine: use devm_spi_alloc_host() [ Upstream commit e12cd96e8e93044646fdf4b2c9a1de62cfa01e7c ] This modifies the AXI SPI Engine driver to use devm_spi_alloc_host() instead of spi_alloc_host() to simplify the code a bit. In addition to simplifying the error paths in the probe function, we can also remove spi_controller_get/put() calls in the remove function since devm_spi_alloc_host() sets a flag to no longer decrement the controller reference count in the spi_unregister_controller() function. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-4-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:12:55 +08:00
if (IS_ERR(spi_engine->ref_clk))
return PTR_ERR(spi_engine->ref_clk);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi: spi-axi-spi-engine: Access register after clock initialization Move register access after clock initialization. Clock "s_axi_aclk" is needed for register access. Without the clock running AXI bus hangs and causes kernel freeze. Signed-off-by: Rafał Hibner <rafal.hibner@secom.com.pl> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200409155621.12174-1-rafal.hibner@secom.com.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-09 23:56:21 +08:00
spi_engine->base = devm_platform_ioremap_resource(pdev, 0);
spi: axi-spi-engine: use devm_spi_alloc_host() [ Upstream commit e12cd96e8e93044646fdf4b2c9a1de62cfa01e7c ] This modifies the AXI SPI Engine driver to use devm_spi_alloc_host() instead of spi_alloc_host() to simplify the code a bit. In addition to simplifying the error paths in the probe function, we can also remove spi_controller_get/put() calls in the remove function since devm_spi_alloc_host() sets a flag to no longer decrement the controller reference count in the spi_unregister_controller() function. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-4-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:12:55 +08:00
if (IS_ERR(spi_engine->base))
return PTR_ERR(spi_engine->base);
spi: spi-axi-spi-engine: Access register after clock initialization Move register access after clock initialization. Clock "s_axi_aclk" is needed for register access. Without the clock running AXI bus hangs and causes kernel freeze. Signed-off-by: Rafał Hibner <rafal.hibner@secom.com.pl> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200409155621.12174-1-rafal.hibner@secom.com.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-09 23:56:21 +08:00
spi: axi-spi-engine: use common AXI macros [ Upstream commit 88c2b56c2690061121cad03f0f551db465287575 ] This avoid duplicating the same macros in multiple drivers by reusing the common AXI macros for the version register. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240202213132.3863124-2-dlechner@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-03 05:31:32 +08:00
version = readl(spi_engine->base + ADI_AXI_REG_VERSION);
if (ADI_AXI_PCORE_VER_MAJOR(version) != 1) {
spi: axi-spi-engine: fix version format string [ Upstream commit 0064db9ce4aa7cc794e6f4aed60dee0f94fc9bcf ] The version format string in the AXI SPI Engine driver was probably intended to print the version number in the same format as the DT compatible string (e.g. 1.00.a). However, the version just uses semantic versioning so formatting the patch number as a character is not correct and would result in printing control characters for patch numbers less than 32. Fixes: b1353d1c1d45 ("spi: Add Analog Devices AXI SPI Engine controller support") Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20240412-axi-spi-engine-version-printf-v1-1-95e1e842c1a6@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-13 06:52:48 +08:00
dev_err(&pdev->dev, "Unsupported peripheral version %u.%u.%u\n",
spi: axi-spi-engine: use common AXI macros [ Upstream commit 88c2b56c2690061121cad03f0f551db465287575 ] This avoid duplicating the same macros in multiple drivers by reusing the common AXI macros for the version register. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240202213132.3863124-2-dlechner@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-03 05:31:32 +08:00
ADI_AXI_PCORE_VER_MAJOR(version),
ADI_AXI_PCORE_VER_MINOR(version),
ADI_AXI_PCORE_VER_PATCH(version));
spi: axi-spi-engine: use devm_spi_alloc_host() [ Upstream commit e12cd96e8e93044646fdf4b2c9a1de62cfa01e7c ] This modifies the AXI SPI Engine driver to use devm_spi_alloc_host() instead of spi_alloc_host() to simplify the code a bit. In addition to simplifying the error paths in the probe function, we can also remove spi_controller_get/put() calls in the remove function since devm_spi_alloc_host() sets a flag to no longer decrement the controller reference count in the spi_unregister_controller() function. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-4-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:12:55 +08:00
return -ENODEV;
spi: spi-axi-spi-engine: Access register after clock initialization Move register access after clock initialization. Clock "s_axi_aclk" is needed for register access. Without the clock running AXI bus hangs and causes kernel freeze. Signed-off-by: Rafał Hibner <rafal.hibner@secom.com.pl> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Alexandru Ardelean <alexandru.ardelean@analog.com> Link: https://lore.kernel.org/r/20200409155621.12174-1-rafal.hibner@secom.com.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-09 23:56:21 +08:00
}
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
writel_relaxed(0x00, spi_engine->base + SPI_ENGINE_REG_RESET);
writel_relaxed(0xff, spi_engine->base + SPI_ENGINE_REG_INT_PENDING);
writel_relaxed(0x00, spi_engine->base + SPI_ENGINE_REG_INT_ENABLE);
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
ret = request_irq(irq, spi_engine_irq, 0, pdev->name, host);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
if (ret)
spi: axi-spi-engine: use devm_spi_alloc_host() [ Upstream commit e12cd96e8e93044646fdf4b2c9a1de62cfa01e7c ] This modifies the AXI SPI Engine driver to use devm_spi_alloc_host() instead of spi_alloc_host() to simplify the code a bit. In addition to simplifying the error paths in the probe function, we can also remove spi_controller_get/put() calls in the remove function since devm_spi_alloc_host() sets a flag to no longer decrement the controller reference count in the spi_unregister_controller() function. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-4-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:12:55 +08:00
return ret;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
host->dev.of_node = pdev->dev.of_node;
host->mode_bits = SPI_CPOL | SPI_CPHA | SPI_3WIRE;
host->bits_per_word_mask = SPI_BPW_MASK(8);
host->max_speed_hz = clk_get_rate(spi_engine->ref_clk) / 2;
host->transfer_one_message = spi_engine_transfer_one_message;
host->num_chipselect = 8;
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
ret = spi_register_controller(host);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
if (ret)
goto err_free_irq;
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
platform_set_drvdata(pdev, host);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
return 0;
err_free_irq:
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
free_irq(irq, host);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
return ret;
}
spi: axi-spi-engine: Convert to platform remove callback returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230303172041.2103336-9-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-04 01:19:22 +08:00
static void spi_engine_remove(struct platform_device *pdev)
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
{
spi: axi-spi-engine: use devm_spi_alloc_host() [ Upstream commit e12cd96e8e93044646fdf4b2c9a1de62cfa01e7c ] This modifies the AXI SPI Engine driver to use devm_spi_alloc_host() instead of spi_alloc_host() to simplify the code a bit. In addition to simplifying the error paths in the probe function, we can also remove spi_controller_get/put() calls in the remove function since devm_spi_alloc_host() sets a flag to no longer decrement the controller reference count in the spi_unregister_controller() function. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231117-axi-spi-engine-series-1-v1-4-cc59db999b87@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-18 04:12:55 +08:00
struct spi_controller *host = platform_get_drvdata(pdev);
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
struct spi_engine *spi_engine = spi_controller_get_devdata(host);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
int irq = platform_get_irq(pdev, 0);
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
spi_unregister_controller(host);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
spi: spi-axi-spi-engine: switch to use modern name Change legacy name master to modern name host or controller. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-4-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-28 17:32:03 +08:00
free_irq(irq, host);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
writel_relaxed(0xff, spi_engine->base + SPI_ENGINE_REG_INT_PENDING);
writel_relaxed(0x00, spi_engine->base + SPI_ENGINE_REG_INT_ENABLE);
writel_relaxed(0x01, spi_engine->base + SPI_ENGINE_REG_RESET);
}
static const struct of_device_id spi_engine_match_table[] = {
{ .compatible = "adi,axi-spi-engine-1.00.a" },
{ },
};
spi: spi-axi: Fix module autoload If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/spi/spi-axi-spi-engine.ko | grep alias $ After this patch: $ modinfo drivers/spi/spi-axi-spi-engine.ko | grep alias alias: of:N*T*Cadi,axi-spi-engine-1.00.aC* alias: of:N*T*Cadi,axi-spi-engine-1.00.a Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-11-24 00:37:08 +08:00
MODULE_DEVICE_TABLE(of, spi_engine_match_table);
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
static struct platform_driver spi_engine_driver = {
.probe = spi_engine_probe,
spi: axi-spi-engine: Convert to platform remove callback returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230303172041.2103336-9-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-04 01:19:22 +08:00
.remove_new = spi_engine_remove,
spi: Add Analog Devices AXI SPI Engine controller support This patch adds support for the AXI SPI Engine controller which is a FPGA soft-peripheral which is used in some of Analog Devices' reference designs. The AXI SPI Engine controller is part of the SPI Engine framework[1] and allows memory mapped access to the SPI Engine control bus. This allows it to be used as a general purpose software driven SPI controller. The SPI Engine in addition offers some optional advanced acceleration and offloading capabilities, which are not part of this patch though and will be introduced separately. At the core of the SPI Engine framework is a small sort of co-processor that accepts a command stream and turns the commands into low-level SPI transactions. Communication is done through three memory mapped FIFOs in the register map of the AXI SPI Engine peripheral. One FIFO for the command stream and one each for transmit and receive data. The driver translates a spi_message in a command stream and writes it to the peripheral which executes it asynchronously. This allows it to perform very precise timings which are required for some SPI slave devices to achieve maximum performance (e.g. analog-to-digital and digital-to-analog converters). The execution flow is synchronized to the host system by a special synchronize instruction which generates a interrupt. [1] https://wiki.analog.com/resources/fpga/peripherals/spi_engine Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-05 00:13:30 +08:00
.driver = {
.name = "spi-engine",
.of_match_table = spi_engine_match_table,
},
};
module_platform_driver(spi_engine_driver);
MODULE_AUTHOR("Lars-Peter Clausen <lars@metafoo.de>");
MODULE_DESCRIPTION("Analog Devices SPI engine peripheral driver");
MODULE_LICENSE("GPL");