The kernel test robot reported a compile-time error regarding the
FIELD_PREP() value being too large for the TRANS_DUAL_QUAD field:

  error: FIELD_PREP: value too large for the field
  note: in expansion of macro 'TRANS_DUAL_QUAD'
  tc |= TRANS_DUAL_QUAD(ffs(op->data.buswidth) - 1);

This occurs because TRANS_DUAL_QUAD is defined as a 2-bit field, and
GCC's static analysis cannot deduce that `ffs(op->data.buswidth) - 1`
will strictly fall within the 0~3 range. Although the SPI framework
guarantees that `op->data.buswidth` is valid at runtime (e.g., 1, 2,
4, 8), an explicit bounds check is necessary to satisfy the compiler.

To resolve the build warning, introduce a safe fallback mechanism.
If an unexpected buswidth is encountered, the driver will trigger
a WARN_ON_ONCE to leave a trace and fall back to width_code = 0
(standard 1-bit SPI mode). This approach guarantees predictable
hardware behavior.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202602140738.P7ZozxzI-lkp@intel.com/
Suggested-by: Pei Xiao <xiaopei01@kylinos.cn>
Signed-off-by: CL Wang <cl634@andestech.com>
---
 drivers/spi/spi-atcspi200.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-atcspi200.c b/drivers/spi/spi-atcspi200.c
index 2075058387f3..709d81475b68 100644
--- a/drivers/spi/spi-atcspi200.c
+++ b/drivers/spi/spi-atcspi200.c
@@ -195,7 +195,15 @@ static void atcspi_set_trans_ctl(struct atcspi_dev *spi,
 	if (op->addr.buswidth > 1)
 		tc |= TRANS_ADDR_FMT;
 	if (op->data.nbytes) {
-		tc |= TRANS_DUAL_QUAD(ffs(op->data.buswidth) - 1);
+		unsigned int width_code;
+
+		width_code = ffs(op->data.buswidth) - 1;
+		if (unlikely(width_code > 3)) {
+			WARN_ON_ONCE(1);
+			width_code = 0;
+		}
+		tc |= TRANS_DUAL_QUAD(width_code);
+
 		if (op->data.dir == SPI_MEM_DATA_IN) {
 			if (op->dummy.nbytes)
 				tc |= TRANS_MODE_DMY_READ |
-- 
2.34.1

On Tue, 03 Mar 2026 10:47:37 +0800, CL Wang wrote:
> spi: atcspi200: Handle invalid buswidth and fix compiler warning

Applied to

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

Thanks!

[1/1] spi: atcspi200: Handle invalid buswidth and fix compiler warning
      https://git.kernel.org/broonie/misc/c/f879365c5bb2

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

On Tue, 03 Mar 2026 10:47:37 +0800, CL Wang wrote:
> The kernel test robot reported a compile-time error regarding the
> FIELD_PREP() value being too large for the TRANS_DUAL_QUAD field:
> 
>   error: FIELD_PREP: value too large for the field
>   note: in expansion of macro 'TRANS_DUAL_QUAD'
>   tc |= TRANS_DUAL_QUAD(ffs(op->data.buswidth) - 1);
> 
> [...]

Applied to

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

Thanks!

[1/1] spi: atcspi200: Handle invalid buswidth and fix compiler warning
      commit: f879365c5bb210ed0d0b0aae1a0202d0c0b4b9d0

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