From: Alan Stern <stern@rowland.harvard.edu>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
USB list <linux-usb@vger.kernel.org>,
Kernel development list <linux-kernel@vger.kernel.org>,
Michael Grzeschik <m.grzeschik@pengutronix.de>,
<stable@vger.kernel.org>
Subject: Re: [PATCH] usb: chipidea: host: Disable port power only if previously enabled
Date: Wed, 1 Jan 2020 21:30:34 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.44L0.2001012117220.30059-100000@netrider.rowland.org> (raw)
In-Reply-To: <1fd709ce-04a3-4183-da39-c1921ec69ce7@roeck-us.net>
On Wed, 1 Jan 2020, Guenter Roeck wrote:
> On 12/29/19 8:40 AM, Alan Stern wrote:
> > On Sun, 29 Dec 2019, Guenter Roeck wrote:
> >
> >> On Sat, Dec 28, 2019 at 02:33:01PM -0500, Alan Stern wrote:
> >>>
> >>> Let's try a slightly different approach. What happens with this patch?
> >>>
> >>> Alan Stern
> >>>
> >>>
> >>> Index: usb-devel/drivers/usb/core/hub.c
> >>> ===================================================================
> >>> --- usb-devel.orig/drivers/usb/core/hub.c
> >>> +++ usb-devel/drivers/usb/core/hub.c
> >>> @@ -1065,6 +1065,7 @@ static void hub_activate(struct usb_hub
> >>> if (type == HUB_INIT) {
> >>> delay = hub_power_on_good_delay(hub);
> >>>
> >>> + hub->power_bits[0] = ~0UL; /* All ports on */
> >>> hub_power_on(hub, false);
> >>> INIT_DELAYED_WORK(&hub->init_work, hub_init_func2);
> >>> queue_delayed_work(system_power_efficient_wq,
> >>>
> >>
> >> That doesn't make a difference - the traceback is still seen with this patch
> >> applied.
> >
> > Can you trace what's going on? Does this code pathway now end up
> > calling ehci_port_power() for each root-hub port, and from there down
> > into the chipidea driver? If not, can you find where it gets
> > sidetracked?
> >
>
> A complete traceback is attached below, so, yes, I think it is safe to say that
> ehci_port_power() is called unconditionally for each root-hub port on shutdown.
I was really asking about hub activation and powering-up, but you found
the answer to that too, so okay.
> The only mystery to me was why ehci_port_power() isn't called to enable port power
> when the port comes up. As it turns out, HCS_PPC(ehci->hcs_params) is false on my
> simulated hardware, and thus ehci_port_power(..., true) is not called from
> ehci_hub_control().
>
> Given that, it may well be that the problem is not seen on "real" hardware,
> at least not with real mcimx7d-sabre hardware, if the hub on that hardware does
> support power control. To test this idea, I modified qemu to claim hub power
> control support by setting the "power control support" capability bit. With
> that, the traceback is gone.
>
> Any suggestion how to proceed ?
Given that HCS_PPC(ehci_hcs_params) is false, I would say that
ehci_turn_off_all_ports() shouldn't call ehci_port_power(). You should
add that test there. (Although to tell the truth, I'm not really sure
we need to test HCS_PPC anywhere...)
Did you check what happens without the patch I sent you? I would like
to know if that patch really does make a difference. If we don't send
the Set-Port-Feature(power) request during hub activation without the
patch then it does need to be merged.
Alan Stern
next prev parent reply other threads:[~2020-01-02 2:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-26 15:57 [PATCH] usb: chipidea: host: Disable port power only if previously enabled Guenter Roeck
2019-12-26 19:46 ` Alan Stern
2019-12-27 1:45 ` Peter Chen
2019-12-27 14:47 ` Alan Stern
2019-12-27 16:55 ` Guenter Roeck
2019-12-28 19:33 ` Alan Stern
2019-12-29 16:28 ` Guenter Roeck
2019-12-29 16:40 ` Alan Stern
2019-12-30 0:57 ` Guenter Roeck
2020-01-01 22:09 ` Guenter Roeck
2020-01-02 2:30 ` Alan Stern [this message]
2019-12-27 1:45 ` 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=Pine.LNX.4.44L0.2001012117220.30059-100000@netrider.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=m.grzeschik@pengutronix.de \
--cc=stable@vger.kernel.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 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).