Re: [PATCH] dt-bindings: net: can: bosch,cc770: Convert to DT schema

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] platform_get_irq() error code is shadowed.
- [High] Incorrect check of uninitialized field priv->cpu_interface instead of pdata->cir.
--

commit 534a229fcad73012a922f469773dd3f6d658bb9e
Author: Quchaosheng <quchaosheng000406@163.com>

dt-bindings: net: can: bosch,cc770: Convert to DT schema

This commit converts the Bosch CC770 and Intel AN82527 controller binding from
free-form text to DT schema. It also references the common can-controller.yaml
schema and documents additional properties used by the driver.

> diff --git a/Documentation/devicetree/bindings/net/can/bosch,cc770.yaml b/Documentation/devicetree/bindings/net/can/bosch,cc770.yaml
> new file mode 100644
> index 0000000000000..448d5b4f74b57
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/can/bosch,cc770.yaml
> @@ -0,0 +1,109 @@
[ ... ]
> +properties:
> +  compatible:
> +    enum:
> +      - bosch,cc770
> +      - intc,82527

[Severity: High]
This is a pre-existing issue, but while looking at the platform data
initialization for this controller, I noticed that the clock divider logic
seems to check an uninitialized field.

In drivers/net/can/cc770/cc770_platform.c:cc770_get_platform_data():

	priv->can.clock.freq = pdata->osc_freq;
	if (priv->cpu_interface & CPUIF_DSC)
		priv->can.clock.freq /= 2;
	priv->clkout = pdata->cor;
	priv->bus_config = pdata->bcr;
	priv->cpu_interface = pdata->cir;

Since priv->cpu_interface is assigned pdata->cir after the check, is
priv->cpu_interface unconditionally 0 here due to the zero-initialization
during allocation? If so, will this prevent the frequency from being correctly
halved when CPUIF_DSC is set in the platform data?

[ ... ]
> +  reg:
> +    description:
> +      Register window of the controller. On a PowerPC system the controller
> +      sits on the local bus and the property describes the chip select, the
> +      address offset and the size, the size usually being 0x80.
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the interrupt
handling property, I noticed the driver shadows the error code during probe.

In drivers/net/can/cc770/cc770_platform.c:cc770_platform_probe():

	irq = platform_get_irq(pdev, 0);
	if (!mem || irq <= 0)
		return -ENODEV;

If platform_get_irq() returns a negative error code such as -EPROBE_DEFER,
the function unconditionally returns -ENODEV instead of the actual error.
Could this permanently prevent the device from probing if its interrupt
controller is initialized after the CC770 driver?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914030215.437602-1-quchaosheng000406@163.com?part=1