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

[Felipe Balbi <balbi@kernel.org>]

"Rafael J. Wysocki" <rafael@kernel.org> writes:

> On Wed, Jun 20, 2018 at 11:27 AM, Felipe Balbi <balbi@kernel.org> wrote:
>>
>> Hi,
>>
>> Tony Lindgren <tony@atomide.com> writes:
>>> * Felipe Balbi <balbi@kernel.org> [180619 01:23]:
>>>> This is a direct consequence of not paying attention to the order of
>>>> things. If driver were to assume that pm_domain->activate() would do the
>>>> right thing for the device -- meaning that probe would run with an
>>>> active device --, then we wouldn't need that pm_runtime_get() call on
>>>> probe at all. Rather we would follow the sequence:
>>>>
>>>>      pm_runtime_forbid()
>
> Why do you need the _forbid() thing?
>
> Does the default user space control setting need to be changed?

wouldn't that race with a udev rule writing "auto" power/control as soon
as device is added?

>>>> (If you need to know why the pm_runtime_put_noidle(), remember that
>>>> pm_runtime_set_active() increments the usage counter, so
>>>> pm_runtime_put_noidle is basically allowing pm_runtime to happen as soon
>>>> as userspace writes "auto" to /sys/..../power/control)
>>>
>>> I wonder if we could also remove the need for drivers to call
>>> pm_runtime_putnoidle() at the end of the probe? If we had
>>> pm_runtime_init_enabled() implemented.
>>
>> probably not. We want to block runtime pm during probe, until the device
>> is fully initialized, the only way to do that is to increment rpm usage
>> counter.
>
> That or enable it only at the end.  But I guess you want to
> runtime-resume it earlier, don't you?

well, if arch implements pm_domain->activate() and guarantees that
device is already running, with clocks stable during probe, then
enabling runtime pm at the end is probably the best idea.