linux-kernel - Re: [PATCH 1/2] dt-bindings: leds: register-bit-led: Add active-low property

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 19 Aug 2022 12:08:59 +0300
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Pali Rohár <pali@...nel.org>
Cc:     Pavel Machek <pavel@....cz>, Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Marek Behún <kabel@...nel.org>,
        linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: leds: register-bit-led: Add active-low
 property

On 19/08/2022 11:42, Pali Rohár wrote:
> On Friday 19 August 2022 11:38:29 Krzysztof Kozlowski wrote:
>> On 19/08/2022 11:08, Pavel Machek wrote:
>>> Hi!
>>>
>>>>> Although the question is - where is the user of it?
>>>>
>>>> I was planning to send updated powerpc DTS files with these
>>>> register-bit-led definitions after accepting dt bindings.
>>>
>>> We need device tree people to ack them, first. But a note saying "this
>>> is for Turris Omnia router" would be welcome.
>>
>> In general the process is one of:
>> 1. Send DT bindings with driver and DTS changes,
>> 2. Send DT bindings with driver in one patchset, DTS in second but you
>> mention the dependency.
>>
>> You should not wait with DTS till bindings got accepted. Why? Because
>> for example we do not want bindings for stuff which never is going to be
>> upstreamed (with several exceptions, e.g. for other systems). Also
>> because we want to be able to compare bindings with your DTS
>> implementing them, so we are sure you described everything (especially
>> that you said running one command to install dtchema and second command
>> to make the check is not possible in your system).
>>
>> Without DTS here how can anyone be sure your DTS actually follows the
>> bindings?
>>
>> Best regards,
>> Krzysztof
> 
> Well, last time I was told that first needs to be accepted bindings
> documentation and then device tree files. So I did it like this. And now
> it is again feasible and different steps and ordering is needed...
> Sorry I cannot known all requirements which are moreover changing every
> day.

The rule is the same from years and no one was changing it. All driver
submitters, all DTS developers follow this. You are literally the one of
very few which is surprised by that generic rule and call it "a change".
The patches should be accepted by maintainers in such order (so without
bindings acceptance, the driver and DTS should not go), but not the
sending order.

It's the same with sysfs ABI. Exactly the same.

Best regards,
Krzysztof