Hi, On Tue, Oct 2, 2012 at 6:08 PM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Oct 01, 2012 at 08:54:23PM +0530, ABRAHAM, KISHON VIJAY wrote: >> On Mon, Oct 1, 2012 at 5:39 PM, Mark Brown > >> > Why would that be helpful? Most platforms don't support DT at all, and > >> I'm not sure how to put it correctly. All I'm trying to tell is mfd is >> a framework that exposes a set of API's to create and remove a device >> among others. If a mfd child device is not created using mfd API, >> it'll be unfair to expect that child be removed properly using mfd >> API. Like in this patch, the device is created using >> of_platform_populate (not a mfd API) but is removed using >> mfd_remove_devices (mfd API) [which should result in an abort]. > > That doesn't sound terribly clever, no, though it's not immediately > clear to me if the non-clever bit is using mfd_remove_devices() or > of_platform_populate(). > >> This means mfd framework does not have an API to create a device from >> dt data or so do I think since of_platform_populate() is used. Thats >> why I suggested the idea of extending mfd_add_devices() (or adding a >> new API in mfd framework) to create child devices from dt data so that >> we'll have API's in mfd framework to both create and delete a device. > > The trouble that always exists with representing MFD children in DT is > that unless you've got a usefully reusable IP block which is clearly > separate from the chip integration you end up essentially just dumping > the Linux data structures into DT which often doesn't leave you with > something which describes the hardware. indeed! Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
