Hello Laurent,
On Wed, Nov 29, 2023 at 12:11:50PM +0200, Laurent Pinchart wrote:
> On Wed, Nov 29, 2023 at 10:51:37AM +0100, Uwe Kleine-König wrote:
> > On Wed, Nov 29, 2023 at 02:39:55AM +0200, Laurent Pinchart wrote:
> > > On Thu, Nov 23, 2023 at 06:54:27PM +0100, Uwe Kleine-König wrote:
> > > > pm_runtime_resume_and_get() already drops the runtime PM usage counter
> > > > in the error case. So a call to pm_runtime_put_sync() can be dropped.
> > > >
> > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
> > >
> > > I wonder if checkpatch should warn about usage of pm_runtime_get_sync().
> >
> > It should not warn in general. There are cases where
> > pm_runtime_get_sync() is the right function to use. See for example
>
> Sure, the function most likely has some valid use cases (otherwise it
> should just be removed), but I think those are are a minority. I was
> just thinking out loud anyway.
>
> > commit aec488051633 ("crypto: stm32 - Properly handle pm_runtime_get
> > failing").
>
> I don't know much about that device, but wouldn't the best option be to
> avoid resuming the device at remove time ? In any case, that's getting
> out of topic for the sn65dsi86 :-)
Agreed for off-topic, I adapted the Subject to make this more obvious
and added Greg and Rafael to Cc:.
Without waking the device in .remove() it's harder to properly free
resources. OTOH if you properly handle a failure to wake the device, you
cope for most of that difficulty already anyhow. Hmm.
One thing that makes this (IMHO) worse is that __device_release_driver()
calls pm_runtime_put_sync() just before device_remove() (which triggers
calling the driver's remove function). See
https://lore.kernel.org/linux-kernel/20230511073428.10264-1-u.kleine-koenig@xxxxxxxxxxxxxx
for an earlier discussion about that topic.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
