usb: dwc3: of-simple: fix use-after-free on remove
Hi,
Quoted 20 lines · Roger Quadros
Quoted 19 lines · Felipe Balbi
Hi,
Quoted 14 lines · Johan Hovold
Quoted 9 lines · Felipe Balbi
Quoted 2 lines · Johan Hovold
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.
Quoted 6 lines
Quoted 3 lines
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?
Quoted 2 lines
for that because
- it needs to poke a few registers in the wrapper region
dwc3-keystone.c does that already
Quoted 1 line
- it doesn't really need the driver to enable any clock
Seems to me you're trying to port omap_device to arm64...
Quoted 1 line
- 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.