Re: [PATCH RESEND v29 1/4] dt-bindings: i2c: Split AST2600 binding into a new YAML

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The new DT binding breaks validation for existing AST2600 device trees by enforcing a new `reg` layout and removing `bus-frequency`.
- [High] Renaming `bus-frequency` to `clock-frequency` causes a silent performance regression with the legacy i2c-aspeed driver.
--

commit 625f06e7b4752a6769de1b97b793eb2043bda8de
Author: Ryan Chen <ryan_chen@aspeedtech.com>

dt-bindings: i2c: Split AST2600 binding into a new YAML

The AST2600 I2C controller introduces a new register layout with separate
controller and target blocks. The binding for AST2600 is moved to a dedicated
aspeed,ast2600-i2c.yaml schema, updating requirements like enforcing two reg
regions and using clock-frequency instead of bus-frequency.

> diff --git a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> new file mode 100644
> index 0000000000000..de2c359037da5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
[ ... ]
> +properties:
> +  compatible:
> +    enum:
> +      - aspeed,ast2600-i2c-bus
> +
> +  reg:
> +    items:
> +      - description: controller registers
> +      - description: controller buffer space

Will enforcing this new reg layout break validation for existing AST2600
device trees?

Existing in-tree device trees define a single reg region. Because these device
trees are not updated in this patch series, make dtbs_check will fail for all
AST2600 boards.

Should the binding retain backward compatibility by allowing a single reg
region for legacy nodes?

[ ... ]
> +  clock-frequency:
> +    description: Desired operating frequency of the I2C bus in Hz.
> +    minimum: 500
> +    maximum: 4000000
> +    default: 100000
> +
> +  resets:
> +    maxItems: 1
> +
> +required:
> +  - reg
> +  - compatible
> +  - clocks
> +  - resets
> +  - interrupts
> +
> +unevaluatedProperties: false

Could renaming bus-frequency to clock-frequency cause a silent performance
regression with the legacy i2c-aspeed driver?

If a device tree is updated to conform to this new binding (by replacing
bus-frequency with clock-frequency) but does not add the aspeed,global-regs
property, the legacy i2c-aspeed.c driver will still probe.

The legacy driver relies entirely on bus-frequency and does not use standard
helpers like i2c_parse_fw_timings() to read clock-frequency.

This will cause the driver to fail to find the bus frequency property, log
an error, and silently fall back to the default 100kHz, which will degrade
performance for fast-mode devices.

Additionally, because the binding sets unevaluatedProperties to false and
removes bus-frequency, existing device trees that still use bus-frequency
will fail validation.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513-upstream_i2c-v29-0-fe9926964d55@aspeedtech.com?part=1