Re: [PATCH 4/4] mfd: tps65217: Instantiate sub-devices from device tree
From: Enric Balletbo Serra <eballetbo@gmail.com>
Date: 2017-06-09 09:55:10
Also in:
linux-arm-kernel, linux-input, linux-leds, linux-omap, lkml
Hello Grygorii, Javier, 2017-06-09 2:00 GMT+02:00 Javier Martinez Canillas [off-list ref]:
Hello Grygorii, [snip]quoted
quoted
For tps65218 couldn't instead of using mfd_add_devices() for all the sub-devs, had used of_platform_populate() for the ones that have device nodes and mfd_add_devices() only for the "tps65218-regulator"? The commit talks about nodes without compatibles but's actually about sub-devices without an associated device node. For me it makes sense to use of_platform_populate() when the MFD has device nodes for their sub-devices and mfd_add_devices() when DT knows nothing about the sub-devices.FYI. Below is link discussion I'm referring to between Mark Brown and Andrew F. Davis https://lkml.org/lkml/2015/10/22/823 the same - https://groups.google.com/forum/#!topic/linux.kernel/wQsdSpPMroQThanks a lot for the pointer. There's a subtle difference between the argument you made and the one that Mark is making in this thread though. Because you said (sorry if I misunderstood) that mfd_add_devices() should be used instead of of_device_populate() even when sub-devices are described as DT nodes (as is the case in the commit you shared) while Mark is saying that if the sub-devs IP blocks are part of the MFD, then it shouldn't be exposed in the DT and be instantiated via mfd_add_devices() and I absolutely agree with that. So I was arguing for using of_device_populate() if the sub-devices are described in the DT. If that makes sense or not to expose the sub-devices in the DT for this particular driver is a different discussion and I can't comment on that since I'm not familiar with the HW.
I'm agree with Grygorii here that has no sense describe the static interrupts resources in the DT here unless DT maintainers prefer have them (dunno their preferences). OTOH, for the charger we need a way to disable (or having a mfd propriety or having a DT subnode with the status). I have a new idea that might be acceptable by Grygorii and also solve my use case. Let me prepare a second patchset and lets continue the discussion there? Best regards, Enric
Best regards, Javier