[lkml]   [2018]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 2/9] dt-bindings: ti-lmu: Remove LM3697

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
>> <> wrote:
>>> On 10/12/2018 08:03 PM, Pavel Machek wrote:
>>>> Hi!
>>>>>>>>> Signed-off-by: Dan Murphy <>
>>>>>>>> NAK.
>>>>>>> Thanks for the NAK.
>>>>>>> This NAK was NAK'd by other maintainer in the V2 RFC patchset
>>>>>> 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]
>>> [1]
>> 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 Murphy

 \ /
  Last update: 2018-10-15 21:15    [W:0.085 / U:0.876 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site