linux-kernel - Re: [PATCH v2 3/9] dt-bindings: mfd: document ASUS Transformer EC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cb91898e-10f1-4d64-bace-41bbed08179b@kernel.org>
Date: Tue, 10 Feb 2026 12:04:26 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Svyatoslav Ryhel <clamor95@...il.com>
Cc: Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Dmitry Torokhov <dmitry.torokhov@...il.com>,
 Pavel Machek <pavel@...nel.org>, Arnd Bergmann <arnd@...db.de>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Sebastian Reichel <sre@...nel.org>, Michał Mirosław
 <mirq-linux@...e.qmqm.pl>, Ion Agorria <ion@...rria.com>,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-input@...r.kernel.org, linux-leds@...r.kernel.org,
 linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 3/9] dt-bindings: mfd: document ASUS Transformer EC

On 10/02/2026 11:59, Svyatoslav Ryhel wrote:
>>>>> +  asus,clear-factory-mode:
>>>>> +    type: boolean
>>>>> +    description: clear Factory Mode bit in EC control register
>>>>
>>>> Why would this be a static/fixed property over lifecycle of all devices?
>>>>
>>>
>>> Specify pls.
>>
>> Provide rationale why we need to clear it every time, not once. Or any
>> other rationale why we would accept that property.
>>
> 
> Cause it is done by original Asus code and Asus did not provide
> schematic or any data apart from downstream source regarding this EC.

So that's a no. downstream code which is poor quality, not following DT
rules at all, is never an argument for a DT property.

> 
>>>
>>>>> +
>>>>> +  battery:
>>>>> +    type: object
>>>>> +    $ref: /schemas/power/supply/power-supply.yaml
>>>>> +    unevaluatedProperties: false
>>>>> +
>>>>> +    properties:
>>>>> +      compatible:
>>>>> +        const: asus,ec-battery
>>>>> +
>>>>> +    required:
>>>>> +      - compatible
>>>>> +
>>>>> +  charger:
>>>>> +    type: object
>>>>> +    $ref: /schemas/power/supply/power-supply.yaml
>>>>> +    additionalProperties: false
>>>>> +
>>>>> +    properties:
>>>>> +      compatible:
>>>>> +        const: asus,ec-charger
>>>>> +
>>>>> +      monitored-battery: true
>>>>> +
>>>>> +    required:
>>>>> +      - compatible
>>>>> +
>>>>> +  keyboard-ext:
>>>>> +    type: object
>>>>> +    description: top row of multimedia keys
>>>>> +    additionalProperties: false
>>>>> +
>>>>> +    properties:
>>>>> +      compatible:
>>>>> +        const: asus,ec-keys
>>>>> +
>>>>> +    required:
>>>>> +      - compatible
>>>>> +
>>>>> +  led:
>>>>> +    type: object
>>>>> +    additionalProperties: false
>>>>> +
>>>>> +    properties:
>>>>> +      compatible:
>>>>> +        const: asus,ec-led
>>>>> +
>>>>> +    required:
>>>>> +      - compatible
>>>>> +
>>>>> +  serio:
>>>>
>>>> All of these children are pointless - no resources. Drop all of them,
>>>> it's btw explicitly documented rule in writing bindings.
>>>>
>>>
>>> They are all needed to be able to disable them individually from the
>>> device tree if needed.
>>
>> They should not be disabled from DT, so they are not valid here. The
>> given EC for given device is fixed/static. Does not change.
>>
> 
> Have you considered a possibility that function may be
> disabled/unrouted within the controller. By the vendor.

And then it is implied by the compatible, so no need for any of that.
Otherwise, if it is not specific per device, then specifying it for DTS
for all devices would make no sense.

Best regards,
Krzysztof