linux-kernel - Re: [PATCH] usb: chipidea: host: Disable port power only if previously enabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 1 Jan 2020 21:30:34 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Guenter Roeck <linux@...ck-us.net>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        USB list <linux-usb@...r.kernel.org>,
        Kernel development list <linux-kernel@...r.kernel.org>,
        Michael Grzeschik <m.grzeschik@...gutronix.de>,
        <stable@...r.kernel.org>
Subject: Re: [PATCH] usb: chipidea: host: Disable port power only if previously
 enabled

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