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=-4.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 7C3C5C2D0E7 for ; Wed, 25 Mar 2020 21:28:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 509F020719 for ; Wed, 25 Mar 2020 21:28:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585171700; bh=5K2E5w4ZAxUttugnFuAHbhicY1xyCyoKDUNqdcoJPBs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=B3/2zrGx8IxpEk29UFUmDN625+cLDeindETcNXULt5msvhid9bKmfvNcNaQlmH/R8 f+N3fjc1TnmkaBrG0B8brHVs9aONLawwycKP7Cdwl/Sh648XKbayviRVKlL8NUHm7c oA86aSzydV+tG4XgPnlEmXYmzFIu9ZHBV7hUtR/Y= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727469AbgCYV2T (ORCPT ); Wed, 25 Mar 2020 17:28:19 -0400 Received: from mail-oi1-f196.google.com ([209.85.167.196]:44175 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727351AbgCYV2T (ORCPT ); Wed, 25 Mar 2020 17:28:19 -0400 Received: by mail-oi1-f196.google.com with SMTP id v134so3548502oie.11; Wed, 25 Mar 2020 14:28:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kMnQUhHsMUqkwZSy38drjBgyagt4hVHMEAtOg07ZQq8=; b=X3OOwSWwF9exeyEaukuWVnthtnuCWkdj/NhnzgeqrAmzkzlpU2fT/VytfClj4jEFGJ G5o4gBQdeEgLIC78xTNGk+ErRE3NP+lWB3eKoLn+VkXHURccNbfl2IDQooDC0N2FqxpP 1rSlrh4Lfm6leOlBEFzcsfCAw1tbbHxp731gtzTNtDy02Owu+V9KHo1qO7+HnfTeIrb+ jF8ouIms+DFnG0IazntOwmamZ+brj1YNWbwLkf1X6oRBRU0OMbDQ5r25hjyWp/LbPxQk K1D7JZg1/HWdNehhcl35Poa+DQfvSFhSXkg3mqICk3/nxMCSvt6eki071DUhP8sx2BYE kAfQ== X-Gm-Message-State: ANhLgQ1pUVY2M0FtB2Yw1Dhc97q49m1Z29krYAT8gHNAYsSASS5uAPUW Sl3yUdcc7Ae7hb0le3d1rzRpVC7rBVQSt94Tcds= X-Google-Smtp-Source: ADFU+vvzKkZOnTfMVU8Sfwv/GSImVsJgGRvYaaTVayXvuwf+AsGAEnB58orlXTBPHO173efwnlO+Y+mX9i6UdjFRaiI= X-Received: by 2002:aca:f07:: with SMTP id 7mr2269427oip.68.1585171698442; Wed, 25 Mar 2020 14:28:18 -0700 (PDT) MIME-Version: 1.0 References: <20200325150017.xhabucfo3v6i234o@e107158-lin> In-Reply-To: From: "Rafael J. Wysocki" Date: Wed, 25 Mar 2020 22:28:06 +0100 Message-ID: Subject: Re: lockdep warning in urb.c:363 usb_submit_urb To: Alan Stern Cc: Qais Yousef , "Rafael J. Wysocki" , Oliver Neukum , Greg Kroah-Hartman , USB list , Linux-pm mailing list , Kernel development list Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 25, 2020 at 9:49 PM Alan Stern wrote: > > On Wed, 25 Mar 2020, Qais Yousef wrote: > > > Thanks for all the hints Alan. > > > > I think I figured it out, the below patch seems to fix it for me. Looking > > at other drivers resume functions it seems we're missing the > > pm_runtime_disable()->set_active()->enable() dance. Doing that fixes the > > warning and the dev_err() in driver/base/power. > > Ah, yes. This should have been added years ago; guess I forgot. :-( > > > I don't see xhci-plat.c doing that, I wonder if it needs it too. > > > > I'm not well versed about the details and the rules here. So my fix could be > > a hack, though it does seem the right thing to do. > > > > I wonder why the power core doesn't handle this transparently.. > > Initially, we didn't want the PM core to do this automatically because > we thought some devices might want to remain runtime-suspended > following a system resume, and only the device driver would know what > to do. > > Raphael, now that we have the direct_complete mechanism, can we revisit > this? Should the PM core automatically call pm_runtime_set_active() if > dev->power.direct_complete isn't set? Perhaps in device_resume_early() > prior to the pm_runtime_enable() call? > > It's possible we discussed this and decided against it at the time when > direct_complete was added, but if so I don't remember what was said. Me neither. :-) That said complexity has grown since then and there are the DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED flags that can be used to control that behavior to some extent. Setting DPM_FLAG_SMART_SUSPEND alone, in particular, causes pm_runtime_set_active() to be called at the noirq stage of device resume either by the core or by bus types (e.g. PCI) etc. It looks like ohci-platform might use DPM_FLAG_SMART_SUSPEND, but I need to take a closer look at that (possibly later this week). Cheers! > > > diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c > > index 7addfc2cbadc..eb92c8092fae 100644 > > --- a/drivers/usb/host/ohci-platform.c > > +++ b/drivers/usb/host/ohci-platform.c > > @@ -299,6 +299,10 @@ static int ohci_platform_resume(struct device *dev) > > } > > > > ohci_resume(hcd, false); > > + > > + pm_runtime_disable(dev); > > + pm_runtime_set_active(dev); > > + pm_runtime_enable(dev); > > return 0; > > } > > #endif /* CONFIG_PM_SLEEP */ > > > > > > Thanks > > > > -- > > Qais Yousef > >