On Fri, Mar 14, 2014 at 11:07:05AM +0000, Tomi Valkeinen wrote:
> On 14/03/14 12:19, Tomi Valkeinen wrote:
> > On 14/03/14 12:14, Mark Rutland wrote:
> >
> >> I can't see anything obviously wrong in platform_device_del. Do you have
> >> a backtrace?
> >
> > Yes, below.
> >
> > I can see at least drivers/usb/dwc3/dwc3-exynos.c doing the exact same thing
> > I do, so maybe I've got something wrong with the omapdss driver.
>
> Looks to me that the devices created by of_platform_populate() are not
> unregisterable in all cases. The address resource created via
> of_platform_populate() had NULL res->parent, which causes
> release_resource to crash.
Hmm. I can't see that unregistering such devices ever works as you say,
given that __release_resource expects a non-NULL parent pointer. Either
we should be setting the parent pointer when initialising devices from
dt or we should teach __release_resource to not care. I'll have a go at
fixing that.
It looks like drivers/usb/dwc3/dwc3-exynos.c only unregisters the
top-level device, not children. This top-level device has no
IORESOURCE_{IO,MEM} resources judging by
arch/arm/boot/dts/exynos5250.dtsi, which would explain why that driver
isn't exploding: __release_resource will never get called.
Anton, Felipe:
Does unregistering the parent ensure the children get cleaned up, or
does it leave them dangling in the dwc3-exynos driver?
Cheers,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
