Re: [PATCH v2 32/78] drm/bridge: ssd2825: Switch to atomic_create_state

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Stack-allocated buffers are used for SPI transfers, leading to potential stack memory corruption if the SPI controller maps them for DMA.
--

commit d2236b7da6130a7a64f424b8a7d39ff467bd42ef
Author: Maxime Ripard <mripard@kernel.org>

drm/bridge: ssd2825: Switch to atomic_create_state

The drm_bridge_funcs.atomic_reset callback and its
drm_atomic_helper_bridge_reset() helper are deprecated.

Switch to the atomic_create_state callback and its
drm_atomic_helper_bridge_create_state() counterpart.

> diff --git a/drivers/gpu/drm/bridge/ssd2825.c b/drivers/gpu/drm/bridge/ssd2825.c
> index 91f1510fc2d40..e345f3a652c2e 100644
> --- a/drivers/gpu/drm/bridge/ssd2825.c
> +++ b/drivers/gpu/drm/bridge/ssd2825.c
> @@ -680,7 +680,7 @@ static const struct drm_bridge_funcs ssd2825_bridge_funcs = {
>  	.atomic_enable = ssd2825_bridge_atomic_enable,
>  	.atomic_disable = ssd2825_bridge_atomic_disable,
>  
> -	.atomic_reset = drm_atomic_helper_bridge_reset,
> +	.atomic_create_state = drm_atomic_helper_bridge_create_state,
>  	.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,

[Severity: High]
This isn't a bug introduced by this patch, but I noticed that
ssd2825_write_raw() and ssd2825_read_raw() use stack-allocated buffers for SPI
transfers.

If the underlying SPI controller supports DMA, these buffers will be mapped via
the DMA API. Since stack variables are not guaranteed to be cacheline-aligned,
DMA cache maintenance operations might corrupt adjacent stack frames, return
addresses, or local variables.

In drivers/gpu/drm/bridge/ssd2825.c:ssd2825_write_raw():

        u8 tx_buf[2];
        ...
        tx_buf[0] = low_byte;
        tx_buf[1] = high_byte;

        return spi_write(spi, tx_buf, 2);

And in drivers/gpu/drm/bridge/ssd2825.c:ssd2825_read_raw():

        u8 tx_buf[2];
        u8 rx_buf[2];
        ...
        ret = spi_sync(spi, &msg);

Could these stack allocations cause unpredictable memory corruption or panics
if a DMA-capable SPI controller maps them?

>  	.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608-drm-no-more-bridge-reset-v2-0-0a91018bf886@kernel.org?part=32