[v3,00/12] spi: s3c64xx: remove OF alias ID dependency

Message

Tudor Ambarus Feb. 16, 2024, 7:05 a.m. UTC

The driver was wrong as it assumed that the alias values in devicetree
have a particular meaning in identifying instances. This immediately
breaks when there is a dtb file that does not use the same alias values,
e.g. because it only needs some of the SPI ports.

Tested gs101 SPI with spi-loopback-test, all went fine. I updated
exynos850 as it uses the same USI.SPI_VERSION as gs101. Maybe Sam can
test exynos850, if not, we can drop that patch (12/12).

v3:
- fix indentation in dt-bindings
- collect Rob's R-b

v2:
- update bindings to consider the asymmetric case where the RX FIFO
  depth can differ from the TX FIFO depth
- update commit message in patch 11/12 to describe the GS101 change
  (I was wrongly mentioning exynos 850). 

Tudor Ambarus (12):
  spi: dt-bindings: introduce FIFO depth properties
  spi: s3c64xx: define a magic value
  spi: s3c64xx: allow full FIFO masks
  spi: s3c64xx: determine the fifo depth only once
  spi: s3c64xx: retrieve the FIFO depth from the device tree
  spi: s3c64xx: allow FIFO depth to be determined from the compatible
  spi: s3c64xx: let the SPI core determine the bus number
  spi: s3c64xx: introduce s3c64xx_spi_set_port_id()
  spi: s3c64xx: get rid of the OF alias ID dependency
  spi: s3c64xx: deprecate fifo_lvl_mask, rx_lvl_offset and port_id
  spi: s3c64xx: switch gs101 to new port config data
  spi: s3c64xx: switch exynos850 to new port config data

 .../bindings/spi/spi-controller.yaml          |  27 ++++
 drivers/spi/spi-s3c64xx.c                     | 142 ++++++++++++++----
 2 files changed, 138 insertions(+), 31 deletions(-)

Comments

Mark Brown March 6, 2024, 2:08 p.m. UTC | #1

On Fri, 16 Feb 2024 07:05:43 +0000, Tudor Ambarus wrote:
> The driver was wrong as it assumed that the alias values in devicetree
> have a particular meaning in identifying instances. This immediately
> breaks when there is a dtb file that does not use the same alias values,
> e.g. because it only needs some of the SPI ports.
> 
> Tested gs101 SPI with spi-loopback-test, all went fine. I updated
> exynos850 as it uses the same USI.SPI_VERSION as gs101. Maybe Sam can
> test exynos850, if not, we can drop that patch (12/12).
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[01/12] spi: dt-bindings: introduce FIFO depth properties
        commit: 80a38bfbbd5965c8bda73b20aa78d308739bbc31
[02/12] spi: s3c64xx: define a magic value
        commit: ff8faa8a5c0f4c2da797cd22a163ee3cc8823b13
[03/12] spi: s3c64xx: allow full FIFO masks
        commit: d6911cf27e5c8491cbfedd4ae2d1ee74a3e685b4
[04/12] spi: s3c64xx: determine the fifo depth only once
        commit: c6e776ab6abdfce5a1edcde7a22c639e76499939
[05/12] spi: s3c64xx: retrieve the FIFO depth from the device tree
        commit: 414d7b8c9147db7dc34c0e2bae2e2361b922dc07
[06/12] spi: s3c64xx: allow FIFO depth to be determined from the compatible
        commit: 82b98fb8cd33db7793e3e695c44e4e75bca03b3e
[07/12] spi: s3c64xx: let the SPI core determine the bus number
        commit: e08433e095dda8b5e44c376648dbf65c6fb6771a
[08/12] spi: s3c64xx: introduce s3c64xx_spi_set_port_id()
        commit: 2cda3623ff4f002877a81f4e7a4c3401fd98aa2d
[09/12] spi: s3c64xx: get rid of the OF alias ID dependency
        commit: ea3fba7c41babda225fea324a72d171be9ff6de6
[10/12] spi: s3c64xx: deprecate fifo_lvl_mask, rx_lvl_offset and port_id
        commit: ad0adac84d42b693295f4bde407d9f20c9a694ab
[11/12] spi: s3c64xx: switch gs101 to new port config data
        commit: e8b16c7a420420a994f68c181abc4a82dcca0616
[12/12] spi: s3c64xx: switch exynos850 to new port config data
        commit: 7ad288208d24e42047e5bf0b88271684a32aa967

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark