From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f54.google.com (mail-dl1-f54.google.com [74.125.82.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 11CB92DAFC7 for ; Thu, 22 Jan 2026 17:49:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769104199; cv=none; b=uZxI0YiIluxwm7XlPVGRsATVytAQFYykUyGdeHFM2MJjGmcjZcexL+BpbYAjiWCu8zeLgI3cjwq3qgy8lTSxRqDOiBCrRyNvT5u+J+RDcJsuzBfi0ce/4IRTX0LXdTH5dkIXfuYMZVh4mx0SwwGnZfsybLIq58TUO2b4c5Pv9sU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769104199; c=relaxed/simple; bh=Fy3XirdW3o4O+QTo79Ey4FXxvk1xhYIcaqrUFj49MDY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fpmTjpRYDaa/6m7NYN9L7q4kWbrujP4hBJpUD2MP14y4jeSUabtWpRsIVUuIbKYNihrT7v0okWM/be1+4DY4moH+a+pUVyYA2ynrHbh3kxmYq99jF7oPOhM0KR32WFUWTQSxUkaFOkyBQ0eicMuO+ohMsKq66HIT769cMm7azjQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=FUnbEHcI; arc=none smtp.client-ip=74.125.82.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="FUnbEHcI" Received: by mail-dl1-f54.google.com with SMTP id a92af1059eb24-1233b953bebso2763303c88.1 for ; Thu, 22 Jan 2026 09:49:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1769104183; x=1769708983; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=Cts/XmrIsitUkgW4W0CPI9+Y5A4oJrjzrlI5Y9vqVAc=; b=FUnbEHcINfzrYaeQhEuTNy4kGslu9mp46Mq5Qinf3z8vY1geZH0osl34Mtmw3GXf35 rDX3D+99W8wn0o1SVPrYJHun4mo5OzD7LC8w7Rn3I6h82TW8FPRszv7Y5RwWBzj8oEzd SZJrnu5rkwXwao29Wmo3IuwpMzm5OQr4pToyI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769104183; x=1769708983; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Cts/XmrIsitUkgW4W0CPI9+Y5A4oJrjzrlI5Y9vqVAc=; b=EWHMsTEKEnilYGwCKGMSeXKhFTa/vbyBimey7ZbsHOErowK+ElKbqbxErkyEI5jPpZ 50rA7B5+wis4A4nkV6PHYp9oj+uNHjU1gO4+dUmpE0tkER9tTMR43HELZLcerl+BeaTW 2wYEOL/P6D0BrJPIvaxe5I14Z1Ni2CXAhlbtG23+aB6DqR9d/dPK/vMGe3KFc/XZj7L3 3UezNL2cVztqtBSGPWKh4kzCZTQOKbUMU76ECb5QtaoJqb3f04apPjtsttRpFNhl+Qhi YZJVTLzRR70HrwVmO+O5a/4nae6K1u25MgjB6a8YV6DW015x4OOiY7r58lrQh8gTfkWt JXeQ== X-Forwarded-Encrypted: i=1; AJvYcCWKhpGSWeEGSEzLpliIN12wLpC5gNpEDU7a9DSx3TAJQn9qYGkGSHlA7VzAbzF5zpZ4zyX5v5HDCQPEOc0=@vger.kernel.org X-Gm-Message-State: AOJu0YwPDZIsNHeZDHSzZdFCFo7iYOw6l88IyHOq48UmWtW5A5dgbHjD HcWyeGc2EdiyUheDXTHbs0DUmEXuKr6+R7ZZF2Zyn/aM7qrrGpUMwu3IsiWaTVFYOw== X-Gm-Gg: AZuq6aKC6ddiiubBbJ3jw09ahWWzPH07SYgmg4v8mr6yU3qP8Gt0eGvU4GwA3tlHb3w WYV9AnL6IIIZf1yekLNf9PqLq2HCkeq/uXbco+w6742uY2pl916wLsNvWKarhB29bKwVldD0Ova SwunCS+9bjQJeMZvPngQgmbZx58MVXvdQl0tnKTMLEtIaaroGyFEiFysYrPuS+oXYCliG8/x74q Lp/3QzV6oUYY/u00hXRnI+uFHeDM5Bv94TFG8a//J0mP054K/l3UZ2bCuaLWq+z/VgXj/Wgerer 0bongrYZk63yyIGatO4gq1gADVdIW6yl/+NKWyHYJ2wDp3jdAtLMaKdUrzRq7fOGKFfXbhyvLnZ aJLRgMTwRD+YQV7BzUQfcHOBcq/PbIfcBXQ6We+C4bmeXs5glojKzouIe4Yq4GVZbtglohLHKB1 lRCbqMvupOrxBJLTp4hv7n5lZi8zb6KeK8biN1d2Y1HQ4OgsUzCw== X-Received: by 2002:a05:7022:660c:b0:119:e56b:c75a with SMTP id a92af1059eb24-1247dbf8d14mr61525c88.31.1769104183224; Thu, 22 Jan 2026 09:49:43 -0800 (PST) Received: from localhost ([2a00:79e0:2e7c:8:f995:553f:5ab5:f684]) by smtp.gmail.com with UTF8SMTPSA id a92af1059eb24-1247d997f7bsm197174c88.11.2026.01.22.09.49.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jan 2026 09:49:42 -0800 (PST) Date: Thu, 22 Jan 2026 09:49:41 -0800 From: Brian Norris To: "Rafael J. Wysocki" Cc: Marek Szyprowski , Bjorn Helgaas , Bjorn Helgaas , Lukas Wunner , linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, Ilpo =?iso-8859-1?Q?J=E4rvinen?= Subject: Re: [PATCH v4] PCI/PM: Prevent runtime suspend before devices are fully initialized Message-ID: References: <20260106222715.GA381397@bhelgaas> <0e35a4e1-894a-47c1-9528-fc5ffbafd9e2@samsung.com> <61e8c93c-d096-4807-b2dd-a22657f2e06a@samsung.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi Rafael, Thanks for your thoughts! On Sun, Jan 18, 2026 at 12:53:21PM +0100, Rafael J. Wysocki wrote: > On Sat, Jan 17, 2026 at 2:19 AM Brian Norris wrote: > > I suppose one way to "solve" that is (untested): > > > > --- a/drivers/pci/bus.c > > +++ b/drivers/pci/bus.c > > @@ -380,8 +380,12 @@ void pci_bus_add_device(struct pci_dev *dev) > > put_device(&pdev->dev); > > } > > > > + if (dev->dev.parent) > > + pm_runtime_get_sync(dev->dev.parent); > > pm_runtime_set_active(&dev->dev); > > pm_runtime_enable(&dev->dev); > > + if (dev->dev.parent) > > + pm_runtime_put(dev->dev.parent); > > > > if (!dn || of_device_is_available(dn)) > > pci_dev_allow_binding(dev); > > > > Personally, I'm more inclined to go back to v1, since it prepares the > > runtime PM status when the device is first discovered. That way, its > > ancestors are still active, avoiding these sorts of problems. I'm > > frankly not sure of all the reasons Rafael recommended I make the > > v1->v3->v4 changes, and now that they cause problems, I'm inclined to > > question them again. > > > > Rafael, do you have any thoughts? > > Yeah. > > Move back pm_runtime_set_active(&dev->dev) back to pm_runtime_init() > because that would prevent the parent from suspending and keep > pm_runtime_enable() here because that would prevent the device itself > from suspending between pm_runtime_init() and this place. I'll admit, I was a little fuzzy on the details of the first part of the sentence here -- specifically, that an "active" (but still "disabled") device will prevent suspend of its parent. I suppose I'm more familiar with the typical "disabled and suspended" device, which essentially has no effect on its parent. Anyway, that's basically v3, so I rerolled a v5 that looks similar. > And I would add comments in both places. I tried to add a short comment to each. It's an art form to write exactly the right size of comment to make everyone happy (people complain about too much commenting, and then others complain about non-obvious behaviors that could have used more comments), especially when it comes to something as tricky as runtime PM. At least I tried... Brian