usb: dwc3: of-simple: fix use-after-free on remove

Hi,

Roger Quadros [off-list ref] writes:

On 18/06/18 12:51, Felipe Balbi wrote:

quoted

Hi,

Johan Hovold [off-list ref] writes:

quoted

On Mon, Jun 18, 2018 at 12:33:44PM +0300, Felipe Balbi wrote:

quoted

Johan Hovold [off-list ref] writes:

quoted

quoted

I suggest merging this fix for 4.18-rc, and then Roger can rework the
driver so that it works also on OMAP.

omap has its own glue layer for several reasons. If you're talking about
Keystone devices, then okay, I understand. But in that case, this would
mean Keystone is copying the same arguably broken PM domain design from
OMAP and it would be best not to propagate that idea.

Maybe so. I'm not sure what Roger's use case is, but perhaps the omap
glue driver could be used instead.

unlikely. Keystone devices are very different from OMAP family. But
we'll see what Roger says.

Well, I was considering to use of-simple for the AM654 SoC [1] but now
I'm of the opinion that it might be better to add a new glue layer driver

why isn't dwc3-keystone.c enough?

for that because
- it needs to poke a few registers in the wrapper region

dwc3-keystone.c does that already

- it doesn't really need the driver to enable any clock

Seems to me you're trying to port omap_device to arm64...

- it needs a pm_runtime_get_sync() to be done in probe

this really shouldn't be necessary. Keystone doesn't rely on all the
omap_device legacy. At least it didn't use to. Could it be that you're
just missing a struct dev_pm_domain definition for arm64?

I haven't seen how you guys implemented your PM for arm64 (is there a
publically accessible version somewhere?), but I'd say you should take
the opportunity to remove this relying on pm_runtime_get_sync() calls
from probe and just do what everybody else does; namely: enable clocks
on probe, pm_runtime_set_active, etc.

This helps drivers being able to make assumptions about devices being
enabled during probe. pm_runtime becomes easier to implement generically
too.