linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mark Gross <markgross@kernel.org>,
	Andy Shevchenko <andy@kernel.org>, Pavel Machek <pavel@ucw.cz>,
	Lee Jones <lee@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Daniel Scally <djrscally@gmail.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	platform-driver-x86@vger.kernel.org, linux-leds@vger.kernel.org,
	linux-gpio@vger.kernel.org, Kate Hsuan <hpa@redhat.com>,
	Mark Pearson <markpearson@lenovo.com>,
	Andy Yeh <andy.yeh@intel.com>, Yao Hao <yao.hao@intel.com>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH v3 06/11] v4l: subdev: Make the v4l2-subdev core code enable/disable the privacy LED if present
Date: Fri, 16 Dec 2022 16:45:29 +0100	[thread overview]
Message-ID: <c0fc35eb-9b26-c1c6-3f85-234acbee0ff8@redhat.com> (raw)
In-Reply-To: <Y5x5D4kTnEpcHzsT@pendragon.ideasonboard.com>

Hi,

On 12/16/22 14:56, Laurent Pinchart wrote:
> Hi Hans,
> 
> Thank you for the patch.
> 
> On Fri, Dec 16, 2022 at 12:30:08PM +0100, Hans de Goede wrote:
>> Extend the call_s_stream() wrapper to enable/disable sensor privacy LEDs
>> for sensors with a privacy LED, rather then having to duplicate this code
>> in all the sensor drivers.
>>
>> Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>>  drivers/media/v4l2-core/v4l2-subdev.c | 40 +++++++++++++++++++++++++++
>>  include/media/v4l2-subdev.h           |  3 ++
>>  2 files changed, 43 insertions(+)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c
>> index 4988a25bd8f4..7344f6cd58b7 100644
>> --- a/drivers/media/v4l2-core/v4l2-subdev.c
>> +++ b/drivers/media/v4l2-core/v4l2-subdev.c
>> @@ -318,10 +318,44 @@ static int call_get_mbus_config(struct v4l2_subdev *sd, unsigned int pad,
>>  	       sd->ops->pad->get_mbus_config(sd, pad, config);
>>  }
>>  
>> +#if IS_REACHABLE(CONFIG_LEDS_CLASS)
>> +#include <linux/leds.h>
> 
> Can this be moved to the top of the file ? It doesn't have to be
> conditionally compiled there.

You mean just the #include right? Ack to that.

> 
>> +
>> +static void call_s_stream_update_pled(struct v4l2_subdev *sd, int enable)
>> +{
>> +	if (!sd->dev)
>> +		return;
>> +
>> +	/* Try to get privacy-led once, at first s_stream() */
>> +	if (!sd->privacy_led)
>> +		sd->privacy_led = led_get(sd->dev, "privacy-led");
> 
> I'm not sure I like this much. If the LED provider isn't available
> (yet), the LED will stay off. That's a privacy concern.

At first I tried to put the led_get() inside v4l2_async_register_subdev_sensor(),
which could then return an error like -EPROBE_DEFER if the led_get()
fails (and nicely limits the led_get() to sensors).

The problem which I hit is that v4l2-fwnode.c is build according to
CONFIG_V4L2_FWNODE where as v4l2-subdev.c is build according to
CONFIG_VIDEO_DEV 

And e.g. CONFIG_VIDEO_DEV could be builtin while CONFIG_V4L2_FWNODE
could be a module and then having the #if IS_REACHABLE(CONFIG_LEDS_CLASS)
spread over the 2 could result in different answers in the different
files ...

One solution here could be to change CONFIG_V4L2_FWNODE and V4L2_ASYNC
to bools and link the (quite small) objects for these 2 into videodev.ko:

videodev-$(CONFIG_V4L2_FWNODE) += v4l2-fwnode.o
videodev-$(CONFIG_V4L2_ASYNC) += v4l2-async.o






> 
>> +
>> +	if (IS_ERR(sd->privacy_led))
>> +		return;
>> +
>> +	mutex_lock(&sd->privacy_led->led_access);
>> +
>> +	if (enable) {
>> +		led_sysfs_disable(sd->privacy_led);
>> +		led_trigger_remove(sd->privacy_led);
>> +		led_set_brightness(sd->privacy_led, sd->privacy_led->max_brightness);
>> +	} else {
>> +		led_set_brightness(sd->privacy_led, 0);
>> +		led_sysfs_enable(sd->privacy_led);
> 
> I don't think you should reenable control through sysfs here. I don't
> really see a use case, and you've removed the trigger anyway, so the
> behaviour would be quite inconsistent.

Hmm, I thought this was a good compromise, this way the LED
can be used for other purposes when the sensor is off if users
want to.

Right if users want to use a trigger then they would need
to re-attach the trigger after using the camera.

But this way at least they can use the LED for other purposes
which since many users don't use their webcam that often
might be interesting for some users ...

And this is consistent with how flash LEDs are handled.

> Also, I think it would be better if the LED device was marked as "no
> sysfs" when it is registered.

If we decide to permanently disallow userspace access then
yes this is an option. Or maybe better (to keep the LED
drivers generic), do the disable directly after the led_get() ?



> 
>> +	}
>> +
>> +	mutex_unlock(&sd->privacy_led->led_access);
>> +}
>> +#else
>> +static void call_s_stream_update_pled(struct v4l2_subdev *sd, int enable) {}
>> +#endif
>> +
>>  static int call_s_stream(struct v4l2_subdev *sd, int enable)
>>  {
>>  	int ret;
>>  
>> +	call_s_stream_update_pled(sd, enable);
>> +
>>  	ret = sd->ops->video->s_stream(sd, enable);
>>  
>>  	if (!enable && ret < 0) {
> 
> You need to turn the LED off when enabling if .s_stream() fails.

Ack.

Regards,

Hans


  parent reply	other threads:[~2022-12-16 15:46 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-16 11:30 [PATCH v3 00/11] leds: lookup-table support + int3472/media privacy LED support Hans de Goede
2022-12-16 11:30 ` [PATCH v3 01/11] leds: led-class: Add missing put_device() to led_put() Hans de Goede
2022-12-16 13:35   ` Andy Shevchenko
2022-12-16 13:55     ` Andy Shevchenko
2022-12-16 15:22       ` Hans de Goede
2022-12-16 11:30 ` [PATCH v3 02/11] leds: led-class: Add __led_get() helper function Hans de Goede
2022-12-16 13:54   ` Andy Shevchenko
2022-12-16 15:46     ` Hans de Goede
2022-12-16 11:30 ` [PATCH v3 03/11] leds: led-class: Add __of_led_get() helper Hans de Goede
2022-12-16 13:50   ` Andy Shevchenko
2022-12-16 15:52     ` Hans de Goede
2022-12-16 16:05       ` Andy Shevchenko
2022-12-16 11:30 ` [PATCH v3 04/11] leds: led-class: Add __devm_led_get() helper Hans de Goede
2022-12-16 11:30 ` [PATCH v3 05/11] leds: led-class: Add generic [devm_]led_get() Hans de Goede
2022-12-16 13:43   ` Andy Shevchenko
2022-12-16 15:54     ` Hans de Goede
2022-12-16 16:07       ` Andy Shevchenko
2022-12-16 16:12         ` Hans de Goede
2022-12-16 14:15   ` Andy Shevchenko
2022-12-18 23:20   ` Linus Walleij
2022-12-16 11:30 ` [PATCH v3 06/11] v4l: subdev: Make the v4l2-subdev core code enable/disable the privacy LED if present Hans de Goede
2022-12-16 13:56   ` Laurent Pinchart
2022-12-16 13:59     ` Laurent Pinchart
2022-12-16 15:45     ` Hans de Goede [this message]
2022-12-16 16:44       ` Laurent Pinchart
2022-12-16 16:52         ` Hans de Goede
2022-12-16 14:02   ` Andy Shevchenko
2022-12-16 16:12     ` Hans de Goede
2022-12-16 11:30 ` [PATCH v3 07/11] platform/x86: int3472/discrete: Refactor GPIO to sensor mapping Hans de Goede
2022-12-16 13:57   ` Andy Shevchenko
2022-12-16 16:15     ` Hans de Goede
2022-12-16 16:26       ` Andy Shevchenko
2022-12-16 11:30 ` [PATCH v3 08/11] platform/x86: int3472/discrete: Create a LED class device for the privacy LED Hans de Goede
2022-12-16 14:16   ` Andy Shevchenko
2022-12-16 16:29     ` Hans de Goede
2022-12-16 17:14       ` Andy Shevchenko
2023-01-11 11:35         ` Hans de Goede
2022-12-16 11:30 ` [PATCH v3 09/11] platform/x86: int3472/discrete: Move GPIO request to skl_int3472_register_clock() Hans de Goede
2022-12-16 14:20   ` Andy Shevchenko
2022-12-16 16:35     ` Hans de Goede
2022-12-16 17:15       ` Andy Shevchenko
2022-12-16 11:30 ` [PATCH v3 10/11] platform/x86: int3472/discrete: Ensure the clk/power enable pins are in output mode Hans de Goede
2022-12-16 11:30 ` [PATCH v3 11/11] platform/x86: int3472/discrete: Get the polarity from the _DSM entry Hans de Goede
2022-12-16 14:57   ` Andy Shevchenko
2022-12-16 14:57     ` Andy Shevchenko
2022-12-16 16:42     ` Hans de Goede
2022-12-16 17:20       ` Andy Shevchenko
2022-12-16 12:02 ` [PATCH v3 00/11] leds: lookup-table support + int3472/media privacy LED support Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c0fc35eb-9b26-c1c6-3f85-234acbee0ff8@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andy.yeh@intel.com \
    --cc=andy@kernel.org \
    --cc=djrscally@gmail.com \
    --cc=hpa@redhat.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=lee@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=markgross@kernel.org \
    --cc=markpearson@lenovo.com \
    --cc=mchehab@kernel.org \
    --cc=pavel@ucw.cz \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=yao.hao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).