All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Gross <andy.gross@linaro.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] usb: echi-hcd: Add ehci_setup check before echi_shutdown
Date: Fri, 20 May 2016 11:09:00 -0500	[thread overview]
Message-ID: <CAPBZ5Qe3EbTKSihugJ-b8HwvPyQtPXFXVyaeBjY0takuzn+d4A@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1605201156220.1938-100000@iolanthe.rowland.org>

On 20 May 2016 at 10:57, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 20 May 2016, Andy Gross wrote:
>
>> On 20 May 2016 at 09:31, Alan Stern <stern@rowland.harvard.edu> wrote:
>> > On Thu, 19 May 2016, Andy Gross wrote:
>> >
>> >> On 19 May 2016 at 05:12, Srinivas Kandagatla
>> >> <srinivas.kandagatla@linaro.org> wrote:
>> >>
>> >> <snip>
>> >>
>> >> > +++ b/drivers/usb/host/ehci-hcd.c
>> >> > @@ -368,6 +368,15 @@ static void ehci_shutdown(struct usb_hcd *hcd)
>> >> >  {
>> >> >         struct ehci_hcd *ehci = hcd_to_ehci(hcd);
>> >> >
>> >> > +       /**
>> >> > +        * Protect the system from crashing at system shutdown in cases where
>> >> > +        * usb host is not added yet from OTG controller driver.
>> >> > +        * As ehci_setup() not done yet, so stop accessing registers or
>> >> > +        * variables initialized in ehci_setup()
>> >> > +        */
>> >> > +       if (!ehci->sbrn)
>> >> > +               return;
>> >> > +
>> >> >         spin_lock_irq(&ehci->lock);
>> >> >         ehci->shutdown = true;
>> >> >         ehci->rh_state = EHCI_RH_STOPPING;
>> >>
>> >>
>> >> Should we also not check this in ehci_suspend and ehci_resume?  If I
>> >> do suspend/resume, it crashes in a similar manner.  I know this goes
>> >> beyond the problem scope of the patch.  Perhaps I should send in an
>> >> additional patch with the code?
>> >>
>> >> Are there any other places in the ehci-hcd where this needs to be checked?
>> >
>> > Really, this is an indication that the problem lies not in ehci-hcd but
>> > rather in the platform glue code.  The platform code allows itself to
>> > be registered as the driver of the controller device but does not
>> > initialize the ehci-hcd parts.
>> >
>> > Neither ehci_suspend nor ehci_resume is called directly by the driver
>> > core; the calls all have to pass through the glue code.  So maybe the
>> > glue layer needs to be careful about invoking these routines in
>> > ehci-hcd before ehci-hcd has been initialized.
>>
>> That's a good point.  Perhaps all of this should be in the glue,
>> including the shutdown case.
>
> Many of the platform glue files set usb_hcd_platform_shutdown() as
> their shutdown callback, which makes it impossible for them to include
> a controller-specific test.

Yes, I just found this out for myself.  So in that specific case, it
makes sense to have the check within the ehci-hcd.  Whereas in the
glue driver, the suspend/resume use direct calls to
ehci_suspend/resume.

I'll send along a ehci-msm patch to address the issues i see with
suspend/resume.

Thanks!

Andy

WARNING: multiple messages have this Message-ID (diff)
From: andy.gross@linaro.org (Andy Gross)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] usb: echi-hcd: Add ehci_setup check before echi_shutdown
Date: Fri, 20 May 2016 11:09:00 -0500	[thread overview]
Message-ID: <CAPBZ5Qe3EbTKSihugJ-b8HwvPyQtPXFXVyaeBjY0takuzn+d4A@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1605201156220.1938-100000@iolanthe.rowland.org>

On 20 May 2016 at 10:57, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 20 May 2016, Andy Gross wrote:
>
>> On 20 May 2016 at 09:31, Alan Stern <stern@rowland.harvard.edu> wrote:
>> > On Thu, 19 May 2016, Andy Gross wrote:
>> >
>> >> On 19 May 2016 at 05:12, Srinivas Kandagatla
>> >> <srinivas.kandagatla@linaro.org> wrote:
>> >>
>> >> <snip>
>> >>
>> >> > +++ b/drivers/usb/host/ehci-hcd.c
>> >> > @@ -368,6 +368,15 @@ static void ehci_shutdown(struct usb_hcd *hcd)
>> >> >  {
>> >> >         struct ehci_hcd *ehci = hcd_to_ehci(hcd);
>> >> >
>> >> > +       /**
>> >> > +        * Protect the system from crashing at system shutdown in cases where
>> >> > +        * usb host is not added yet from OTG controller driver.
>> >> > +        * As ehci_setup() not done yet, so stop accessing registers or
>> >> > +        * variables initialized in ehci_setup()
>> >> > +        */
>> >> > +       if (!ehci->sbrn)
>> >> > +               return;
>> >> > +
>> >> >         spin_lock_irq(&ehci->lock);
>> >> >         ehci->shutdown = true;
>> >> >         ehci->rh_state = EHCI_RH_STOPPING;
>> >>
>> >>
>> >> Should we also not check this in ehci_suspend and ehci_resume?  If I
>> >> do suspend/resume, it crashes in a similar manner.  I know this goes
>> >> beyond the problem scope of the patch.  Perhaps I should send in an
>> >> additional patch with the code?
>> >>
>> >> Are there any other places in the ehci-hcd where this needs to be checked?
>> >
>> > Really, this is an indication that the problem lies not in ehci-hcd but
>> > rather in the platform glue code.  The platform code allows itself to
>> > be registered as the driver of the controller device but does not
>> > initialize the ehci-hcd parts.
>> >
>> > Neither ehci_suspend nor ehci_resume is called directly by the driver
>> > core; the calls all have to pass through the glue code.  So maybe the
>> > glue layer needs to be careful about invoking these routines in
>> > ehci-hcd before ehci-hcd has been initialized.
>>
>> That's a good point.  Perhaps all of this should be in the glue,
>> including the shutdown case.
>
> Many of the platform glue files set usb_hcd_platform_shutdown() as
> their shutdown callback, which makes it impossible for them to include
> a controller-specific test.

Yes, I just found this out for myself.  So in that specific case, it
makes sense to have the check within the ehci-hcd.  Whereas in the
glue driver, the suspend/resume use direct calls to
ehci_suspend/resume.

I'll send along a ehci-msm patch to address the issues i see with
suspend/resume.

Thanks!

Andy

  reply	other threads:[~2016-05-20 16:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-19 10:12 [PATCH] usb: echi-hcd: Add ehci_setup check before echi_shutdown Srinivas Kandagatla
2016-05-19 10:12 ` Srinivas Kandagatla
2016-05-19 14:06 ` Alan Stern
2016-05-19 14:06   ` Alan Stern
2016-05-19 20:49 ` Andy Gross
2016-05-19 20:49   ` Andy Gross
2016-05-19 21:20 ` Andy Gross
2016-05-19 21:20   ` Andy Gross
2016-05-20 14:31   ` Alan Stern
2016-05-20 14:31     ` Alan Stern
2016-05-20 15:33     ` Andy Gross
2016-05-20 15:33       ` Andy Gross
2016-05-20 15:57       ` Alan Stern
2016-05-20 15:57         ` Alan Stern
2016-05-20 16:09         ` Andy Gross [this message]
2016-05-20 16:09           ` Andy Gross
2016-05-30 13:20 ` Pramod Gurav
2016-05-30 13:20   ` Pramod Gurav

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPBZ5Qe3EbTKSihugJ-b8HwvPyQtPXFXVyaeBjY0takuzn+d4A@mail.gmail.com \
    --to=andy.gross@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.