Re: [PATCH v7 1/3] dt-bindings: leds: rt8515: Support single-GPIO flash ICs with vin supply

[Rudraksha Gupta <guptarud@gmail.com>]

On 9/12/26 19:45, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The `oneOf` constraint incorrectly makes `ent-gpios` and `vin-supply` mutually exclusive and strictly requires exactly one to be present, contradicting the claim that `vin-supply` is optional and artificially restricting valid hardware configurations.
> --
make ARCH=arm CHECK_DTBS=y DT_SCHEMA_FILES=richtek,rt8515.yaml \
       qcom/qcom-msm8960-samsung-expressatt.dtb \
       st/ste-ux500-samsung-codina.dtb \
       st/ste-ux500-samsung-codina-tmo.dtb \
       st/ste-ux500-samsung-gavini.dtb \
       st/ste-ux500-samsung-golden.dtb \
       st/ste-ux500-samsung-janice.dtb \
       st/ste-ux500-samsung-kyle.dtb \
       st/ste-ux500-samsung-skomer.dtb

all 8 in-tree users of this binding. 0 warnings.

existing hw passes. Probably not useful to account for hw not in the tree



>
> commit 72463777ee1c18e7913b350d5d2ad857810ece89
> Author: Rudraksha Gupta <guptarud@gmail.com>
> Subject: dt-bindings: leds: rt8515: Support single-GPIO flash ICs with vin supply
>
> This commit adds support for single-channel variants of the RT8515 flash
> ICs. It makes ent-gpios optional and introduces a vin-supply property,
> adding a oneOf constraint to manage their presence.
>
>> diff --git a/Documentation/devicetree/bindings/leds/richtek,rt8515.yaml b/Documentation/devicetree/bindings/leds/richtek,rt8515.yaml
>> index 0356371a6b014..ab3c5139132cc 100644
>> --- a/Documentation/devicetree/bindings/leds/richtek,rt8515.yaml
>> +++ b/Documentation/devicetree/bindings/leds/richtek,rt8515.yaml
> [ ... ]
>
>> @@ -81,10 +90,15 @@ properties:
>>   
>>   required:
>>     - compatible
>> -  - ent-gpios
>>     - enf-gpios
>>     - led
>>   
>> +oneOf:
>> +  - required:
>> +      - ent-gpios
>> +  - required:
>> +      - vin-supply
>> +
> [Severity: Medium]
> Does this oneOf constraint incorrectly restrict valid hardware configurations?
>
> The oneOf constraint strictly requires exactly one of its subschemas to match.
> If a single-channel IC (which naturally lacks ent-gpios) does not use the
> explicitly optional vin-supply regulator, zero subschemas will match, causing
> schema validation to fail.
>
> Conversely, if a standard dual-channel IC (which requires ent-gpios) is also
> powered by a vin-supply regulator, two subschemas will match. This will also
> fail validation due to the strict exclusivity of oneOf.
>
> Should this be modeled differently to allow vin-supply to be truly optional
> while safely permitting single-channel configurations?
>
>>   additionalProperties: false
>>   
>>   examples: