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? -- Best regards, Jacek Anaszewski
