Em Sat, 24 Apr 2021 12:00:46 +0200
Johan Hovold <johan@xxxxxxxxxx> escreveu:
> On Sat, Apr 24, 2021 at 10:24:54AM +0200, Jacopo Mondi wrote:
> > Hi Mauro,
> >
> > On Sat, Apr 24, 2021 at 08:44:48AM +0200, Mauro Carvalho Chehab wrote:
> > > Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> > > added pm_runtime_resume_and_get() in order to automatically handle
> > > dev->power.usage_count decrement on errors.
> > >
> > > Use the new API, in order to cleanup the error check logic.
> > >
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx>
> >
> > Thanks
> > Acked-by: Jacopo Mondi <jacopo@xxxxxxxxxx>
> >
> > I should re-work the error handling sequence there on top of this
> > patch as right now it's not the best, that 'done' label bothers me...
> > anyway, for later.
> >
> > > ---
> > > drivers/media/i2c/mt9m001.c | 7 ++++---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/mt9m001.c b/drivers/media/i2c/mt9m001.c
> > > index 3b0ba8ed5233..57e15a291ebd 100644
> > > --- a/drivers/media/i2c/mt9m001.c
> > > +++ b/drivers/media/i2c/mt9m001.c
> > > @@ -217,9 +217,9 @@ static int mt9m001_s_stream(struct v4l2_subdev *sd, int enable)
> > > goto done;
> > >
> > > if (enable) {
> > > - ret = pm_runtime_get_sync(&client->dev);
> > > + ret = pm_runtime_resume_and_get(&client->dev);
> > > if (ret < 0)
> > > - goto put_unlock;
> > > + goto unlock;
> > >
> > > ret = mt9m001_apply_selection(sd);
> > > if (ret)
> > > @@ -247,6 +247,7 @@ static int mt9m001_s_stream(struct v4l2_subdev *sd, int enable)
> > >
> > > put_unlock:
> > > pm_runtime_put(&client->dev);
> > > +unlock:
> > > mutex_unlock(&mt9m001->mutex);
> > >
> > > return ret;
> > > @@ -834,7 +835,7 @@ static int mt9m001_remove(struct i2c_client *client)
> > > {
> > > struct mt9m001 *mt9m001 = to_mt9m001(client);
> > >
> > > - pm_runtime_get_sync(&client->dev);
> > > + pm_runtime_resume_and_get(&client->dev);
> > >
> > > v4l2_async_unregister_subdev(&mt9m001->subdev);
> > > media_entity_cleanup(&mt9m001->subdev.entity);
>
> I couldn't help looking at one more now that you got feedback on this
> one.
>
> Here you have the same problem as the one I reported earlier, in that
> the usage count could end up negative on resume failure due to the later
> put_noidle() call in remove().
I'll double-check this at the entire series. Different sensor
drivers are handling this on different ways, which sounds
bad, as they are meant to be independent on the media bridge
driver.
> Also note that you're adding more lines than you're removing.
Ok, but the end goal is not really reducing the number of lines,
but to have the code following the same pattern, and to avoid
cut-and-paste errors when new drivers are written.
The mt9m001 is one of the oldest sensor drivers, written a long time
before the PM runtime core, written for the soc_camera driver, back
in 2008. The port to use PM runtime isn't old:
commit 8fcfc491c6ca5887bb341b3a622cca3ed8e3c9f0
Author: Akinobu Mita <akinobu.mita@xxxxxxxxx>
Date: Tue Jan 8 12:51:44 2019 -0200
media: mt9m001: switch s_power callback to runtime PM
It was part of an attempt to recover the soc_camera sensor drives
from staging.
Yet, the logic on this driver seems to be different than the
one used on more modern I2C sensors. So, better to re-check
everything.
> I'd say this kind of mass-conversion is of questionable worth as
> pm_runtime_resume_and_get() isn't necessarily an improvement (even if it
> may have its use in some places).
The main problem is that other parts of the driver's core APIs
assume that get object methods will only increment the usage
counter if no errors. The pm_runtime_get_sync() is an exception.
Its name doesn't help at all: A function like that should, IMHO,
be called, instead:
pm_runtime_inc_usage_count_and_try_to_resume().
Or something similar, in order to make clearer that it always
increment the usage count, no matter what. If possible, all drivers
should get rid of it too (or alternatively add comments warning
people that keeping the usage_count incremented is desired on the
very specific places where it is really needed), as it is risky
to use something that has a different usage_count increement behavior
than other more usual *_get() functions.
With regards to mass-fixing it, I've seen several patches seen
to media fixing bugs due to the bad usage_count decrement logic.
So, the best is to solve them all at once, and stop using
pm_runtime_get_sync() inside the subsystem.
Thanks,
Mauro
