(restoring the Cc list I cleared accidentally in previous reply) On 16/04/14 21:29, Rob Herring wrote: > On Wed, Apr 16, 2014 at 12:19 PM, Sylwester Nawrocki > <s.nawrocki@xxxxxxxxxxx> wrote: >> On 16/04/14 17:34, Rob Herring wrote: >>> On Tue, Apr 15, 2014 at 12:34 PM, Sylwester Nawrocki >>> <s.nawrocki@xxxxxxxxxxx> wrote: >>>>> This patch makes the driver instantiating its child devices itself, >>>>> rather than relying on an OS to instantiate devices as children >>>>> of "simple-bus". This removes an incorrect usage of "simple-bus" >>>>> compatible. >>> >>> Good, but why can't you use of_platform_populate with the root being >>> the "samsung,fimc" node? The code to instantiate the devices belongs >>> in the core OF code. >> >> As I mentioned in other thread, I couldn't see anything like >> of_platform_unpopulate(), which would allow to destroy any created >> devices. I can't have of_platform_populate() called as last thing >> in probe() as some drivers do, so at least deferred probe works. >> Anyway, it wouldn't be a solution since on a driver removal the >> created devices must be unregistered. > > I think the deferred probe will get fixed in 3.16, but I'm not > following how deferred probe is relevant here. What I meant was that when something fails in the middle of probe() callback and of_platform_populate() was already called any devices created by it must be destroyed before returning an error from probe(). And some drivers seem to never free their devices created by of_platform_populate(). >> I read through thread [1] and I didn't immediately have an idea how >> to fix the core OF code. So I thought I'd come up with this partial >> solution. >> >> I was wondering if creating functions like of_platform_device_delete(), >> of_amba_device_delete() and a function that would walk device tree and >> call them would be a way to go ? I could spend some time on that, any >> suggestions would be appreciated. > > I need to look at the other removal case, but perhaps the way you did > using children of the struct device parent is the right way. I'm fine > with that, but I just want to see this in the core code. All right, I'll have a closer look then if it can be done that way. > Rob > >> >> -- >> Regards, >> Sylwester >> >> [1] http://www.spinics.net/lists/linux-omap/msg94484.html -- Thanks, Sylwester -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
