linux-kernel - Re: [PATCH v2 1/1] media: v4l: Don't turn on privacy LED if streamon fails

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]

Message-ID: <ZhzUHs7lpdeMa22l@kekkonen.localdomain>
Date: Mon, 15 Apr 2024 07:15:42 +0000
From: Sakari Ailus <sakari.ailus@...ux.intel.com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: linux-media@...r.kernel.org, tomi.valkeinen@...asonboard.com,
	Hans de Goede <hdegoede@...hat.com>,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Hans Verkuil <hverkuil@...all.nl>,
	Umang Jain <umang.jain@...asonboard.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/1] media: v4l: Don't turn on privacy LED if streamon
 fails

Hi Laurent,

On Fri, Apr 12, 2024 at 08:46:21PM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> Thank you for the patch.
> 
> On Wed, Apr 10, 2024 at 02:47:12PM +0300, Sakari Ailus wrote:
> > Turn on the privacy LED only if streamon succeeds. This can be done after
> > enabling streaming on the sensor.
> > 
> > Fixes: b6e10ff6c23d ("media: v4l2-core: Make the v4l2-core code enable/disable the privacy LED if present")
> > Signed-off-by: Sakari Ailus <sakari.ailus@...ux.intel.com>
> > ---
> >  drivers/media/v4l2-core/v4l2-subdev.c | 22 ++++++++++++----------
> >  1 file changed, 12 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c
> > index 4c6198c48dd6..012b757eac9f 100644
> > --- a/drivers/media/v4l2-core/v4l2-subdev.c
> > +++ b/drivers/media/v4l2-core/v4l2-subdev.c
> > @@ -412,15 +412,6 @@ static int call_s_stream(struct v4l2_subdev *sd, int enable)
> >  	if (WARN_ON(!!sd->enabled_streams == !!enable))
> >  		return 0;
> >  
> > -#if IS_REACHABLE(CONFIG_LEDS_CLASS)
> > -	if (!IS_ERR_OR_NULL(sd->privacy_led)) {
> > -		if (enable)
> > -			led_set_brightness(sd->privacy_led,
> > -					   sd->privacy_led->max_brightness);
> > -		else
> > -			led_set_brightness(sd->privacy_led, 0);
> > -	}
> > -#endif
> >  	ret = sd->ops->video->s_stream(sd, enable);
> >  
> >  	if (!enable && ret < 0) {
> > @@ -428,9 +419,20 @@ static int call_s_stream(struct v4l2_subdev *sd, int enable)
> >  		ret = 0;
> >  	}
> >  
> > -	if (!ret)
> > +	if (!ret) {
> >  		sd->enabled_streams = enable ? BIT(0) : 0;
> >  
> > +#if IS_REACHABLE(CONFIG_LEDS_CLASS)
> > +		if (!IS_ERR_OR_NULL(sd->privacy_led)) {
> > +			if (enable)
> > +				led_set_brightness(sd->privacy_led,
> > +						   sd->privacy_led->max_brightness);
> > +			else
> > +				led_set_brightness(sd->privacy_led, 0);
> > +		}
> > +#endif
> 
> This means that the LED will be turned slightly after the camera is
> enabled. I don't think it's an issue in practice. Another possibly more

That's what I'd think as well. Typically even the exposure time is much,
much longer than what it takes to get here.

> important concern is that we should maybe check the return value of
> led_set_brightness(), and fail .s_stream() when we can't enable the
> privacy LED at stream on time. In that case, it would be best to keep
> turning the privacy LED on before calling .s_stream(). It should still
> be turned off only after calling .s_stream() though.

The return type of led_set_brightness() is void. Maybe because a large
majority is GPIO-controlled?

-- 
Regards,

Sakari Ailus