[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YgZNCoYeArYTECYC@sirena.org.uk>
Date: Fri, 11 Feb 2022 11:48:26 +0000
From: Mark Brown <broonie@...nel.org>
To: Jon Lin <jon.lin@...k-chips.com>
Cc: heiko@...ech.de, linux-spi@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v10 5/6] spi: rockchip: Support cs-gpio
On Fri, Feb 11, 2022 at 11:43:41AM +0800, Jon Lin wrote:
> 1.Add standard cs-gpio support
> 2.Refer to spi-controller.yaml for details
>
> Signed-off-by: Jon Lin <jon.lin@...k-chips.com>
> ---
>
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
Why is this the one patch in the series with any versioning information?
> - ROCKCHIP_SPI_SET_BITS(rs->regs + ROCKCHIP_SPI_SER,
> - BIT(spi->chip_select));
> + if (spi->cs_gpiod)
> + ROCKCHIP_SPI_SET_BITS(rs->regs + ROCKCHIP_SPI_SER, 1);
> + else
> + ROCKCHIP_SPI_SET_BITS(rs->regs + ROCKCHIP_SPI_SER, BIT(spi->chip_select));
This appears to be making the device control chip select 0 if a GPIO
chip select is used - that's going to work poorly if there's a device
using that chip select. It should be fine to prohibit that
configuration if the hardware requires that a GPIO be controlled,
especially if the native chip select can be pinmuxed to a GPIO, but it
ought to be at least documented that this won't work and ideally
detected.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists