Re: [PATCH 1/4] dt-bindings: crypto: rockchip: Add RK356x/RK3588 crypto engine binding

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Shared interrupt is registered before hardware clocks are enabled and driver structures are initialized, risking an unhandled bus fault.
- [Low] The device tree example fails to compile with `dtc` and `dt_binding_check` due to undefined SCMI macros.
- [Low] The device tree example will fail validation in `dt_binding_check` due to a mismatch between the `reg` property length and the default `#address-cells`/`#size-cells`.
--

commit e90ad76061a5abfb6bd1bbdaa25b14862d6be7d3
Author: Dawid Olesinski <dawidro@gmail.com>

dt-bindings: crypto: rockchip: Add RK356x/RK3588 crypto engine binding

Add a YAML device tree binding for the Rockchip second-generation (V2)
cryptographic hardware accelerator present on the RK3568 and RK3588 SoCs.

> diff --git a/Documentation/devicetree/bindings/crypto/rockchip,rk3588-crypto.yaml b/Documentation/devicetree/bindings/crypto/rockchip,rk3588-crypto.yaml
> new file mode 100644
> index 0000000000000..4188ed8920db9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/rockchip,rk3588-crypto.yaml

[ ... ]

> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +    crypto@fe370000 {
> +        compatible = "rockchip,rk3588-crypto";
> +        reg = <0x0 0xfe370000 0x0 0x2000>;

[Severity: Low]
Does this node need to be wrapped in a parent block that specifies
#address-cells = <2> and #size-cells = <2>?

Since this node is at the top level of the example, dt_binding_check defaults
both properties to 1, which causes a length mismatch with this 4-cell reg
property. This will trigger a dtc invalid length warning and cause
dt-validate to fail.

> +        interrupts = <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH 0>;
> +        clocks = <&scmi_clk SCMI_CRYPTO_CORE>,
> +                 <&scmi_clk SCMI_ACLK_SECURE_NS>,
> +                 <&scmi_clk SCMI_HCLK_SECURE_NS>;

[Severity: Low]
Are the SCMI clock macros defined anywhere in this example?

It looks like the #include directives for the SCMI headers (e.g.,
<dt-bindings/clock/rockchip,rk3588-cru.h>) are missing. During
make dt_binding_check, these macros are left unexpanded, resulting in dtc
syntax errors because bare strings are invalid inside a < > array.

> +        clock-names = "core", "aclk", "hclk";
> +        resets = <&scmi_reset SCMI_SRST_CRYPTO_CORE>;

[Severity: Low]
Are the SCMI reset macros defined anywhere in this example?

Similar to the clocks property, the reset macro #include is missing
(e.g., <dt-bindings/reset/rockchip,rk3588-cru.h>), which will cause
dtc and dt_binding_check to fail.

> +        reset-names = "core";
> +    };

[ ... ]

Also, looking at the driver code added later in this patch series:

> diff --git a/drivers/crypto/rockchip/rk2_crypto.c b/drivers/crypto/rockchip/rk2_crypto.c
> new file mode 100644
> index 0000000000000..df7dab4d7ca0b
> --- /dev/null
> +++ b/drivers/crypto/rockchip/rk2_crypto.c

[ ... ]

> +static int rk2_crypto_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct rk2_crypto_dev *rkc;
> +	int err = 0;

[ ... ]

> +	err = devm_request_irq(dev, rkc->irq,
> +			       rk2_crypto_irq_handle, IRQF_SHARED,
> +			       "rk-crypto", pdev);
> +
> +	if (err) {
> +		err = dev_err_probe(dev, err, "irq request failed.\n");
> +		goto err_dma;
> +	}
> +
> +	rkc->engine = crypto_engine_alloc_init(dev, true);
> +	if (!rkc->engine) {
> +		err = -ENOMEM;
> +		goto err_dma;
> +	}
> +
> +	err = crypto_engine_start(rkc->engine);
> +	if (err) {
> +		err = dev_err_probe(dev, err, "Failed to start crypto engine\n");
> +		goto err_engine;
> +	}
> +
> +	init_completion(&rkc->complete);
> +
> +	err = rk2_crypto_pm_init(rkc);
> +	if (err) {
> +		err = dev_err_probe(dev, err, "Failed to initialize runtime PM\n");
> +		goto err_engine;
> +	}
> +
> +	err = pm_runtime_resume_and_get(dev);

[Severity: High]
Is it safe to request the shared IRQ before the hardware clocks are enabled
and rkc->complete is initialized?

If another device sharing this IRQ triggers an interrupt during this window,
rk2_crypto_irq_handle() could be invoked. Reading RK2_CRYPTO_DMA_INT_ST
without clocks enabled would trigger a synchronous external abort (bus fault),
leading to a kernel panic. It would also attempt to call complete() on an
uninitialized structure.

[ ... ]

> +static void rk2_crypto_remove(struct platform_device *pdev)
> +{
> +	struct rk2_crypto_dev *rkc = platform_get_drvdata(pdev);
> +
> +	/* Stop engine to prevent new requests */
> +	crypto_engine_stop(rkc->engine);
> +
> +	/* Unregister algorithms for this specific device */
> +	rk2_crypto_unregister(rkc);
> +
> +#ifdef CONFIG_CRYPTO_DEV_ROCKCHIP2_DEBUG
> +	debugfs_remove_recursive(rkc->dbgfs_dir);
> +#endif
> +
> +	/* Safe to kill the engine completely */
> +	crypto_engine_exit(rkc->engine);
> +
> +	rk2_crypto_pm_exit(rkc);
> +	dma_free_coherent(rkc->dev, sizeof(struct rk2_crypto_lli) * MAX_LLI,
> +			  rkc->tl, rkc->t_phy);
> +}

[Severity: High]
Can rk2_crypto_pm_exit(rkc) disable runtime PM (gating clocks) while the
devres-managed shared IRQ is still active?

This would reopen the bus fault window during module unload, as the IRQ is
not freed until devres cleanup occurs after rk2_crypto_remove() returns.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260530160704.3453555-1-dawidro@gmail.com?part=1