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: 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ