linux-kernel - Re: [PATCH RFC 0/2] Add target mode support for the DesignWare SPI controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <176053044486.105519.3995515775023859907.b4-ty@kernel.org>
Date: Wed, 15 Oct 2025 13:14:04 +0100
From: Mark Brown <broonie@...nel.org>
To: Benoît Monin <benoit.monin@...tlin.com>
Cc: Thomas Petazzoni <thomas.petazzoni@...tlin.com>, 
 Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>, 
 Tawfik Bayouk <tawfik.bayouk@...ileye.com>, linux-spi@...r.kernel.org, 
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/2] Add target mode support for the DesignWare SPI
 controller

On Thu, 02 Oct 2025 14:14:36 +0200, Benoît Monin wrote:
> The DesignWare SPI controller can act as a host or a target; the
> choice between the two is set in hardware and cannot be changed by
> software. When configured in target mode, the controller has a much
> reduced set of capabilities. It only has a single chip-select input and
> can only run standard SPI mode (no dual, quad, or octal mode). Despite
> this, the overall logic of doing an SPI transfer and the register layout
> is identical between both modes, so implementing the target mode reuses
> much of the existing code.
> 
> [...]

Applied to

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

Thanks!

[1/2] spi: dw: rename the spi controller to ctlr
      commit: b926b15547d29a88932de3c24a05c12826fc1dbc
[2/2] spi: dw: add target mode support
      commit: fe8cc44dd173cde5788ab4e3730ac61f3d316d9c

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