linux-kernel - Re: [PATCH v4 1/2] dt-bindings: leds-lp55xx: add ti,charge-pump-mode

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]

Date:   Thu, 2 Feb 2023 21:11:23 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Maarten Zanders <maarten.zanders@...d.be>,
        Pavel Machek <pavel@....cz>, Lee Jones <lee@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc:     linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/2] dt-bindings: leds-lp55xx: add ti,charge-pump-mode

On 02/02/2023 15:12, Maarten Zanders wrote:
> 
> On 2/2/23 14:43, Krzysztof Kozlowski wrote:
>>
>> Strings in DTS are usually easier to for humans to read, but it's not a
>> requirement to use them. The problem of storing register values is that
>> binding is tied/coupled with hardware programming model, so you cannot
>> add a new device if the register value is a bit different (e.g.
>> LP55XX_CP_OFF is 0x1). You need entire new binding for such case. With
>> string - no need.
> I understand and this is why I started with the string in the first 
> place (as suggested by yourself in V1).
>> With binding constants (IDs) also no need, so was this
>> the intention? Just to be clear - it is then ID or binding constant, not
>> a value for hardware register.
>>
> For simplicity sake, yes, now the setting is propagating directly into 
> the register as a bit value. But this is how the current implementation 
> of the drivers work. If we add a device in the future which indeed has 
> different bit mappings, that driver will have to do a mapping of the DT 
> binding to its own bit field definitions. I consider this DT binding as 
> the "master", which is now conveniently chosen to match the register values.

OK, that makes sense.

Best regards,
Krzysztof