linux-kernel - Re: [PATCH v3 2/9] dt-bindings: ti-lmu: Remove LM3697

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:   Sat, 13 Oct 2018 20:45:58 +0200
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Pavel Machek <pavel@....cz>, Rob Herring <robh@...nel.org>
Cc:     Dan Murphy <dmurphy@...com>, lee.jones@...aro.org,
        tony@...mide.com, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-leds@...r.kernel.org
Subject: Re: [PATCH v3 2/9] dt-bindings: ti-lmu: Remove LM3697

On 10/12/2018 08:03 PM, Pavel Machek wrote:
> Hi!
> 
>>>>>> Signed-off-by: Dan Murphy <dmurphy@...com>
>>>>>
>>>>> NAK.
>>>>
>>>> Thanks for the NAK.
>>>>
>>>> This NAK was NAK'd by other maintainer in the V2 RFC patchset
>>>>
>>>> https://lore.kernel.org/patchwork/patch/993171/
>>>
>>> I confirm. LM3697 is a standalone device and not a cell of any
>>> MFD device.
>>>
>>> Waiting for DT maintainer's ack.
>>
>> You all sort out what you want... I can't follow it all, and I'm not 
>> going to spend the time trying to figure out what is going on here.
> 
> This is what I want:
> 
>> As this is worded, changing the driver is a Linux problem and irrelevant 
>> to the binding. Now if you want to move documentation to a location that 
>> makes more sense, then fine. But structure patches that way and make it 
>> clear that from an binding ABI perspective, nothing is changing.
> 
> ...but apparently I did not have enough authority to get it.
> 
> (I'm ok with move, and it is possible that binding does need some
> fixups besides the move; still it should be done as fixup not as a new
> binding).

There is a fundamental question - should the bindings be considered
an ABI, even though there is no mainline "*.dts" implementation basing
on these bindings?

This patch fixes the issues of bindings in a way that would change
the ABI, if only it existed. But it apparently doesn't exist in
mainline. Unless a DT documentation itself constitutes an ABI.

I'd like to have it clarified at this occasion, and that's why
I kindly ask for DT maintainer's ack or NACK for this modification
of bindings.

For a reference we have a nice summary of the MFD driver and related
bindings' flaws in [0] and [1].

[0] https://lkml.org/lkml/2018/9/7/774
[1] https://lkml.org/lkml/2018/9/11/984

-- 
Best regards,
Jacek Anaszewski