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

[Dan Murphy <dmurphy@ti.com>]

Jacek

On 10/15/2018 02:13 PM, Jacek Anaszewski wrote:
> On 10/15/2018 02:56 AM, Rob Herring wrote:
>> On Sat, Oct 13, 2018 at 1:46 PM Jacek Anaszewski
>> <jacek.anaszewski@gmail.com> wrote:
>>>
>>> On 10/12/2018 08:03 PM, Pavel Machek wrote:
>>>> Hi!
>>>>
>>>>>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.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?
>>
>> In theory there could be out of tree users. Having a dts file using it
>> in tree shouldn't be a requirement to maintain the ABI IMO. However, a
>> lack of dts is one piece of determining whether this is in use or not.
>>
>>> 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
>>
>> Given this one seems to have not really been finished, it's probably
>> okay to make changes in this case. Still, it would be good to see
>> patches structured so that it's obvious we're breaking things. But how
>> the patches are structured doesn't matter until there's some agreement
>> on the end result.
> 
> OK, so if I'm getting it right, the correct patch structure in this case
> means that changes removing bindings from MFD and moving them along
> with the modifications to the LED subsystem should be placed in a single
> patch.
> 
> Dan, could you please arrange the next patch set version accordingly?

Yes I can squash the DT bindings patches and call it a "move and modify"

Dan

> 


-- 
------------------
Dan Murphy