linux-kernel - Re: [PATCH 4/4] media: mt9m111: remove .s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 19 Aug 2022 10:06:26 +0200
From:   Marco Felsch <m.felsch@...gutronix.de>
To:     Jacopo Mondi <jacopo@...ndi.org>
Cc:     mchehab@...nel.org, sakari.ailus@...ux.intel.com,
        laurent.pinchart+renesas@...asonboard.com,
        jacopo+renesas@...ndi.org, akinobu.mita@...il.com,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel@...gutronix.de
Subject: Re: [PATCH 4/4] media: mt9m111: remove .s_power callback

On 22-08-19, Jacopo Mondi wrote:
> Hi Marco
> 
> On Fri, Aug 19, 2022 at 09:18:32AM +0200, Marco Felsch wrote:
> > Hi Jacopo,
> >
> > thanks for your fast feedback :)
> >
> > On 22-08-18, Jacopo Mondi wrote:
> > > Hi Marco
> > >
> > > On Thu, Aug 18, 2022 at 04:47:12PM +0200, Marco Felsch wrote:
> > > > This is in preparation of switching to the generic dev PM mechanism.
> > > > Since the .s_power callback will be removed in the near future move the
> > > > powering into the .s_stream callback. So this driver no longer depends
> > > > on the .s_power mechanism.
> > > >
> > > > Signed-off-by: Marco Felsch <m.felsch@...gutronix.de>
> > >
> > > If you want to move to runtime_pm, I would implement it first and have
> > > s_power call the _resume and _suspend routines, as some platform
> > > drivers still use s_power() and some of them might depend on it.
> >
> > Do we really have platforms which depend on this? IMHO if that is the
> 
> $ git grep "v4l2_subdev_call(.*, s_power" drivers/media/platform/  | cut -d : -f1 | uniq  | wc -l
> 8
> 
> > case than we should fix those platfoms. Since new drivers shouldn't use
> > this callback anymore.
> 
> Patches are clearly welcome I guess..

:)

> > In my case, I worked on [1] and wondered why the sensor was enabled
> > before I told him to do so. Since I didn't implement the s_power()
> > callback, I had no chance to get enabled before.
> >
> 
> I'm not sure I got this part

What I mean is, that the MT9M131 sensor gets enabled and immediately
start sending frames before I told him to do so e.g. by calling
s_stream(). This can confuse the downstream device. The only way to get
enable the downstream device first is to add the s_power() callback.

> > Can we please decide:
> >  - Do we wanna get rid of the s_power() callback?
> 
> I think that would be everyone's desire, but drivers have to be moved
> away from it
> 
> >  - If not, how do we handle those devices then with drivers not
> >    implementing this callback?
> 
> By maintaining compatibility. I suggested to move to runtime_pm() and
> wrap _resume/_suspend in s_power(). 

But then you're introducing new drivers with s_power() callbacks and so
the behaviour isn't really changed.

> My understanding is that the two (runtime_pm/s_power) are mutually
> exclusive, but even if that was not the case, runtime_pm is reference
> counted, hence as long as calls are balanced this should work, right ?

Right but the s_power() behaviour is not changed and drivers still rely
on it to work as right now.

Regards,
  Marco