From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 193E5448BA1 for ; Thu, 23 Jul 2026 14:40:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784817650; cv=none; b=oMagnR5ro1afsHpuvocHPWDrCIxXzz/BeMtziT1qfS3pSU3ocXXTD9CX8HB/LgTYJTYf2xklaRYJGC1g4a3fNpz8js+ElGyPRydBz+gY+OlhO9oDD928c8gH652g8fchILOl99flarTgVRHTc5NDEmaVs5Q9wWHnO/nhMPQSBxI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784817650; c=relaxed/simple; bh=kg9Xp/R9DfaR82RsUOUd8pUoL9wzn3C0edR+7vZ5gSA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rOPoR5Mqv70UAkd7JI8rlGYadFNLkaIaP+4RgmJehQ8wLoqVHL5QSiE0ET2ZJ2q6dQUTd/71j7pRHN55R/Gb2l68sRG9ucBWFs46cwhEcUqTmEa6enDC0ZO1nde83PaX1CPnat4aGRGUw3YH+f1WoNjEbZqblybUWg5XwI8yG4M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=LxYGTi3Z; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=dU+/oUjS; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LxYGTi3Z"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="dU+/oUjS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1784817635; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KBbJHj3/HGRQnu2lI6pHC51IXPFz8msF1DYjvpECwOc=; b=LxYGTi3ZkIOmRzp3eQZ0nsVcwha5P6pU66BNKzzaid8zAbXcgX+4q5xZUfDXVzzpe+PW1t kdZ3YK772Ms9koV/hMhDPmwTMD4MbryLNeGQjR/HxGj+de/UVLi+VQT3gD5ckjnX0lZkj/ C7gmlIn73pz3YTUgjji7YTFtwk5rKoQ= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-643-EfV0g0q9NoWoti5IwVy0vg-1; Thu, 23 Jul 2026 10:40:31 -0400 X-MC-Unique: EfV0g0q9NoWoti5IwVy0vg-1 X-Mimecast-MFC-AGG-ID: EfV0g0q9NoWoti5IwVy0vg_1784817631 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-92e55721a8cso148997585a.1 for ; Thu, 23 Jul 2026 07:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1784817631; x=1785422431; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to:content-type; bh=KBbJHj3/HGRQnu2lI6pHC51IXPFz8msF1DYjvpECwOc=; b=dU+/oUjSOlC9t53ktRfF/J8+squORYID7xpnLDSQLSEBbD7siYIDDeKFWYON3axS83 CWdteHAiLm9HIzAcIVtTFDhlIC/TFWLzVVj39NFZZxe4cMFDLrLhkUGCkEPFeAxlTFif dNoOcM2hWjFC7VW45ntAaq2twpB89vwx+yDEEpumhBvbjxrf3+6wuxN/ctreGg6j2gJF nClweZmX3K6ASfhectRHVva8ci9zcgDXJIARZI7b/0Y1rbjmID+PuvNxsnuKn5x+ViT5 EJgNaAy7RkAhB/P9Aa4belDYOFvWKN1YuTjpgaTz+sJ+3mBaqb91N/wYkDr2fFlpGQPB 75EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784817631; x=1785422431; h=user-agent:in-reply-to:content-disposition:content-type :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 :content-type; bh=KBbJHj3/HGRQnu2lI6pHC51IXPFz8msF1DYjvpECwOc=; b=GggzsPd3r+IwsQgVbNfTQOvIlx4sdzQaUu+9KkpFY9uYrJ9NrJe3gpPrYQ3szoTxUl d9AAhWjdCyiPZNktfcnuiaLSGHM0R4XBSIgrWSzeZfN3c1Y5CIcRSMmp/wtbpG7P4kgZ G90TJQKMyeTg6Kyg94ykwJjw6vgfZbe1L5TfPG5NBCGBncg+SfbeCBPip/XcOB/+YqU7 MdyxGbkgEopKh2i2VV6iY8gYGRf3PbvYiE96+Y0hR+qubidIvCI4qWhb9aNuzTGsYE07 lbwdZNpJ2/lMEdnzib5hWN+fppRZIz8DqcPFnq2nJDAqAXPt2kZ33W8VSvlLAXdql7ty /6pA== X-Forwarded-Encrypted: i=1; AHgh+Rrg7zjGPIBt2BrlnI56GMl8dUwwdbBSQHwCh3WB+YMwJCw/4eq6zLU5RdmB7RyCrJUxR4Jla3Smiak2ctQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwcPnnd+H3PkHevmO7MxMgS2mV0j77oZj6VXsgrCNCjWS1vyQ7n VcF1az4E3zTKPMYmwMT4+f+gqZrjOFRlRn+dOjLB5Aj+TP8RefbiGddqlrbHa9TLdZqPka9Taqr HPghtqzFKax6vrvps4QB5S5KwSoglRw/HDpZ1iAiys/ICYWszdBxWY9WnUPOg8LHuMw== X-Gm-Gg: AR+sD13UakmkfBFoGXQE5XbWczrMJ2j5kwRIaC1xbv/JvX9Swb3ob2ejKjNQOSFkA/+ 1wdCmjOZIcd72UYsZImu00O/Uu5R2+1tzqUuTKkmzruilMb60GQ3EYWnjHRDrTnGnFDDpeMuDFD tqYbBtbrwh3G+G9NOVIfYGswVcfs1rtHPw+qcp1DLfZIXbvuldjJKTE2zDAxKTSe9Mnp90SFQzN zqnFFH8b/Sx2Yv/BKysKp/ARaapZLK2OpIY9CoBg3OYRy4EKAqIfxvYubJMCtxkD4of3l2c4J4B 1fkzfGm13npqfT8Xdhropdy26tmsUUGOGBTWtQrglyEasna/TmWrBYnEmwdVwUdhK9f4ckDmiRD 7ZuOzfY0M2rIssdOm77gXlx3UhzVG2DapO38= X-Received: by 2002:a05:620a:90ce:10b0:92e:8a84:7041 with SMTP id af79cd13be357-931035ce976mr246942985a.8.1784817631160; Thu, 23 Jul 2026 07:40:31 -0700 (PDT) X-Received: by 2002:a05:620a:90ce:10b0:92e:8a84:7041 with SMTP id af79cd13be357-931035ce976mr246937785a.8.1784817630329; Thu, 23 Jul 2026 07:40:30 -0700 (PDT) Received: from redhat.com (c-73-183-53-213.hsd1.pa.comcast.net. [73.183.53.213]) by smtp.gmail.com with ESMTPSA id af79cd13be357-930f6a6a157sm425415285a.37.2026.07.23.07.40.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2026 07:40:29 -0700 (PDT) Date: Thu, 23 Jul 2026 10:40:28 -0400 From: Brian Masney To: Jerome Brunet Cc: Michael Turquette , Stephen Boyd , Russell King , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2] clk: fix self-consuming provider module pinning Message-ID: References: <20260723-clk-provider-pinning-v2-1-8dad72eb79f0@baylibre.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: <20260723-clk-provider-pinning-v2-1-8dad72eb79f0@baylibre.com> User-Agent: Mutt/2.4.0 (2026-06-19) Hi Jerome, On Thu, Jul 23, 2026 at 03:00:51PM +0200, Jerome Brunet wrote: > clk_hw_get_clk() lets a provider get a struct clk for one of its own > struct clk_hw. > > When a struct clk is created, the module usage count of the provider > is unconditionally increased. For a self-consuming provider, this means > it pins itself and the module can never be unloaded. > > Increasing the module usage count should only be done when the consumer > lives in a different module from the provider. Use THIS_MODULE to > capture caller's module and increase the module usage count accordingly. > > It is OK for consumer-only APIs such as clk_get() or of_clk_get() to > pass a NULL owner. As a result, any provider module will get pinned, > same as before. > > Fixes: 30d6f8c15d2c ("clk: add api to get clk consumer from clk_hw") > Signed-off-by: Jerome Brunet > --- > This issue has been present for a while. Virtually all users of > clk_hw_get_clk() are affected. The majority are compiled as builtins > according to the defconfigs. It is not problem in this case but it is > if the configuration is changed to module. > > The following modules are using clk_hw_get_clk() and are compiled as > module with some shipped defconfigs: > * drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_pll.c > * drivers/phy/cadence/phy-cadence-sierra.c > * drivers/pwm/pwm-meson.c > * sound/soc/codecs/lpass-va-macro.c > > Currently those module cannot be unloaded once they have been loaded. > > """ > rmmod: ERROR: Module blabla-module is in use > """ > > With this applied, we can get back to removing the direct usage > of the struct clk in struct clk_hw and eventually remove this > struct member entirely. > --- > Changes in v2: > - Update comment in __clk_register() > - Add missing documention for the new parameter of clk_hw_create_clk() > - No functional change > - Link to v1: https://patch.msgid.link/20260721-clk-provider-pinning-v1-1-63db2e667993@baylibre.com Reviewed-by: Brian Masney This looks good to me. I'm planning to send Stephen a pull next week for content that I think is ready during this development cycle, however I'm not going to include this. I suspect he's going to want a kunit test for this and I know it's going to be complicated. My suggestion is to post some kind of rough test scenario for this, even if it's initially not in kunit. As I get some spare time at work, I can help you to see if we can get a kunit test together for this. Brian