Re: [PATCH v10 03/19] spi: parse spi-max-post-config-frequency-hz into post_config_max_speed_hz

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] spi: missing bounds check for post_config_max_speed_hz
- [Medium] spi: missing propagation of post_config_max_speed_hz to non-DT instantiations
- [Medium] spi: proxy and ancillary devices drop post_config_max_speed_hz
--

commit a54a647ebbac4cf4a270dd8915b629161a216725
Author: Santhosh Kumar K <s-k6@ti.com>
Subject: spi: parse spi-max-post-config-frequency-hz into post_config_max_speed_hz

This patch adds post_config_max_speed_hz to struct spi_device and parses
it from the spi-max-post-config-frequency-hz device tree property. This
supports SPI devices that operate at a conservative rate before
configuration and a higher rate after controller-side configuration.

> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 015d93680e5d0..97bf58dacd06d 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -2809,6 +2809,8 @@ static int of_spi_parse_dt(struct spi_controller *ctlr, struct spi_device *spi,
>  	/* Device speed */
>  	if (!of_property_read_u32(nc, "spi-max-frequency", &value))
>  		spi->max_speed_hz = value;
> +	if (!of_property_read_u32(nc, "spi-max-post-config-frequency-hz", &value))
> +		spi->post_config_max_speed_hz = value;

[Severity: Medium]
Does limiting this new property to device tree via of_property_read_u32()
prevent ACPI and software nodes from using it? The core pattern usually
relies on device_property_read_u32() in __spi_add_device() to support
these automatically.

Also, should spi_board_info be updated to propagate this configuration to
non-DT SPI instantiations? Currently, spi_new_device() maps fields from
spi_board_info to spi_device like this:

drivers/spi/spi.c:spi_new_device() {
    ...
    proxy->max_speed_hz = chip->max_speed_hz;
    proxy->mode = chip->mode;
    proxy->irq = chip->irq;
    ...
}

Does this omission mean devices instantiated via spi_register_board_info()
or ACPI cannot configure post-configuration high-speed capabilities?

[Severity: High]
Is a bounds check needed for post_config_max_speed_hz against the
controller's maximum speed? In __spi_setup(), spi->max_speed_hz is correctly
capped:

drivers/spi/spi.c:__spi_setup() {
    ...
    if (spi->controller->max_speed_hz &&
        (!spi->max_speed_hz ||
         spi->max_speed_hz > spi->controller->max_speed_hz))
        spi->max_speed_hz = spi->controller->max_speed_hz;
    ...
}

Without a similar check for post_config_max_speed_hz, could a device tree
misconfiguration instruct the SPI controller to drive a clock frequency
exceeding its physical hardware limits, potentially leading to invalid
divider calculations or hardware lockups?

[Severity: Medium]
Should post_config_max_speed_hz also be propagated to proxy and ancillary
devices? When an ancillary device is created, max_speed_hz and mode are
copied, but post_config_max_speed_hz is omitted:

drivers/spi/spi.c:spi_new_ancillary_device() {
    ...
    ancillary->max_speed_hz = spi->max_speed_hz;
    ancillary->mode = spi->mode;
    ...
}

Similarly, in drivers/spi/spi-mux.c, the child device's settings are copied
to the multiplexed proxy device:

drivers/spi/spi-mux.c:spi_mux_select() {
    ...
    priv->spi->max_speed_hz = spi->max_speed_hz;
    priv->spi->mode = spi->mode;
    priv->spi->bits_per_word = spi->bits_per_word;
    ...
}

Will this omission silently break the ability of multiplexed or ancillary
devices to use PHY tuning and high-speed post-config rates?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260929063529.1235417-1-s-k6@ti.com?part=3