* [PATCH RESEND] phy: phy-twl4030-usb: fix denied runtime access @ 2018-09-17 5:22 Andreas Kemnade 2018-09-17 17:51 ` Dmitry Torokhov 0 siblings, 1 reply; 6+ messages in thread From: Andreas Kemnade @ 2018-09-17 5:22 UTC (permalink / raw) To: kishon, lee.jones, dmitry.torokhov, daniel.thompson, wsa, linux-omap, linux-kernel, Discussions about the Letux Kernel Cc: Andreas Kemnade When runtime is not enabled, pm_runtime_get_sync() returns -EACCESS, the counter will be incremented but the resume callback not called, so enumeration and charging will not start properly. To avoid that happen, wait and try again later. Practically this happens when the device is woken up from suspend by plugging in usb. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> --- drivers/phy/ti/phy-twl4030-usb.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/phy/ti/phy-twl4030-usb.c b/drivers/phy/ti/phy-twl4030-usb.c index a44680d64f9b..1f3cf4e48383 100644 --- a/drivers/phy/ti/phy-twl4030-usb.c +++ b/drivers/phy/ti/phy-twl4030-usb.c @@ -552,6 +552,15 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl) status = twl4030_usb_linkstat(twl); + /* we might get here too early when runtime is not ready yet + * and we will get an EACCESS later, so try again later + */ + if (!pm_runtime_enabled(twl->dev)) { + cancel_delayed_work(&twl->id_workaround_work); + schedule_delayed_work(&twl->id_workaround_work, HZ); + return IRQ_HANDLED; + } + mutex_lock(&twl->lock); if (status >= 0 && status != twl->linkstat) { status_changed = -- 2.11.0 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH RESEND] phy: phy-twl4030-usb: fix denied runtime access 2018-09-17 5:22 [PATCH RESEND] phy: phy-twl4030-usb: fix denied runtime access Andreas Kemnade @ 2018-09-17 17:51 ` Dmitry Torokhov 2018-09-17 18:56 ` Andreas Kemnade 0 siblings, 1 reply; 6+ messages in thread From: Dmitry Torokhov @ 2018-09-17 17:51 UTC (permalink / raw) To: Andreas Kemnade Cc: kishon, lee.jones, daniel.thompson, wsa, linux-omap, linux-kernel, Discussions about the Letux Kernel Hi Andreas, On Mon, Sep 17, 2018 at 07:22:54AM +0200, Andreas Kemnade wrote: > When runtime is not enabled, pm_runtime_get_sync() returns -EACCESS, > the counter will be incremented but the resume callback not called, > so enumeration and charging will not start properly. > To avoid that happen, wait and try again later. > > Practically this happens when the device is woken up from suspend by > plugging in usb. > > Signed-off-by: Andreas Kemnade <andreas@kemnade.info> > --- > drivers/phy/ti/phy-twl4030-usb.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/phy/ti/phy-twl4030-usb.c b/drivers/phy/ti/phy-twl4030-usb.c > index a44680d64f9b..1f3cf4e48383 100644 > --- a/drivers/phy/ti/phy-twl4030-usb.c > +++ b/drivers/phy/ti/phy-twl4030-usb.c > @@ -552,6 +552,15 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl) > > status = twl4030_usb_linkstat(twl); > > + /* we might get here too early when runtime is not ready yet > + * and we will get an EACCESS later, so try again later > + */ How exactly can this happen? What disables (and later re-enables) runtime PM? How can we guarantee that the interrupt will be re-triggered? > + if (!pm_runtime_enabled(twl->dev)) { > + cancel_delayed_work(&twl->id_workaround_work); > + schedule_delayed_work(&twl->id_workaround_work, HZ); > + return IRQ_HANDLED; > + } > + > mutex_lock(&twl->lock); > if (status >= 0 && status != twl->linkstat) { > status_changed = > -- > 2.11.0 > Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH RESEND] phy: phy-twl4030-usb: fix denied runtime access 2018-09-17 17:51 ` Dmitry Torokhov @ 2018-09-17 18:56 ` Andreas Kemnade 2018-09-17 22:23 ` Dmitry Torokhov 0 siblings, 1 reply; 6+ messages in thread From: Andreas Kemnade @ 2018-09-17 18:56 UTC (permalink / raw) To: Dmitry Torokhov Cc: kishon, lee.jones, daniel.thompson, wsa, linux-omap, linux-kernel, Discussions about the Letux Kernel [-- Attachment #1: Type: text/plain, Size: 1978 bytes --] Hi Dmitry, On Mon, 17 Sep 2018 10:51:31 -0700 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > Hi Andreas, > > On Mon, Sep 17, 2018 at 07:22:54AM +0200, Andreas Kemnade wrote: > > When runtime is not enabled, pm_runtime_get_sync() returns -EACCESS, > > the counter will be incremented but the resume callback not called, > > so enumeration and charging will not start properly. > > To avoid that happen, wait and try again later. > > > > Practically this happens when the device is woken up from suspend by > > plugging in usb. > > > > Signed-off-by: Andreas Kemnade <andreas@kemnade.info> > > --- > > drivers/phy/ti/phy-twl4030-usb.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/drivers/phy/ti/phy-twl4030-usb.c b/drivers/phy/ti/phy-twl4030-usb.c > > index a44680d64f9b..1f3cf4e48383 100644 > > --- a/drivers/phy/ti/phy-twl4030-usb.c > > +++ b/drivers/phy/ti/phy-twl4030-usb.c > > @@ -552,6 +552,15 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl) > > > > status = twl4030_usb_linkstat(twl); > > > > + /* we might get here too early when runtime is not ready yet > > + * and we will get an EACCESS later, so try again later > > + */ > > How exactly can this happen? What disables (and later re-enables) > runtime PM? If the whole resume process is started by plugging in usb, the interrupt will be triggered still in the resume process so that runtime resume is not yet possible, pm_runtime_get_sync() returns EACCESS > How can we guarantee that the interrupt will be > re-triggered? > The interrupt will not be re-triggered but the handler will be called at some other places... > > + if (!pm_runtime_enabled(twl->dev)) { > > + cancel_delayed_work(&twl->id_workaround_work); > > + schedule_delayed_work(&twl->id_workaround_work, HZ); > > + return IRQ_HANDLED; > > + } > > + ... for example by this delayed work which is already there. Regards, Andreas [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH RESEND] phy: phy-twl4030-usb: fix denied runtime access 2018-09-17 18:56 ` Andreas Kemnade @ 2018-09-17 22:23 ` Dmitry Torokhov 2018-09-18 16:16 ` Andreas Kemnade 0 siblings, 1 reply; 6+ messages in thread From: Dmitry Torokhov @ 2018-09-17 22:23 UTC (permalink / raw) To: Andreas Kemnade Cc: kishon, lee.jones, daniel.thompson, wsa, linux-omap, linux-kernel, Discussions about the Letux Kernel On Mon, Sep 17, 2018 at 08:56:34PM +0200, Andreas Kemnade wrote: > Hi Dmitry, > > On Mon, 17 Sep 2018 10:51:31 -0700 > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > > Hi Andreas, > > > > On Mon, Sep 17, 2018 at 07:22:54AM +0200, Andreas Kemnade wrote: > > > When runtime is not enabled, pm_runtime_get_sync() returns -EACCESS, > > > the counter will be incremented but the resume callback not called, > > > so enumeration and charging will not start properly. > > > To avoid that happen, wait and try again later. > > > > > > Practically this happens when the device is woken up from suspend by > > > plugging in usb. > > > > > > Signed-off-by: Andreas Kemnade <andreas@kemnade.info> > > > --- > > > drivers/phy/ti/phy-twl4030-usb.c | 9 +++++++++ > > > 1 file changed, 9 insertions(+) > > > > > > diff --git a/drivers/phy/ti/phy-twl4030-usb.c b/drivers/phy/ti/phy-twl4030-usb.c > > > index a44680d64f9b..1f3cf4e48383 100644 > > > --- a/drivers/phy/ti/phy-twl4030-usb.c > > > +++ b/drivers/phy/ti/phy-twl4030-usb.c > > > @@ -552,6 +552,15 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl) > > > > > > status = twl4030_usb_linkstat(twl); > > > > > > + /* we might get here too early when runtime is not ready yet > > > + * and we will get an EACCESS later, so try again later > > > + */ > > > > How exactly can this happen? What disables (and later re-enables) > > runtime PM? > If the whole resume process is started by plugging in usb, the > interrupt will be triggered still in the resume process so that > runtime resume is not yet possible, pm_runtime_get_sync() returns > EACCESS I see. This all seems a bit wonky, to be honest. I would expect that the driver would have a suspend routine that disables interrupt and also configure interrupt for wakeup (enable_irq_wake) and kick bus scanning from there instead of aborting interrupt handler... > > > How can we guarantee that the interrupt will be > > re-triggered? > > > The interrupt will not be re-triggered but the handler will be > called at some other places... > > > > + if (!pm_runtime_enabled(twl->dev)) { > > > + cancel_delayed_work(&twl->id_workaround_work); > > > + schedule_delayed_work(&twl->id_workaround_work, HZ); > > > + return IRQ_HANDLED; > > > + } > > > + > ... for example by this delayed work which is already there. If we decide to keep this, it should be mod_delayed_work() I think. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH RESEND] phy: phy-twl4030-usb: fix denied runtime access 2018-09-17 22:23 ` Dmitry Torokhov @ 2018-09-18 16:16 ` Andreas Kemnade 2018-09-18 16:56 ` Dmitry Torokhov 0 siblings, 1 reply; 6+ messages in thread From: Andreas Kemnade @ 2018-09-18 16:16 UTC (permalink / raw) To: Dmitry Torokhov Cc: kishon, lee.jones, daniel.thompson, wsa, linux-omap, linux-kernel, Discussions about the Letux Kernel [-- Attachment #1: Type: text/plain, Size: 2965 bytes --] Hi, On Mon, 17 Sep 2018 15:23:45 -0700 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > On Mon, Sep 17, 2018 at 08:56:34PM +0200, Andreas Kemnade wrote: > > Hi Dmitry, > > > > On Mon, 17 Sep 2018 10:51:31 -0700 > > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > > > > Hi Andreas, > > > > > > On Mon, Sep 17, 2018 at 07:22:54AM +0200, Andreas Kemnade wrote: > > > > When runtime is not enabled, pm_runtime_get_sync() returns -EACCESS, > > > > the counter will be incremented but the resume callback not called, > > > > so enumeration and charging will not start properly. > > > > To avoid that happen, wait and try again later. > > > > > > > > Practically this happens when the device is woken up from suspend by > > > > plugging in usb. > > > > > > > > Signed-off-by: Andreas Kemnade <andreas@kemnade.info> > > > > --- > > > > drivers/phy/ti/phy-twl4030-usb.c | 9 +++++++++ > > > > 1 file changed, 9 insertions(+) > > > > > > > > diff --git a/drivers/phy/ti/phy-twl4030-usb.c b/drivers/phy/ti/phy-twl4030-usb.c > > > > index a44680d64f9b..1f3cf4e48383 100644 > > > > --- a/drivers/phy/ti/phy-twl4030-usb.c > > > > +++ b/drivers/phy/ti/phy-twl4030-usb.c > > > > @@ -552,6 +552,15 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl) > > > > > > > > status = twl4030_usb_linkstat(twl); > > > > > > > > + /* we might get here too early when runtime is not ready yet > > > > + * and we will get an EACCESS later, so try again later > > > > + */ > > > > > > How exactly can this happen? What disables (and later re-enables) > > > runtime PM? > > If the whole resume process is started by plugging in usb, the > > interrupt will be triggered still in the resume process so that > > runtime resume is not yet possible, pm_runtime_get_sync() returns > > EACCESS > > I see. This all seems a bit wonky, to be honest. I would expect that the > driver would have a suspend routine that disables interrupt and also > configure interrupt for wakeup (enable_irq_wake) and kick bus scanning > from there instead of aborting interrupt handler... > well, that seems doable. So there will be a v2. > > > > > How can we guarantee that the interrupt will be > > > re-triggered? > > > > > The interrupt will not be re-triggered but the handler will be > > called at some other places... > > > > > > + if (!pm_runtime_enabled(twl->dev)) { > > > > + cancel_delayed_work(&twl->id_workaround_work); > > > > + schedule_delayed_work(&twl->id_workaround_work, HZ); > > > > + return IRQ_HANDLED; > > > > + } > > > > + > > ... for example by this delayed work which is already there. > > If we decide to keep this, it should be mod_delayed_work() I think. > Well, is that valid for the other uses of id_workaround_work() (which are clearly required)? So there should be a second, independent cleanup patch for the existing uses? Regards, Andreas [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH RESEND] phy: phy-twl4030-usb: fix denied runtime access 2018-09-18 16:16 ` Andreas Kemnade @ 2018-09-18 16:56 ` Dmitry Torokhov 0 siblings, 0 replies; 6+ messages in thread From: Dmitry Torokhov @ 2018-09-18 16:56 UTC (permalink / raw) To: Andreas Kemnade Cc: kishon, lee.jones, daniel.thompson, wsa, linux-omap, linux-kernel, Discussions about the Letux Kernel On Tue, Sep 18, 2018 at 06:16:19PM +0200, Andreas Kemnade wrote: > Hi, > > On Mon, 17 Sep 2018 15:23:45 -0700 > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > > On Mon, Sep 17, 2018 at 08:56:34PM +0200, Andreas Kemnade wrote: > > > Hi Dmitry, > > > > > > On Mon, 17 Sep 2018 10:51:31 -0700 > > > Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > > > > > > Hi Andreas, > > > > > > > > On Mon, Sep 17, 2018 at 07:22:54AM +0200, Andreas Kemnade wrote: > > > > > When runtime is not enabled, pm_runtime_get_sync() returns -EACCESS, > > > > > the counter will be incremented but the resume callback not called, > > > > > so enumeration and charging will not start properly. > > > > > To avoid that happen, wait and try again later. > > > > > > > > > > Practically this happens when the device is woken up from suspend by > > > > > plugging in usb. > > > > > > > > > > Signed-off-by: Andreas Kemnade <andreas@kemnade.info> > > > > > --- > > > > > drivers/phy/ti/phy-twl4030-usb.c | 9 +++++++++ > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > diff --git a/drivers/phy/ti/phy-twl4030-usb.c b/drivers/phy/ti/phy-twl4030-usb.c > > > > > index a44680d64f9b..1f3cf4e48383 100644 > > > > > --- a/drivers/phy/ti/phy-twl4030-usb.c > > > > > +++ b/drivers/phy/ti/phy-twl4030-usb.c > > > > > @@ -552,6 +552,15 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl) > > > > > > > > > > status = twl4030_usb_linkstat(twl); > > > > > > > > > > + /* we might get here too early when runtime is not ready yet > > > > > + * and we will get an EACCESS later, so try again later > > > > > + */ > > > > > > > > How exactly can this happen? What disables (and later re-enables) > > > > runtime PM? > > > If the whole resume process is started by plugging in usb, the > > > interrupt will be triggered still in the resume process so that > > > runtime resume is not yet possible, pm_runtime_get_sync() returns > > > EACCESS > > > > I see. This all seems a bit wonky, to be honest. I would expect that the > > driver would have a suspend routine that disables interrupt and also > > configure interrupt for wakeup (enable_irq_wake) and kick bus scanning > > from there instead of aborting interrupt handler... > > > well, that seems doable. So there will be a v2. > > > > > > > > How can we guarantee that the interrupt will be > > > > re-triggered? > > > > > > > The interrupt will not be re-triggered but the handler will be > > > called at some other places... > > > > > > > > + if (!pm_runtime_enabled(twl->dev)) { > > > > > + cancel_delayed_work(&twl->id_workaround_work); > > > > > + schedule_delayed_work(&twl->id_workaround_work, HZ); > > > > > + return IRQ_HANDLED; > > > > > + } > > > > > + > > > ... for example by this delayed work which is already there. > > > > If we decide to keep this, it should be mod_delayed_work() I think. > > > Well, is that valid for the other uses of id_workaround_work() (which > are clearly required)? So there should be a second, independent > cleanup patch for the existing uses? Yes, mod_delayed_work() is replacement for cancel + reschedule. I guess this driver was created before mod_delayed_work() was added to the kernel. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-09-18 16:56 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-09-17 5:22 [PATCH RESEND] phy: phy-twl4030-usb: fix denied runtime access Andreas Kemnade 2018-09-17 17:51 ` Dmitry Torokhov 2018-09-17 18:56 ` Andreas Kemnade 2018-09-17 22:23 ` Dmitry Torokhov 2018-09-18 16:16 ` Andreas Kemnade 2018-09-18 16:56 ` Dmitry Torokhov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).