From: Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org>
To: Peter Geis <pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] usb: chipidea: tegra: fix hardlock with invalid dr mode
Date: Tue, 4 Feb 2020 07:44:20 +0000 [thread overview]
Message-ID: <20200204074419.GA6681@b29397-desktop> (raw)
In-Reply-To: <CAMdYzYrbvsTunwxJLcC_-ZhczsQfyDLOjTnZ+eorb325qO-QhA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 20-02-03 12:22:37, Peter Geis wrote:
> > diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c b/drivers/usb/chipidea/ci_hdrc_tegra.c
> > index 0c9911d44ee5..5d85363ad0f4 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_tegra.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
> > @@ -95,6 +95,7 @@ static int tegra_udc_probe(struct platform_device *pdev)
> > udc->data.flags = soc->flags;
> > udc->data.usb_phy = udc->phy;
> > udc->data.capoffset = DEF_CAPOFFSET;
> > + udc->data.dr_mode = USB_DR_MODE_PERIPHERAL;
> >
> > udc->dev = ci_hdrc_add_device(&pdev->dev, pdev->resource,
> > pdev->num_resources, &udc->data);
>
> I do not wish to set the dr_mode manually, since this could break
> things on devices I do not own.
> Future work is needed to address the tegra_udc capabilities, as well
> as fully correct the hang issue.
> This patch merely aims to fix a corner case.
>
> >
> > > They also seem to be missing the extcon phandle, which means automatic
> > > mode switching is not possible?
> > >
> > > >
> > > > But one thing I could not understand, if the driver doesn't support
> > > > dual-role, how could you do manual role switch?
> > >
> > > Manual role switching is conducted via debugfs,
> > > /sys/kernel/debug/usb/ci_hdrc.0/role
> > >
> > > >
> > > > >
> > > > > Detect this state by checking for the extcon phandle when dual role mode
> > > > > is set to otg.
> > > > > If it doesn't exist request the driver to only enable manual role
> > > > > switching.
> > > > >
> > > > > Fixes: dfebb5f ("usb: chipidea: Add support for Tegra20/30/114/124")
> > > > > Signed-off-by: Peter Geis <pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > ---
> > > > > drivers/usb/chipidea/ci_hdrc_tegra.c | 7 +++++++
> > > > > 1 file changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c b/drivers/usb/chipidea/ci_hdrc_tegra.c
> > > > > index 7455df0ede49..2f6f6ce3e8f5 100644
> > > > > --- a/drivers/usb/chipidea/ci_hdrc_tegra.c
> > > > > +++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
> > > > > @@ -89,6 +89,13 @@ static int tegra_udc_probe(struct platform_device *pdev)
> > > > > udc->data.usb_phy = udc->phy;
> > > > > udc->data.capoffset = DEF_CAPOFFSET;
> > > > >
> > > > > + /* check the dual mode and warn about bad configurations */
> > > > > + if (usb_get_dr_mode(&pdev->dev) == USB_DR_MODE_OTG &&
> > > > > + !of_property_read_bool(pdev->dev.of_node, "extcon")) {
> > > > > + dev_warn(&pdev->dev, "no extcon registered, otg unavailable");
> > > > > + udc->data.flags |= CI_HDRC_DUAL_ROLE_NOT_OTG;
> > > > > + }
> > > > > +
> > > >
> > > > The CI_HDRC_DUAL_ROLE_NOT_OTG flag may not be suitable here, please see
> > > > comments for it.
> > >
> > > I've dug around the various mailing lists and I fail to find any
> > > reference to why this is not a valid use case.
> > > The commit message specifically references dual role capable devices
> > > without proper otg implementations, such as missing the otgsc
> > > register.
> > >
> > > My current use case is the Ouya, which deadlocks the kernel durning
> > > probe if the otg capable usb controller is set to dr_mode=otg.
> > > It works with this flag set.
> > > Unfortunately there isn't a property for dr_mode set to non_otg_dr_mode.
> > >
> > > I found a post stating that the driver blindly touches registers in
> > > otg mode, which leads to the deadlock if those registers are read only
> > > or non-existent,
> > > Eventually someone should look into why this deadlock occurs and make
> > > a proper fix that applies to all users.
> > > Unfortunately I do not have the knowledge yet to accomplish this task.
> > >
> > > With some simple modifications to the tegra_udc driver it is possible
> > > to get host mode working, vice using the tegra-ehci driver.
> > > At this point role switch works
> > >
> > > I also managed to move all of the functionality of the tegra-ehci
> > > driver into the tegra-udc driver.
> > > Unfortunately it doesn't behave correctly under some cases, so I never
> > > submitted it.
> > >
> > > Do you have a recommendation for handling this?
> >
> > If you would like adding host function in chipidea driver for tegra, and
> > want dual-role switch to work, first, you may need to know which
> > dual-role switch you need:
> > - Through controller's id and vbus pins
> > - Through extcon, eg,GPIO.
> > - Through usb-role-switch class, eg, Type-C controller
> > - Through sysfs, /sys/bus/platform/devices/ci_hdrc.0/role
> >
> > The first three are automatically switch, the last one is manually.
> > Current chipidea core should support all above switches, maybe there are
> > some limitations for them, the fixes are welcome.
>
> AFAIK reading through the comments, the chipidea driver intended to
> exclusively use extcon for automatic role switching, please correct me
> if I'm wrong here.
No, extcon is supported.
> USB-C support is not a likely scenario, as currently the chipidea
> driver only supports usb 2.0.
USB-C is a connector, not related to USB HW revision. For USB 2.0
USB-C solution, there is no SS TX/RX connected on connector.
>
> >
> > Second, you may check if touch otgsc will hang or deadlock the system.
> > If you can't touch otgsc when portsc.phcd = 0, you may need the flag
> > CI_HDRC_DUAL_ROLE_NOT_OTG, afaik, few SoCs can't touch otgsc if it
> > supports dual-role.
>
> I added some traces to the driver, and it doesn't actually appear to
> be a register read/write that is breaking things. (Not directly
> anyways).
> The hang occurs after it enumerates the usb gadgets and hub.
> Still trying to track down exactly where the hang occurs.
>
Try to see if it is related to runtime power management.
--
Thanks,
Peter Chen
WARNING: multiple messages have this Message-ID (diff)
From: Peter Chen <peter.chen@nxp.com>
To: Peter Geis <pgwipeout@gmail.com>
Cc: Thierry Reding <treding@nvidia.com>,
Dmitry Osipenko <digetx@gmail.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH] usb: chipidea: tegra: fix hardlock with invalid dr mode
Date: Tue, 4 Feb 2020 07:44:20 +0000 [thread overview]
Message-ID: <20200204074419.GA6681@b29397-desktop> (raw)
In-Reply-To: <CAMdYzYrbvsTunwxJLcC_-ZhczsQfyDLOjTnZ+eorb325qO-QhA@mail.gmail.com>
On 20-02-03 12:22:37, Peter Geis wrote:
> > diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c b/drivers/usb/chipidea/ci_hdrc_tegra.c
> > index 0c9911d44ee5..5d85363ad0f4 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_tegra.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
> > @@ -95,6 +95,7 @@ static int tegra_udc_probe(struct platform_device *pdev)
> > udc->data.flags = soc->flags;
> > udc->data.usb_phy = udc->phy;
> > udc->data.capoffset = DEF_CAPOFFSET;
> > + udc->data.dr_mode = USB_DR_MODE_PERIPHERAL;
> >
> > udc->dev = ci_hdrc_add_device(&pdev->dev, pdev->resource,
> > pdev->num_resources, &udc->data);
>
> I do not wish to set the dr_mode manually, since this could break
> things on devices I do not own.
> Future work is needed to address the tegra_udc capabilities, as well
> as fully correct the hang issue.
> This patch merely aims to fix a corner case.
>
> >
> > > They also seem to be missing the extcon phandle, which means automatic
> > > mode switching is not possible?
> > >
> > > >
> > > > But one thing I could not understand, if the driver doesn't support
> > > > dual-role, how could you do manual role switch?
> > >
> > > Manual role switching is conducted via debugfs,
> > > /sys/kernel/debug/usb/ci_hdrc.0/role
> > >
> > > >
> > > > >
> > > > > Detect this state by checking for the extcon phandle when dual role mode
> > > > > is set to otg.
> > > > > If it doesn't exist request the driver to only enable manual role
> > > > > switching.
> > > > >
> > > > > Fixes: dfebb5f ("usb: chipidea: Add support for Tegra20/30/114/124")
> > > > > Signed-off-by: Peter Geis <pgwipeout@gmail.com>
> > > > > ---
> > > > > drivers/usb/chipidea/ci_hdrc_tegra.c | 7 +++++++
> > > > > 1 file changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c b/drivers/usb/chipidea/ci_hdrc_tegra.c
> > > > > index 7455df0ede49..2f6f6ce3e8f5 100644
> > > > > --- a/drivers/usb/chipidea/ci_hdrc_tegra.c
> > > > > +++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
> > > > > @@ -89,6 +89,13 @@ static int tegra_udc_probe(struct platform_device *pdev)
> > > > > udc->data.usb_phy = udc->phy;
> > > > > udc->data.capoffset = DEF_CAPOFFSET;
> > > > >
> > > > > + /* check the dual mode and warn about bad configurations */
> > > > > + if (usb_get_dr_mode(&pdev->dev) == USB_DR_MODE_OTG &&
> > > > > + !of_property_read_bool(pdev->dev.of_node, "extcon")) {
> > > > > + dev_warn(&pdev->dev, "no extcon registered, otg unavailable");
> > > > > + udc->data.flags |= CI_HDRC_DUAL_ROLE_NOT_OTG;
> > > > > + }
> > > > > +
> > > >
> > > > The CI_HDRC_DUAL_ROLE_NOT_OTG flag may not be suitable here, please see
> > > > comments for it.
> > >
> > > I've dug around the various mailing lists and I fail to find any
> > > reference to why this is not a valid use case.
> > > The commit message specifically references dual role capable devices
> > > without proper otg implementations, such as missing the otgsc
> > > register.
> > >
> > > My current use case is the Ouya, which deadlocks the kernel durning
> > > probe if the otg capable usb controller is set to dr_mode=otg.
> > > It works with this flag set.
> > > Unfortunately there isn't a property for dr_mode set to non_otg_dr_mode.
> > >
> > > I found a post stating that the driver blindly touches registers in
> > > otg mode, which leads to the deadlock if those registers are read only
> > > or non-existent,
> > > Eventually someone should look into why this deadlock occurs and make
> > > a proper fix that applies to all users.
> > > Unfortunately I do not have the knowledge yet to accomplish this task.
> > >
> > > With some simple modifications to the tegra_udc driver it is possible
> > > to get host mode working, vice using the tegra-ehci driver.
> > > At this point role switch works
> > >
> > > I also managed to move all of the functionality of the tegra-ehci
> > > driver into the tegra-udc driver.
> > > Unfortunately it doesn't behave correctly under some cases, so I never
> > > submitted it.
> > >
> > > Do you have a recommendation for handling this?
> >
> > If you would like adding host function in chipidea driver for tegra, and
> > want dual-role switch to work, first, you may need to know which
> > dual-role switch you need:
> > - Through controller's id and vbus pins
> > - Through extcon, eg,GPIO.
> > - Through usb-role-switch class, eg, Type-C controller
> > - Through sysfs, /sys/bus/platform/devices/ci_hdrc.0/role
> >
> > The first three are automatically switch, the last one is manually.
> > Current chipidea core should support all above switches, maybe there are
> > some limitations for them, the fixes are welcome.
>
> AFAIK reading through the comments, the chipidea driver intended to
> exclusively use extcon for automatic role switching, please correct me
> if I'm wrong here.
No, extcon is supported.
> USB-C support is not a likely scenario, as currently the chipidea
> driver only supports usb 2.0.
USB-C is a connector, not related to USB HW revision. For USB 2.0
USB-C solution, there is no SS TX/RX connected on connector.
>
> >
> > Second, you may check if touch otgsc will hang or deadlock the system.
> > If you can't touch otgsc when portsc.phcd = 0, you may need the flag
> > CI_HDRC_DUAL_ROLE_NOT_OTG, afaik, few SoCs can't touch otgsc if it
> > supports dual-role.
>
> I added some traces to the driver, and it doesn't actually appear to
> be a register read/write that is breaking things. (Not directly
> anyways).
> The hang occurs after it enumerates the usb gadgets and hub.
> Still trying to track down exactly where the hang occurs.
>
Try to see if it is related to runtime power management.
--
Thanks,
Peter Chen
next prev parent reply other threads:[~2020-02-04 7:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-27 2:35 [PATCH] usb: chipidea: tegra: fix hardlock with invalid dr mode Peter Geis
2020-01-27 2:35 ` Peter Geis
[not found] ` <20200127023548.27107-1-pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-01-27 7:17 ` Greg KH
2020-01-27 7:17 ` Greg KH
[not found] ` <20200127071758.GD279449-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2020-01-27 15:25 ` Peter Geis
2020-01-27 15:25 ` Peter Geis
[not found] ` <CAMdYzYqctkfqhHN0-WDvX9kKdXH-AVir193SpcrR_t3K=VN=0w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-01-27 15:38 ` Dmitry Osipenko
2020-01-27 15:38 ` Dmitry Osipenko
2020-01-31 5:27 ` Peter Chen
2020-01-31 5:27 ` Peter Chen
2020-01-31 20:43 ` Peter Geis
2020-01-31 20:43 ` Peter Geis
[not found] ` <CAMdYzYqwz9HLsjvc1hDmovzWqiV_Vswe57d_gWhwBnvb2aNPyQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-02-01 6:13 ` Peter Chen
2020-02-01 6:13 ` Peter Chen
2020-02-03 17:22 ` Peter Geis
2020-02-03 17:22 ` Peter Geis
[not found] ` <CAMdYzYrbvsTunwxJLcC_-ZhczsQfyDLOjTnZ+eorb325qO-QhA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-02-04 7:44 ` Peter Chen [this message]
2020-02-04 7:44 ` Peter Chen
2020-02-04 14:35 ` Peter Geis
2020-02-04 14:35 ` Peter Geis
[not found] ` <CAMdYzYo8Vgw8h=LtfLnQNF4j-rVzgKJTp1hCyf7BFKrdhAhAHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-02-05 11:17 ` Peter Chen
2020-02-05 11:17 ` Peter Chen
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=20200204074419.GA6681@b29397-desktop \
--to=peter.chen-3arqi8vn3tc@public.gmane.org \
--cc=digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
/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.