[PATCH] dt-bindings: i3c: dw: Document missing optional core reset

[sashiko-bot at kernel.org]

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

Pre-existing issues:
- [High] The dt-binding specifies the APB clock name as 'apb', but the driver attempts to fetch it using the name 'pclk'.
- [High] Mixing devm_clk_get_enabled() with manual runtime PM clock toggling causes unbalanced clock disables.
--

--- Patch [1]: [PATCH] dt-bindings: i3c: dw: Document missing optional core reset ---
commit 3d9cd37483dab62bf65ce3e70bf1ff17d3bd87d7
Author: Shubham Patil <shubhamsanjay.patil at amd.com>

dt-bindings: i3c: dw: Document missing optional core reset

The DesignWare I3C master IP supports a core reset input, but the
binding is missing the corresponding reset description. Document the
reset property and name in the binding. Keep the reset optional because
the reset line is integration-specific.

> diff --git a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml
> index e803457d3f554..822faf8d221b8 100644
> --- a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml
> +++ b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml
> @@ -38,6 +38,12 @@ properties:
>    interrupts:
>      maxItems: 1
>  

[Severity: High]
This is a pre-existing issue, but I noticed a potential mismatch between the
DT binding and the driver for the APB clock while reviewing this file.

The binding enforces the name 'apb':

Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml:
      - const: apb

However, the driver requests it by the name 'pclk':

drivers/i3c/master/dw-i3c-master.c:dw_i3c_common_probe() {
    ...
    master->pclk = devm_clk_get_optional_enabled(&pdev->dev, "pclk");
    ...
}

If a device tree is created strictly following the binding using clock-names =
"core", "apb", won't dw_i3c_common_probe() fail to find the "pclk" clock?

Since it is requested as optional, the probe will succeed but subsequent
register accesses will occur without the APB clock enabled. Could this lead to
a synchronous external abort or system freeze during operation?

> +  resets:
> +    maxItems: 1
> +
> +  reset-names:
> +    const: core_rst
> +
>    power-domains:
>      maxItems: 1

[Severity: High]
This is also a pre-existing issue, but I noticed a potential runtime PM
imbalance with how the clocks are handled in the driver.

The clocks are acquired using devres, which ties enablement strictly to the
device lifecycle:

drivers/i3c/master/dw-i3c-master.c:dw_i3c_common_probe() {
    ...
    master->core_clk = devm_clk_get_enabled(&pdev->dev, NULL);
    ...
    master->pclk = devm_clk_get_optional_enabled(&pdev->dev, "pclk");
    ...
}

However, they are manually disabled during runtime suspend:

drivers/i3c/master/dw-i3c-master.c:dw_i3c_master_runtime_suspend() {
    ...
    dw_i3c_master_disable_clks(master);
    ...
}

And runtime PM is disabled on removal without waking the device:

drivers/i3c/master/dw-i3c-master.c:dw_i3c_common_remove() {
    ...
    pm_runtime_disable(master->dev);
    ...
}

If the driver is unbound via sysfs while the device is idle in runtime suspend,
the clocks remain disabled. When the devres actions fire during cleanup, won't
they attempt to disable the clocks a second time?

Could this unbalanced clock disable turn off a shared clock and affect other
active peripherals?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717105829.567522-1-shubhamsanjay.patil@amd.com?part=1