[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21d3314355b43ecd6acc42f9dfedec501418332d.camel@gmail.com>
Date: Wed, 05 Jun 2024 11:14:33 +0200
From: Nuno Sá <noname.nuno@...il.com>
To: Marcelo Schmitt <marcelo.schmitt@...log.com>, broonie@...nel.org,
lars@...afoo.de, Michael.Hennerich@...log.com, jic23@...nel.org,
robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
nuno.sa@...log.com, dlechner@...libre.com, marcelo.schmitt1@...il.com
Cc: linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/6] spi: Add SPI mode bit for MOSI idle state
configuration
On Tue, 2024-06-04 at 19:41 -0300, Marcelo Schmitt wrote:
> The behavior of an SPI controller data output line (SDO or MOSI or COPI
> (Controller Output Peripheral Input) for disambiguation) is not specified
> when the controller is not clocking out data on SCLK edges. However, there
> exist SPI peripherals that require specific COPI line state when data is
> not being clocked out of the controller.
> Add SPI mode bit to allow pheripherals to request explicit COPI idle
> behavior when needed.
>
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@...log.com>
> ---
> drivers/spi/spi.c | 6 ++++++
> include/uapi/linux/spi/spi.h | 3 ++-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 289feccca376..6072b6e93bef 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -3921,6 +3921,12 @@ int spi_setup(struct spi_device *spi)
> (SPI_TX_DUAL | SPI_TX_QUAD | SPI_TX_OCTAL |
> SPI_RX_DUAL | SPI_RX_QUAD | SPI_RX_OCTAL)))
> return -EINVAL;
> + /* Check against conflicting MOSI idle configuration */
> + if ((spi->mode & SPI_MOSI_IDLE_LOW) && (spi->mode &
> SPI_MOSI_IDLE_HIGH)) {
> + dev_warn(&spi->dev,
> + "setup: erratic MOSI idle configuration. Set to idle
> low\n");
> + spi->mode &= ~SPI_MOSI_IDLE_HIGH;
> + }
Should we assume such a thing? IOW, should this be treated as a warning or a
real error? I would assume this should be a configuration error and return -
EINVAL but...
- Nuno Sá
Powered by blists - more mailing lists