Re: [PATCH 5/5] spi: atcspi200: Drop redundant andestech,qilai-spi compatible

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Direct casting and dereferencing of potentially unaligned buffers to 'unsigned int *' causes undefined behavior and unaligned access faults.
--

--- Patch [5]: [PATCH 5/5] spi: atcspi200: Drop redundant andestech,qilai-spi compatible ---
commit 0adcd926abd385a3e807d5c95896eac0c48c12aa
Author: Krzysztof Kozlowski <[email protected]>

spi: atcspi200: Drop redundant andestech,qilai-spi compatible

"andestech,qilai-spi" compatible can only be used with a fallback, which
is already matched by the driver's OF device ID table, thus it is
redundant in the driver.

> diff --git a/drivers/spi/spi-atcspi200.c b/drivers/spi/spi-atcspi200.c
> index b6ea8e5563359..b532c58c0ab91 100644
> --- a/drivers/spi/spi-atcspi200.c
> +++ b/drivers/spi/spi-atcspi200.c

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing this file I
noticed a pre-existing issue that can cause unaligned access faults.

Looking at the transmit path in drivers/spi/spi-atcspi200.c:atcspi_xfer_data_poll():

			if (spi->data_merge)
				val = *(unsigned int *)tx_buf;

And on the receive path in the same function:

			if (spi->data_merge)
				*(unsigned int *)rx_buf = val;

Does this code directly cast and dereference potentially unaligned buffers?

Since spi->data_merge is enabled whenever the transfer size is a multiple
of 4, it appears to ignore the memory alignment of the op->data.buf.out and
op->data.buf.in input/output buffers.

On architectures that do not support hardware unaligned accesses, such as
RISC-V CPUs lacking this feature, could this cause an unaligned access fault
and kernel panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5