mbox series

[RESEND,v4,0/4] spi: dw: Auto-detect number of native CS

Message ID 20240424150657.9678-1-fancer.lancer@gmail.com
Headers show
Series spi: dw: Auto-detect number of native CS | expand

Message

Serge Semin April 24, 2024, 3:06 p.m. UTC 
The main goal of the short series is to provide a procedure implementing
the auto-detection of the number of native Chip-Select signals supported
by the controller. The suggested algorithm is straightforward. It relies
on the fact that the SER register writable flags reflects the actual
number of available native chip-select signals. So the DW APB/AHB SSI
driver now tests the SER register for having the writable bits,
calculates the number of CS signals based on the number of set flags and
then initializes the num_cs private data field based on that, which then
will be passed to the SPI-core subsystem indicating the number of
supported hardware chip-selects. The implemented procedure will be useful
for the DW SSI device nodes not having the explicitly set "num-cs"
property. In case if the property is specified it will be utilized instead
of the auto-detection procedure.

Besides of that a small cleanup patch is introduced in the head of the
series. It converts the driver to using the BITS_TO_BYTES() macro instead
of the hard-coded DIV_ROUND_UP()-based calculation of the number of
bytes-per-transfer-word.

Link: https://lore.kernel.org/linux-spi/20240215180102.13887-1-fancer.lancer@gmail.com
Changelog v2:
- Add a new patch:
  [PATCH v2 3/4] spi: dw: Convert dw_spi::num_cs to u32
- Fix some spelling notes (@Andy).

Link: https://lore.kernel.org/linux-spi/20240222172853.25082-1-fancer.lancer@gmail.com
Changelog v3:
- Add Andy' Rb tag.
- Rebase onto the kernel v6.9 and resubmit.

Link: https://lore.kernel.org/linux-spi/20240416155257.22429-1-fancer.lancer@gmail.com
Changelog v4:
- Just resend.

Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: linux-spi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Serge Semin (4):
  spi: dw: Convert to using BITS_TO_BYTES() macro
  spi: dw: Add a number of native CS auto-detection
  spi: dw: Convert dw_spi::num_cs to u32
  spi: dw: Drop default number of CS setting

 drivers/spi/spi-dw-core.c | 20 ++++++++++++++++----
 drivers/spi/spi-dw-mmio.c |  8 ++------
 drivers/spi/spi-dw.h      |  2 +-
 3 files changed, 19 insertions(+), 11 deletions(-)

Comments

Mark Brown May 6, 2024, 2:59 p.m. UTC | #1 
On Wed, 24 Apr 2024 18:06:41 +0300, Serge Semin wrote:
> The main goal of the short series is to provide a procedure implementing
> the auto-detection of the number of native Chip-Select signals supported
> by the controller. The suggested algorithm is straightforward. It relies
> on the fact that the SER register writable flags reflects the actual
> number of available native chip-select signals. So the DW APB/AHB SSI
> driver now tests the SER register for having the writable bits,
> calculates the number of CS signals based on the number of set flags and
> then initializes the num_cs private data field based on that, which then
> will be passed to the SPI-core subsystem indicating the number of
> supported hardware chip-selects. The implemented procedure will be useful
> for the DW SSI device nodes not having the explicitly set "num-cs"
> property. In case if the property is specified it will be utilized instead
> of the auto-detection procedure.
> 
> [...]

Applied to

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

Thanks!

[1/4] spi: dw: Convert to using BITS_TO_BYTES() macro
      commit: 11ae2e63b2a517742d233c4e5b67b898c797973e
[2/4] spi: dw: Add a number of native CS auto-detection
      commit: e164be7e1e9373bd10e6b79924b0a6374752775e
[3/4] spi: dw: Convert dw_spi::num_cs to u32
      commit: 33c85972d1e4952a8c93ec260be2e6ff4470e619
[4/4] spi: dw: Drop default number of CS setting
      commit: 98d75b9ef282f6b9bfa1ea06d8a0824e0edaea97

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