Dan, On 09/17/2018 05:24 PM, Dan Murphy wrote: > Jacek > > On 09/15/2018 03:00 PM, Jacek Anaszewski wrote: >> Hi Pavel. >> >> On 09/14/2018 11:42 PM, Pavel Machek wrote: >>> Hi! >>> >>>>> You may want to learn more about device tree and/or talk to the device >>>>> tree maintainers. This is an old article. https://lwn.net/Articles/561462/ >>>> >>>> The article title is "Device trees as ABI". A device tree is defined >>>> in the "*.dts" file that is then compiled to a dtb blob, which >>>> constitutes the ABI. And this ABI should be kept backwards compatible. >>>> >>>> What is discussed here is a documentation of bindings, i.e. according >>>> to ePAPR: "requirements for how specific types and classes of devices >>>> are represented in the device tree". >>>> >>>> >From the bindings documented in the >>>> Documentation/devicetree/bindings/mfd/ti-lmu.txt only >>>> ti,lm3532-backlight is used in the mainline dts file >>>> (arch/arm/boot/dts/omap4-droid4-xt894.dts). >>>> >>>> Having the above it seems that there is no risk of breaking any >>>> users. >>> >>> DTBs and bindings are supposed to be portable between operating >>> systems. You are right there are no _mainline_ _Linux_ users. >> >> No mainline users means no users we should care of. >> Other people also don't care - see patch [0]. >> >>>>> NAK on this patch. I see that this binding has problems, but >>>>> introducing different binding for subset of devices is _not_ a fix. >>>>> >>>>>>> What about the multi function devices? They should have same binding. >>>>>> >>>>>> The MFD devices defined are not in contention here only the SFD. >>>>> >>>>> I'd like to see common solutions for SFD and MFD, as the hardware is >>>>> similar, and that includes the code. Having code that is easier to >>>>> maintain is important, and having many drivers are harder to maintain >>>>> than one driver. >>>>> >>>>> Milo's code looks better than yours in that regard. I disagree about >>>>> Milo's code being "nightmare" to modify, and care about "easy to >>>>> maintain" more than "binary size". >>>> >>>> Easy to maintain will be a dedicated LED class driver. >>> >>> You mean, 3 dedicated LED class drivers and 3 MFD drivers with LED >>> parts? We'll need complex driver anyway, and I'd really like to have >>> just one. >> >> In the LED subsystem we can wrap common functionalities >> into a library object. MFD driver will be able to reuse it then. > > I am currently working on that code now. I expect a RFC on this this week. Will it affect the shape of the driver for lm3697 as of v7 [0]? Or the patch set [0] state should be deemed "awaiting merge"? [0] https://lkml.org/lkml/2018/9/11/760 -- Best regards, Jacek Anaszewski
