Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1007842ybb; Wed, 25 Mar 2020 13:50:20 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsVcfIUX8l5YsyrWjBUAoeLLOYMOwvz+E96Jq8MpFpYv3Q0ghQAbVKFHhBpXymRR7kmF6Ti X-Received: by 2002:aca:d44d:: with SMTP id l74mr3942441oig.83.1585169420442; Wed, 25 Mar 2020 13:50:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585169420; cv=none; d=google.com; s=arc-20160816; b=e2S+bZzM4zIPS2HcgPLq2FvyJWcfWRUCQYK5oDtbVQyxYRwa9LdyHxlWU49c6K1O1Y rwX1zPbnCl3oYYq1LeHTgrV8ZTxTpDVYwYmu278X5cYrs/YqyCFxvVN1lHF7wEuM8fzi MIEKFVd6sY6SpIrfEY0dpRSNige3eQ1dCniLBJjdYmsIX+kNm9vi9BzTnTKOZIvqJ1xm sfwgRmBRDi4Ymq50DKUxGFOGAotHLu4SXEqGYyiyflVeMOUqvho+F1tHAwmmKaBbClXK UKX1Eyqvv4xhhkGCJozn7ZAAZKrYWiD1dIZO80lrQo6101b30eV3Sp/6t7GkgId3RrLA PIhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=040884DRvyjy0Ka+cm0WAtOkAUZkbsjDnWQ6gprgk90=; b=ObyztNcL/bdcLz8mgqCd2qmFVdEhC02t/7b+VE15Raltc9FN21Mepp69Zul34+s/5g tCm+nDIdMjBB2SR87N23qaeuFZ9vIOccno2Ox0FYnO7CYfFK2smiMfJ/rcZwZDXXl3FH 1QEyT0SZYX8ExjGOdxI1LvKQ2wy1MZ+5tPobswnqxq/QFshPanZ2dZKSHl8yGxluHBxk MvX4fCM6jDu8iI8/jjwR1hmpjU0jtBQdygebRUEJrcM95qb4uwSTfPv+vP7mvx7QJYo9 Oz9Aodq7C1MLybnEWSgs0vcJLa7f9yXhOGDGHzRcZZVEmI4foZD5+V93b8ZFls0Gv2nv z3GA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n63si73363oia.144.2020.03.25.13.50.06; Wed, 25 Mar 2020 13:50:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727466AbgCYUtJ (ORCPT + 99 others); Wed, 25 Mar 2020 16:49:09 -0400 Received: from netrider.rowland.org ([192.131.102.5]:49877 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1727399AbgCYUtI (ORCPT ); Wed, 25 Mar 2020 16:49:08 -0400 Received: (qmail 11099 invoked by uid 500); 25 Mar 2020 16:49:07 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Mar 2020 16:49:07 -0400 Date: Wed, 25 Mar 2020 16:49:07 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Qais Yousef , "Rafael J. Wysocki" cc: Oliver Neukum , Greg Kroah-Hartman , USB list , Linux-pm mailing list , Kernel development list Subject: Re: lockdep warning in urb.c:363 usb_submit_urb In-Reply-To: <20200325150017.xhabucfo3v6i234o@e107158-lin> 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, 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. Alan Stern > 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