On 07/02/2017 11:27 PM, Vignesh R wrote:
Hi,
On Saturday 01 July 2017 01:04 AM, Strashko, Grygorii wrote:
On 06/29/2017 01:03 AM, Tony Lindgren wrote:
* Vignesh R <vigneshr@xxxxxx> [170628 21:21]:
On Thursday 29 June 2017 05:01 AM, Strashko, Grygorii wrote:
IRQ_NOAUTOEN can't be used with shared IRQs and Kernel now will triggers
warning if it happns, since commit 04c848d39879 ("genirq: Warn when
IRQ_NOAUTOEN is used with shared interrupts"). And this is the case for
OMAP DWC 3 driver.
Hence, remove IRQ_NOAUTOEN flag and instead call disable_irq() before
disabling PM runtime in probe error path handling.
Or, how about requesting the irq at the end of probe after extcon
registration?
Hmm yeah, what prevents the issue that we tried to fix with commit
12a7f17fac5b ("usb: dwc3: omap: fix race of pm runtime with irq handler
in probe")?
No, I think. There should be the disable_irq() call any way
before pm_runtime_put_sync(dev);| pm_runtime_disable(dev); -
once IRQ is requested driver can't know if IRQ handler is running now or not
unless it will call disable_irq()/free_irq().
But, I've also thought about moving request_irq() down (seems
it can be moved even after of_platform_populate()).
looks like it can be separate patch.
commit 12a7f17fac5b says PM runtime can race with IRQ handler when
deferred probing happening due to extcon, therefore IRQ_NOAUTOEN was set
and disable_irq() call was added. If IRQ handler registration is moved
to a place after of_platform_populate(), then we can be sure that extcon
is registered and there wont be any deferred probe or race with irq
handler and PM runtime. Would disable_irq() still be needed then?
You might be correct, so feel free to send a patch.
--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
