Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp1431732pxx; Fri, 30 Oct 2020 09:48:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy+SNdQDq2mpGQG0RaG4/uKK2xwzsRTk/Qv05WvR7YRvmeH6zelgpeTvNiwuIlMZ2CluEzP X-Received: by 2002:a17:906:8142:: with SMTP id z2mr3300125ejw.30.1604076504687; Fri, 30 Oct 2020 09:48:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1604076504; cv=none; d=google.com; s=arc-20160816; b=Erd2bx4W9/BGWX9MGvO3bPz6p9F1osu+aQMl4xLnkgvGR9XkN19cKvAnnKyFGN2Iaf kjh9cj3Jgv3ROOSoYp9MZ4dMa0P2Rkz0frpRRX0Ue/28xYX8Y2Dt4gid5RQCM9qJJLxl 7yoIUH2TpDERGjv1rlUVtGDvIc+CsRLNOr/Wm1w+Q6UT1ntNnhsCsLoY72D1niyUIsOZ 0fh+djLDGNCy9ODWQpZzfreQ2MtVHETGAMEtshOYvGmbSgBQYa2ZEaj4xzxOZOwGEYaP uPhLmDyNrTmXhmDB7ZOY/THMSfrKOHdzB2o72Muqdp98cMzWQaX+0yfpxVorySPt1kiR NmCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=zdHn4Bghzba5wOelTeZ6mhUplKqje06p67vbKsYURC0=; b=zKjOfUpEWTWR4DRKvQP2RDsUiIZ8R0+/j29z+rF7MSjQSNS5NNsVXdPzqmgIrSIjT9 zbN/rRVdjE5FYsz4PTQU7V8P/wI2aBVVAUusybJ52uqewL2TYcD8CLYp30Byy7KiPUs6 5f3dayLXgp4zJshcXzALB5CBwjhg8eny61jPWbF1xfhYfMf9DLUmBZk/zxGDKn+isIhM FhqFcajr65qtUdLWNnTZFmgkgg5kuw8Td5NuMrGBRhCYJZlXYNrOv+CuEyp6dTddp6C6 1FsjDlNdKGFbVhPLl+sbvuNbWh40pEdOL9om7LDLwDEmAWHfHzAcNWhegxrEK+Vhr+gF gDVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jz5si4734203ejb.728.2020.10.30.09.48.01; Fri, 30 Oct 2020 09:48:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726917AbgJ3Qqi (ORCPT + 99 others); Fri, 30 Oct 2020 12:46:38 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:44171 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725943AbgJ3Qqh (ORCPT ); Fri, 30 Oct 2020 12:46:37 -0400 Received: by mail-ot1-f68.google.com with SMTP id m26so6076010otk.11; Fri, 30 Oct 2020 09:46:37 -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=zdHn4Bghzba5wOelTeZ6mhUplKqje06p67vbKsYURC0=; b=cFMBnFtwUKvmqXAdDDDbjD190ZucouS1+crWbSRnVgI3b/fHLOvFIW4kudTNuZ1TW+ zH4gB56F4bOiD3duQX0L08rd86k0PoOjL2JrJtYVtz+BYQPWbZsM33gEYUYqh70oKFn7 p7TkqXxq+9h/8B3w38mBNt64C7pf2++2t863VEkFa7RbEFV3w0jW4y38q/D4n5iYj9bv lfH50ltOEzuactU0zTXgNuFR2Bi0KqA7hxo7b1ZdUib+UZajdFvz/CXD2wZImdaYSgYx e0SMI+cmoHlg5Sgg1Ow+37TZDuwlTGdQ9rVqtya3uHBAk+P5PKq+wpvkqMzyfJMdAr/m APtw== X-Gm-Message-State: AOAM532jN4UOomxjj8K/3WXDwcUWkFsJt+gwR0Iphposk5a0N9X1pJ8x dHt7FIR/ftxTeE6sitK4vQbbEgCf0MAEAjGhFuFCXReXie4= X-Received: by 2002:a4a:e80b:: with SMTP id b11mr2575066oob.1.1604075920719; Fri, 30 Oct 2020 09:38:40 -0700 (PDT) MIME-Version: 1.0 References: <6543936.FbWAdBN1tG@kreacher> In-Reply-To: <6543936.FbWAdBN1tG@kreacher> From: "Rafael J. Wysocki" Date: Fri, 30 Oct 2020 17:38:29 +0100 Message-ID: Subject: Re: [PATCH 0/3] PM: runtime: Fixes related to device links management To: Greg Kroah-Hartman Cc: Linux PM , LKML , Lukas Wunner , Saravana Kannan , Xiang Chen Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Greg, On Wed, Oct 21, 2020 at 9:14 PM Rafael J. Wysocki wrote: > > Hi Greg & all, > > Commit d12544fb2aa9 ("PM: runtime: Remove link state checks in > rpm_get/put_supplier()") merged recently introduced a weakness > in the handling of device links in the runtime PM framework that > may be confusing and even harmful. > > Namely, the checks removed by that commit prevented PM-runtime from > getting or dropping references to the supplier device whose driver > was going away via its links to consumers, which specifically allowed > the pm_runtime_clean_up_links() called from __device_release_driver() > to run without interfering with runtime suspend/resume of consumer > devices (which still might happen even though the drivers had been > unbound from them by that time). > > After the above commit, calling pm_runtime_clean_up_links() from > __device_release_driver() makes a little sense and it may be interfering > destructively with regular PM-runtime suspend/resume control flows, so > it needs to be either fixed or dropped altogether. I prefer the latter, > because among other things this removes an arbitrary difference in the > handling of managed device links with respect to the stateless ones, > so patch [2/3] is doing just that. > > However, in some rare cases pm_runtime_clean_up_links() may help to clean > up leftover PM-runtime references, so if that function goes away, they > need to be cleaned up elsewhere. That's why patch [1/3] modifies > __device_link_del() to drop them upon device link removal (which also > needs to be done for stateless device links and that's why I'm regarding > this patch as a fix). > > Finally, to avoid pointless overhead related to suspending and resuming > the target device for multiple times in a row in __device_release_driver(), > it is better to resume it upfront before checking its links to consumers, > which is done by patch [3/3]. > > While this series touches the driver core, it really is mostly related to > runtime PM, so I can apply it if that's OK. Any concerns regarding this series? If not, I'd like to queue it up for -rc3, because the current behavior in there is quite confusing (or worse). Cheers!