[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <60cc9238-aba2-aa6a-64a4-2b5e20835549@gmail.com>
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
Powered by blists - more mailing lists