[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251012185216.6268c201@jic23-huawei>
Date: Sun, 12 Oct 2025 18:52:16 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Shuhao Fu <sfual@....ust.hk>, Chen-Yu Tsai <wens@...e.org>, Jernej
Skrabec <jernej.skrabec@...il.com>, Samuel Holland <samuel@...lland.org>,
David Lechner <dlechner@...libre.com>, Nuno Sá
<nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>,
linux-iio@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iio: adc: Fix pm runtime clean-up in sun4i_gpadc_probe
On Wed, 8 Oct 2025 19:57:47 +0300
Andy Shevchenko <andy.shevchenko@...il.com> wrote:
> On Wed, Oct 8, 2025 at 7:52 PM Shuhao Fu <sfual@....ust.hk> wrote:
> >
> > In `sun4i_gpadc_probe`, in case of thermal register failure, the runtime
> > PM usage counter would not be decreased, resulting in a possible
> > inconsistency of runtime PM state.
> >
> > Fixes: b0a242894f11 ("iio: adc: sun4i-gpadc-iio: register in the thermal after registering in pm")
>
> This might fix this problem, but it doesn't fix the whole mess in the
> probe with devm/non-devm ordering.
>
Mostly this looks simple to fix. Starting with devm_iio_map_register() instead
of the non devm version.
Then devm_pm_runtime_enable(). However, I have no idea why we need a pm_runtime_put()
in the exit path. Maybe it's messing with the parent power? There isn't a matching
get.
Anyone have this hardware to hand for testing if we try to fix this up fully?
Jonathan
Powered by blists - more mailing lists