From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3D0AC2D0DE for ; Thu, 2 Jan 2020 02:30:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B8D2520866 for ; Thu, 2 Jan 2020 02:30:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727551AbgABCaf (ORCPT ); Wed, 1 Jan 2020 21:30:35 -0500 Received: from netrider.rowland.org ([192.131.102.5]:38463 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1727509AbgABCaf (ORCPT ); Wed, 1 Jan 2020 21:30:35 -0500 Received: (qmail 30587 invoked by uid 500); 1 Jan 2020 21:30:34 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Jan 2020 21:30:34 -0500 Date: Wed, 1 Jan 2020 21:30:34 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Guenter Roeck cc: Greg Kroah-Hartman , USB list , Kernel development list , Michael Grzeschik , Subject: Re: [PATCH] usb: chipidea: host: Disable port power only if previously enabled In-Reply-To: <1fd709ce-04a3-4183-da39-c1921ec69ce7@roeck-us.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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