Re: [PATCH v5 2/2] can: m_can: add ti,am62-mcan compatible with out-of-band wakeup support

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing rollback in m_can_class_suspend error path leaves device permanently unusable if deinit fails.
--

commit f4778144b1ead7bde54359bb563953cd8601ac93
Author: Kendall Willis <k-willis@ti.com>

can: m_can: add ti,am62-mcan compatible with out-of-band wakeup support

This commit introduces the ti,am62-mcan compatible with match data to
identify the out-of-band wakeup capability for TI AM62 SoCs. It also
updates the suspend path to set the out-of-band wakeup flag when
the device is configured appropriately.

> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 16f80607e150e..67ac6995a7f27 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -2622,8 +2622,14 @@ int m_can_class_suspend(struct device *dev)
>  		cdev->can.state = CAN_STATE_SLEEPING;
>  	}
>  
> -	if (!m_can_class_wakeup_pinctrl_enabled(cdev))
> -		pinctrl_pm_select_sleep_state(dev);
> +	if (!ret) {
> +		if (m_can_class_wakeup_pinctrl_enabled(cdev)) {
> +			if (cdev->out_band_wakeup)
> +				device_set_out_band_wakeup(dev);
> +		} else {
> +			pinctrl_pm_select_sleep_state(dev);
> +		}
> +	}
>  
>  	return ret;
>  }

[Severity: High]
This is a pre-existing issue, but could this error path leave the CAN device
permanently unusable?

If cdev->ops->deinit() returns a negative error code (e.g. due to an SPI
error in a peripheral driver), ret is set, but m_can_class_suspend()
unconditionally stops the clocks and changes the state earlier in the
function:

    if (cdev->pm_wake_source) {
        ...
        if (cdev->ops->deinit)
            ret = cdev->ops->deinit(cdev);
    } else {
        m_can_stop(ndev);
    }

    m_can_clk_stop(cdev);
    cdev->can.state = CAN_STATE_SLEEPING;

If an error is returned to the PM core, the suspend operation is aborted
and the resume callback is never invoked. Does this leave the network
interface detached via netif_device_detach(), its clocks stopped, and the
state stuck in CAN_STATE_SLEEPING indefinitely without a manual module
reload?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912-temp-v5-0-2e3201c02109@ti.com?part=2