Re: [PATCH v4 4/7] dtc: dt-check-style: Expect first device_type

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Low] The `compatible` string in the YAML example does not match the schema constraint.
- [Low] Copy-paste error in the comment of the 'good' test fixture.
- [Low] The docstring for `_property_bucket` missed an update for the new `device_type` fixed slot.
--

--- Patch [4]: [PATCH v4 4/7] dtc: dt-check-style: Expect first device_type ---
commit c078538281e29a1c935623ba80b1e47b07008331
Author: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

dtc: dt-check-style: Expect first device_type

Adjust the DTS coding style rules to expect the device_type property first
and improve the dt-check-style script to handle this correctly, along with
new test fixtures.

> diff --git a/scripts/dtc/dt-check-style b/scripts/dtc/dt-check-style
> index bb9ec5b82319e..23cdfe78b1890 100755
> --- a/scripts/dtc/dt-check-style
> +++ b/scripts/dtc/dt-check-style
> @@ -558,28 +558,31 @@ def check_child_name_order(ctx):
>  
>  def _property_bucket(name):
>      """Return the canonical bucket index for a property:
> -       0 compatible
> -       1 reg / reg-names
> -       2 ranges
> -       3 standard properties (no vendor comma in #-stripped name)
> -       4 vendor-specific properties
> -       5 status
> +       0 device_type
> +       1 compatible
> +       2 reg / reg-names
> +       3 ranges
> +       4 standard properties (no vendor comma in #-stripped name)
> +       5 vendor-specific properties
> +       6 status
>      Plus a sub-key inside the bucket for fixed slots (compatible, reg,
>      reg-names, ranges, status). 'standard' and 'vendor' return None for

[Severity: Low]
This isn't a bug, but should device_type be added to the list of fixed slots
in this parenthetical?

>      the sub-key, signalling that the within-bucket key is computed by

[ ... ]

> diff --git a/scripts/dtc/dt-style-selftest/bad/yaml-prop-order-device-type.yaml b/scripts/dtc/dt-style-selftest/bad/yaml-prop-order-device-type.yaml
> new file mode 100644
> index 0000000000000..433afb731dded
> --- /dev/null
> +++ b/scripts/dtc/dt-style-selftest/bad/yaml-prop-order-device-type.yaml
> @@ -0,0 +1,31 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/test-bad-prop-order.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Test fixture with device_type
> +
> +maintainers:
> +  - Test User <test@example.com>
> +
> +properties:
> +  compatible:
> +    const: example,test-prop-order-device-type
> +  reg:
> +    maxItems: 1
> +  device_type: true
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    device@1000 {
> +        compatible = "example,test-prop-order";

[Severity: Low]
The compatible string used here in the example doesn't match the const
requirement defined in properties.compatible above. Will this cause the test
fixture to fail standard dtschema validation if it's ever checked directly?

> +        device_type = "cpu";
> +        reg = <0x1000 0x100>;
> +    };

[ ... ]

> diff --git a/scripts/dtc/dt-style-selftest/good/dts-property-order.dts b/scripts/dtc/dt-style-selftest/good/dts-property-order.dts
> new file mode 100644
> index 0000000000000..0e183e3459cdf
> --- /dev/null
> +++ b/scripts/dtc/dt-style-selftest/good/dts-property-order.dts
> @@ -0,0 +1,41 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +/*
> + * Test fixture: Incorrect property order

[Severity: Low]
This isn't a bug, but since this is the "good" dts file, should this header
comment be updated to indicate it is testing correct property order?

> + */
> +
> +/dts-v1/;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-dts-style-checker-v4-0-c175e6401150@oss.qualcomm.com?part=4