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@xxxxxxxxx> wrote: >>> >>> On 10/12/2018 08:03 PM, Pavel Machek wrote: >>>> Hi! >>>> >>>>>>>>> Signed-off-by: Dan Murphy <dmurphy@xxxxxx> >>>>>>>> >>>>>>>> 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
