Several drivers in the clk subsystem forget to call dont_use_autosuspend()
on teardown or error, causing potential resource leaks. This series adds
the missing calls.

The offending drivers were found using a semantic patch for Coccinelle
I'm working on [1].

[1] https://lore.kernel.org/all/20260915064327.1377-1-joshua.crofts1@gmail.com/

Joshua Crofts (2):
  clk: imx: clk-imx8qxp-lpcg: add missing
    pm_runtime_dont_use_autosuspend()
  clk: imx: scu: add missing pm_runtime_dont_use_autosuspend() call

 drivers/clk/imx/clk-imx8qxp-lpcg.c | 1 +
 drivers/clk/imx/clk-scu.c          | 2 ++
 2 files changed, 3 insertions(+)

-- 
2.47.3

On Tue, Sep 15, 2026 at 10:33:43AM +0000, Joshua Crofts wrote:
> Several drivers in the clk subsystem forget to call dont_use_autosuspend()
> on teardown or error, causing potential resource leaks. This series adds
> the missing calls.

No, as I've explained repeatedly elsewhere, it does not cause any
resource leaks. [1][2]

The autosuspend setting leaks if you will, but that only matters in the
theoretical corner case of someone rebinding a different driver (which
will soon also taint the kernel).

So don't exaggerate the impact, this is essentially just a cleanup,
which is fine in itself.

Johan

[1] https://lore.kernel.org/all/aqpd3viN1UoZBkgL@hovoldconsulting.com/
[2] https://lore.kernel.org/linux-iio/aow51Nk-cet9qaUQ@hovoldconsulting.com/

On Wed, Sep 16, 2026 at 11:24:32AM +0200, Johan Hovold wrote:
> On Tue, Sep 15, 2026 at 10:33:43AM +0000, Joshua Crofts wrote:
> > Several drivers in the clk subsystem forget to call dont_use_autosuspend()
> > on teardown or error, causing potential resource leaks. This series adds
> > the missing calls.
>
> No, as I've explained repeatedly elsewhere, it does not cause any
> resource leaks. [1][2]
>
> The autosuspend setting leaks if you will, but that only matters in the
> theoretical corner case of someone rebinding a different driver (which
> will soon also taint the kernel).
>
> So don't exaggerate the impact, this is essentially just a cleanup,
> which is fine in itself.

Is it possilbe to create/improve runtime pm API, let runtime_pm enable/disable
include these pair functions.

I get many similar patches since scan tools is more powerful now.

Frank

>
> Johan
>
> [1] https://lore.kernel.org/all/aqpd3viN1UoZBkgL@hovoldconsulting.com/
> [2] https://lore.kernel.org/linux-iio/aow51Nk-cet9qaUQ@hovoldconsulting.com/
>

On Wed, 16 Sep 2026 11:11:54 -0500
Frank Li <Frank.li@oss.nxp.com> wrote:

> On Wed, Sep 16, 2026 at 11:24:32AM +0200, Johan Hovold wrote:
> > On Tue, Sep 15, 2026 at 10:33:43AM +0000, Joshua Crofts wrote:  
> > > Several drivers in the clk subsystem forget to call dont_use_autosuspend()
> > > on teardown or error, causing potential resource leaks. This series adds
> > > the missing calls.  
> >
> > No, as I've explained repeatedly elsewhere, it does not cause any
> > resource leaks. [1][2]
> >
> > The autosuspend setting leaks if you will, but that only matters in the
> > theoretical corner case of someone rebinding a different driver (which
> > will soon also taint the kernel).
> >
> > So don't exaggerate the impact, this is essentially just a cleanup,
> > which is fine in itself.  
> 
> Is it possilbe to create/improve runtime pm API, let runtime_pm enable/disable
> include these pair functions.
> 
> I get many similar patches since scan tools is more powerful now.

I suppose that could work. One would still have to scrub the kernel of legacy
use/dont_use_autosuspend() calls though, so it could end up being a large
patchset.

-- 
Kind regards,
Joshua Crofts

On Thu, 17 Sep 2026 10:24:29 +0200
Joshua Crofts <joshua.crofts1@gmail.com> wrote:

> On Wed, 16 Sep 2026 11:11:54 -0500
> Frank Li <Frank.li@oss.nxp.com> wrote:
> 
> > On Wed, Sep 16, 2026 at 11:24:32AM +0200, Johan Hovold wrote:  
> > > On Tue, Sep 15, 2026 at 10:33:43AM +0000, Joshua Crofts wrote:    
> > > > Several drivers in the clk subsystem forget to call dont_use_autosuspend()
> > > > on teardown or error, causing potential resource leaks. This series adds
> > > > the missing calls.    
> > >
> > > No, as I've explained repeatedly elsewhere, it does not cause any
> > > resource leaks. [1][2]
> > >
> > > The autosuspend setting leaks if you will, but that only matters in the
> > > theoretical corner case of someone rebinding a different driver (which
> > > will soon also taint the kernel).
> > >
> > > So don't exaggerate the impact, this is essentially just a cleanup,
> > > which is fine in itself.    
> > 
> > Is it possilbe to create/improve runtime pm API, let runtime_pm enable/disable
> > include these pair functions.
> > 
> > I get many similar patches since scan tools is more powerful now.  
> 
> I suppose that could work. One would still have to scrub the kernel of legacy
> use/dont_use_autosuspend() calls though, so it could end up being a large
> patchset.
> 

On second thought, some drivers do tend to disable PM runtime system sleep
etc. so it probably isn't as simple as adding the autosuspend stuff to
enable/disable.

-- 
Kind regards,
Joshua Crofts

On Thu, Sep 17, 2026 at 10:42:33AM +0200, Joshua Crofts wrote:
> On Thu, 17 Sep 2026 10:24:29 +0200
> Joshua Crofts <joshua.crofts1@gmail.com> wrote:
>
> > On Wed, 16 Sep 2026 11:11:54 -0500
> > Frank Li <Frank.li@oss.nxp.com> wrote:
> >
> > > On Wed, Sep 16, 2026 at 11:24:32AM +0200, Johan Hovold wrote:
> > > > On Tue, Sep 15, 2026 at 10:33:43AM +0000, Joshua Crofts wrote:
> > > > > Several drivers in the clk subsystem forget to call dont_use_autosuspend()
> > > > > on teardown or error, causing potential resource leaks. This series adds
> > > > > the missing calls.
> > > >
> > > > No, as I've explained repeatedly elsewhere, it does not cause any
> > > > resource leaks. [1][2]
> > > >
> > > > The autosuspend setting leaks if you will, but that only matters in the
> > > > theoretical corner case of someone rebinding a different driver (which
> > > > will soon also taint the kernel).
> > > >
> > > > So don't exaggerate the impact, this is essentially just a cleanup,
> > > > which is fine in itself.
> > >
> > > Is it possilbe to create/improve runtime pm API, let runtime_pm enable/disable
> > > include these pair functions.
> > >
> > > I get many similar patches since scan tools is more powerful now.
> >
> > I suppose that could work. One would still have to scrub the kernel of legacy
> > use/dont_use_autosuspend() calls though, so it could end up being a large
> > patchset.
> >
>
> On second thought, some drivers do tend to disable PM runtime system sleep
> etc. so it probably isn't as simple as adding the autosuspend stuff to
> enable/disable.

if runtime pm disable, does autosuspend still work? suppose it should be
disable also

Frank

>
> --
> Kind regards,
> Joshua Crofts

On Thu, 17 Sept 2026 at 18:26, Frank Li <Frank.li@oss.nxp.com> wrote:
>
> On Thu, Sep 17, 2026 at 10:42:33AM +0200, Joshua Crofts wrote:
> > On Thu, 17 Sep 2026 10:24:29 +0200
> > Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> >
> > > On Wed, 16 Sep 2026 11:11:54 -0500
> > > Frank Li <Frank.li@oss.nxp.com> wrote:
> > >
> > > > On Wed, Sep 16, 2026 at 11:24:32AM +0200, Johan Hovold wrote:
> > > > > On Tue, Sep 15, 2026 at 10:33:43AM +0000, Joshua Crofts wrote:
> > > > > > Several drivers in the clk subsystem forget to call dont_use_autosuspend()
> > > > > > on teardown or error, causing potential resource leaks. This series adds
> > > > > > the missing calls.
> > > > >
> > > > > No, as I've explained repeatedly elsewhere, it does not cause any
> > > > > resource leaks. [1][2]
> > > > >
> > > > > The autosuspend setting leaks if you will, but that only matters in the
> > > > > theoretical corner case of someone rebinding a different driver (which
> > > > > will soon also taint the kernel).
> > > > >
> > > > > So don't exaggerate the impact, this is essentially just a cleanup,
> > > > > which is fine in itself.
> > > >
> > > > Is it possilbe to create/improve runtime pm API, let runtime_pm enable/disable
> > > > include these pair functions.
> > > >
> > > > I get many similar patches since scan tools is more powerful now.
> > >
> > > I suppose that could work. One would still have to scrub the kernel of legacy
> > > use/dont_use_autosuspend() calls though, so it could end up being a large
> > > patchset.
> > >
> >
> > On second thought, some drivers do tend to disable PM runtime system sleep
> > etc. so it probably isn't as simple as adding the autosuspend stuff to
> > enable/disable.
>
> if runtime pm disable, does autosuspend still work? suppose it should be
> disable also

If we add dont_use_autosuspend to disable then every time the system suspends
and resumes we lose the autosuspend config, meaning it will never autosuspend
again.

I guess adding dont_use manually to the driver's remove() function is the only
way (which according to my cocci script it's 195 drivers that should be patched)

--
Kind regards,
Joshua Crofts

On Thu, Sep 17, 2026 at 07:15:29PM +0200, Joshua Crofts wrote:
> On Thu, 17 Sept 2026 at 18:26, Frank Li <Frank.li@oss.nxp.com> wrote:
> >
> > On Thu, Sep 17, 2026 at 10:42:33AM +0200, Joshua Crofts wrote:
> > > On Thu, 17 Sep 2026 10:24:29 +0200
> > > Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> > >
> > > > On Wed, 16 Sep 2026 11:11:54 -0500
> > > > Frank Li <Frank.li@oss.nxp.com> wrote:
> > > >
> > > > > On Wed, Sep 16, 2026 at 11:24:32AM +0200, Johan Hovold wrote:
> > > > > > On Tue, Sep 15, 2026 at 10:33:43AM +0000, Joshua Crofts wrote:
> > > > > > > Several drivers in the clk subsystem forget to call dont_use_autosuspend()
> > > > > > > on teardown or error, causing potential resource leaks. This series adds
> > > > > > > the missing calls.
> > > > > >
> > > > > > No, as I've explained repeatedly elsewhere, it does not cause any
> > > > > > resource leaks. [1][2]
> > > > > >
> > > > > > The autosuspend setting leaks if you will, but that only matters in the
> > > > > > theoretical corner case of someone rebinding a different driver (which
> > > > > > will soon also taint the kernel).
> > > > > >
> > > > > > So don't exaggerate the impact, this is essentially just a cleanup,
> > > > > > which is fine in itself.
> > > > >
> > > > > Is it possilbe to create/improve runtime pm API, let runtime_pm enable/disable
> > > > > include these pair functions.
> > > > >
> > > > > I get many similar patches since scan tools is more powerful now.
> > > >
> > > > I suppose that could work. One would still have to scrub the kernel of legacy
> > > > use/dont_use_autosuspend() calls though, so it could end up being a large
> > > > patchset.
> > > >
> > >
> > > On second thought, some drivers do tend to disable PM runtime system sleep
> > > etc. so it probably isn't as simple as adding the autosuspend stuff to
> > > enable/disable.
> >
> > if runtime pm disable, does autosuspend still work? suppose it should be
> > disable also
>
> If we add dont_use_autosuspend to disable then every time the system suspends
> and resumes we lose the autosuspend config, meaning it will never autosuspend
> again.
>
> I guess adding dont_use manually to the driver's remove() function is the only
> way (which according to my cocci script it's 195 drivers that should be patched)

Extend with exist pm_runtime_enable() and passdown delay value. if delay
value is 0, actually it is no autosuspend version.

and merge dont_use_autosuspend() into disable function. And actually
I don't understand why need two varible autosuspend_delay and use_autosuspend.

when autosuspend_delay 0, means take action immediately.

Frank

>
> --
> Kind regards,
> Joshua Crofts

On Thu, 17 Sep 2026 13:36:11 -0500
Frank Li <Frank.li@oss.nxp.com> wrote:

> On Thu, Sep 17, 2026 at 07:15:29PM +0200, Joshua Crofts wrote:
> > On Thu, 17 Sept 2026 at 18:26, Frank Li <Frank.li@oss.nxp.com> wrote:  
> > >
> > > On Thu, Sep 17, 2026 at 10:42:33AM +0200, Joshua Crofts wrote:  
> > > > On Thu, 17 Sep 2026 10:24:29 +0200
> > > > Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> > > >  
> > > > > On Wed, 16 Sep 2026 11:11:54 -0500
> > > > > Frank Li <Frank.li@oss.nxp.com> wrote:
> > > > >  
> > > > > > On Wed, Sep 16, 2026 at 11:24:32AM +0200, Johan Hovold wrote:  
> > > > > > > On Tue, Sep 15, 2026 at 10:33:43AM +0000, Joshua Crofts wrote:  
> > > > > > > > Several drivers in the clk subsystem forget to call dont_use_autosuspend()
> > > > > > > > on teardown or error, causing potential resource leaks. This series adds
> > > > > > > > the missing calls.  
> > > > > > >
> > > > > > > No, as I've explained repeatedly elsewhere, it does not cause any
> > > > > > > resource leaks. [1][2]
> > > > > > >
> > > > > > > The autosuspend setting leaks if you will, but that only matters in the
> > > > > > > theoretical corner case of someone rebinding a different driver (which
> > > > > > > will soon also taint the kernel).
> > > > > > >
> > > > > > > So don't exaggerate the impact, this is essentially just a cleanup,
> > > > > > > which is fine in itself.  
> > > > > >
> > > > > > Is it possilbe to create/improve runtime pm API, let runtime_pm enable/disable
> > > > > > include these pair functions.
> > > > > >
> > > > > > I get many similar patches since scan tools is more powerful now.  
> > > > >
> > > > > I suppose that could work. One would still have to scrub the kernel of legacy
> > > > > use/dont_use_autosuspend() calls though, so it could end up being a large
> > > > > patchset.
> > > > >  
> > > >
> > > > On second thought, some drivers do tend to disable PM runtime system sleep
> > > > etc. so it probably isn't as simple as adding the autosuspend stuff to
> > > > enable/disable.  
> > >
> > > if runtime pm disable, does autosuspend still work? suppose it should be
> > > disable also  
> >
> > If we add dont_use_autosuspend to disable then every time the system suspends
> > and resumes we lose the autosuspend config, meaning it will never autosuspend
> > again.
> >
> > I guess adding dont_use manually to the driver's remove() function is the only
> > way (which according to my cocci script it's 195 drivers that should be patched)  
> 
> Extend with exist pm_runtime_enable() and passdown delay value. if delay
> value is 0, actually it is no autosuspend version.
> 
> and merge dont_use_autosuspend() into disable function. And actually
> I don't understand why need two varible autosuspend_delay and use_autosuspend.
> 
> when autosuspend_delay 0, means take action immediately.

Actually, what about putting dont_use_autosuspend() in pm_runtime_reinit()?
https://elixir.bootlin.com/linux/v7.3-rc3/source/drivers/base/power/runtime.c#L1865

driver core calls this in device_unbind_cleanup(), meaning driver core would
just handle it.

-- 
Kind regards,
Joshua Crofts

On Fri, Sep 18, 2026 at 09:25:33AM +0200, Joshua Crofts wrote:
> On Thu, 17 Sep 2026 13:36:11 -0500
> Frank Li <Frank.li@oss.nxp.com> wrote:
>
> > On Thu, Sep 17, 2026 at 07:15:29PM +0200, Joshua Crofts wrote:
> > > On Thu, 17 Sept 2026 at 18:26, Frank Li <Frank.li@oss.nxp.com> wrote:
> > > >
> > > > On Thu, Sep 17, 2026 at 10:42:33AM +0200, Joshua Crofts wrote:
> > > > > On Thu, 17 Sep 2026 10:24:29 +0200
> > > > > Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> > > > >
> > > > > > On Wed, 16 Sep 2026 11:11:54 -0500
> > > > > > Frank Li <Frank.li@oss.nxp.com> wrote:
> > > > > >
> > > > > > > On Wed, Sep 16, 2026 at 11:24:32AM +0200, Johan Hovold wrote:
> > > > > > > > On Tue, Sep 15, 2026 at 10:33:43AM +0000, Joshua Crofts wrote:
> > > > > > > > > Several drivers in the clk subsystem forget to call dont_use_autosuspend()
> > > > > > > > > on teardown or error, causing potential resource leaks. This series adds
> > > > > > > > > the missing calls.
> > > > > > > >
> > > > > > > > No, as I've explained repeatedly elsewhere, it does not cause any
> > > > > > > > resource leaks. [1][2]
> > > > > > > >
> > > > > > > > The autosuspend setting leaks if you will, but that only matters in the
> > > > > > > > theoretical corner case of someone rebinding a different driver (which
> > > > > > > > will soon also taint the kernel).
> > > > > > > >
> > > > > > > > So don't exaggerate the impact, this is essentially just a cleanup,
> > > > > > > > which is fine in itself.
> > > > > > >
> > > > > > > Is it possilbe to create/improve runtime pm API, let runtime_pm enable/disable
> > > > > > > include these pair functions.
> > > > > > >
> > > > > > > I get many similar patches since scan tools is more powerful now.
> > > > > >
> > > > > > I suppose that could work. One would still have to scrub the kernel of legacy
> > > > > > use/dont_use_autosuspend() calls though, so it could end up being a large
> > > > > > patchset.
> > > > > >
> > > > >
> > > > > On second thought, some drivers do tend to disable PM runtime system sleep
> > > > > etc. so it probably isn't as simple as adding the autosuspend stuff to
> > > > > enable/disable.
> > > >
> > > > if runtime pm disable, does autosuspend still work? suppose it should be
> > > > disable also
> > >
> > > If we add dont_use_autosuspend to disable then every time the system suspends
> > > and resumes we lose the autosuspend config, meaning it will never autosuspend
> > > again.
> > >
> > > I guess adding dont_use manually to the driver's remove() function is the only
> > > way (which according to my cocci script it's 195 drivers that should be patched)
> >
> > Extend with exist pm_runtime_enable() and passdown delay value. if delay
> > value is 0, actually it is no autosuspend version.
> >
> > and merge dont_use_autosuspend() into disable function. And actually
> > I don't understand why need two varible autosuspend_delay and use_autosuspend.
> >
> > when autosuspend_delay 0, means take action immediately.
>
> Actually, what about putting dont_use_autosuspend() in pm_runtime_reinit()?
> https://elixir.bootlin.com/linux/v7.3-rc3/source/drivers/base/power/runtime.c#L1865
>
> driver core calls this in device_unbind_cleanup(), meaning driver core would
> just handle it.

Yes, much better.

Frank
>
> --
> Kind regards,
> Joshua Crofts