From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BCF58279798 for ; Wed, 1 Jul 2026 16:23:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782923006; cv=none; b=JSWqS+4m//g9FkmQ4RuwmfF2mQSOdy5tU6Ya9DAjARytMhMBlEUhhOst4C1J1tp2VkyIGxCVO2TEPVgOHAad2ZGoUR5vpYU6K3x93IQpKFnkQ3rFtT9U/a9XB4WHet2AGyGsI6teYsuknhU+NXjeu68WQhLStI256koOr2d/0SQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782923006; c=relaxed/simple; bh=QDuwYFuFsQex09p/F/Y2K7txltbO6dGVc5gPKtvf6UA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tRF+2wvMBtn4dDjmq3Z9TBXxkPJa+2etTcKBcQAEj2I0lp/r4CFXuK4kjOer63/TlVLtEGvXwew4H5ukne/qyKHkj0B1eyVZQvpD0jxfkwH2hFXgutdSXzHMZS+EraQ6rn2awL34hy/eCgPFlfD2adZy44fHzp3o2Jt0tEZSYUo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=eSYsJS1s; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="eSYsJS1s" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BA37B1E7D; Wed, 1 Jul 2026 09:23:19 -0700 (PDT) Received: from localhost (unknown [10.2.196.114]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B22F13F673; Wed, 1 Jul 2026 09:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1782923004; bh=QDuwYFuFsQex09p/F/Y2K7txltbO6dGVc5gPKtvf6UA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eSYsJS1ssQDTzRKLDsO/Yyw68KpGwaH82FNpbe/1R5gXZ61TQyQxLN0bNxVww0f5F lVf0OhesrMIdNhbndF2SYNgLkuhN1DyIp7PyDljLs4GJagYu0H7I5b9K1+pg0LF+3i gGvf1dkV0MW1veJLqFOUgaWBksrtXOs53886JcMg= Date: Wed, 1 Jul 2026 17:23:21 +0100 From: Leo Yan To: Jie Gan Cc: Suzuki K Poulose , Mike Leach , James Clark , Alexander Shishkin , Anshuman Khandual , Yeoreum Yun , Yuanfang Zhang , Maxime Coquelin , Alexandre Torgue , Tingwei Zhang , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com Subject: Re: [PATCH 1/2] coresight: Fix clock refcount imbalance on platform remove Message-ID: <20260701162321.GG1812158@e132581.arm.com> References: <20260701-fix-clock-refcount-unbalance-v1-0-321dc63c1f90@oss.qualcomm.com> <20260701-fix-clock-refcount-unbalance-v1-1-321dc63c1f90@oss.qualcomm.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=us-ascii Content-Disposition: inline In-Reply-To: <20260701-fix-clock-refcount-unbalance-v1-1-321dc63c1f90@oss.qualcomm.com> On Wed, Jul 01, 2026 at 02:05:02PM +0800, Jie Gan wrote: > After probe, pm_runtime_put() allows the device to suspend and the > runtime suspend callback disables the same clocks. During remove the > device is left runtime suspended, so pm_runtime_disable() freezes it > with the clocks already disabled. The devm cleanup that runs afterwards > calls clk_disable_unprepare() a second time, underflowing the clock > enable refcount. Thanks for fixing the issue. The problem is that if the device has already been runtime suspended and its clock has been disabled, afterwards when remove the device, the devm cleanup disables the clock again, resulting in clock count underflow. > diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c > index 0abc11f0690c..4c5b94640e6a 100644 > --- a/drivers/hwtracing/coresight/coresight-funnel.c > +++ b/drivers/hwtracing/coresight/coresight-funnel.c > @@ -334,6 +334,7 @@ static void funnel_platform_remove(struct platform_device *pdev) > return; > > funnel_remove(&pdev->dev); > + pm_runtime_get_sync(&pdev->dev); > pm_runtime_disable(&pdev->dev); Let's use the funnel driver for the discussion. Once we agree on the approach, we can apply the same change to the other CoreSight platform drivers. How about the following teardown? static void funnel_platform_remove(struct platform_device *pdev) { struct funnel_drvdata *drvdata = dev_get_drvdata(&pdev->dev); + int ret; if (WARN_ON(!drvdata)) return; + ret = pm_runtime_get_sync(&pdev->dev); + if (ret < 0) + dev_warn(&pdev->dev, "failed to resume before remove: %d\n", ret); + funnel_remove(&pdev->dev); + pm_runtime_disable(&pdev->dev); + pm_runtime_set_suspended(&pdev->dev); + pm_runtime_put_noidle(&pdev->dev); } The idea is to first resume the device with pm_runtime_get_sync(), then perform the remove (which is safe if they need to access or clean up hardware state), and finally clean up the runtime PM states. I mainly referred to drivers/iio/adc/stm32-adc.c. Thanks, Leo