From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2358C4321E for ; Wed, 30 Nov 2022 16:30:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230232AbiK3Qal (ORCPT ); Wed, 30 Nov 2022 11:30:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230159AbiK3Qab (ORCPT ); Wed, 30 Nov 2022 11:30:31 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7DF6E2ED40 for ; Wed, 30 Nov 2022 08:29:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669825775; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Y1PU8u2hxhHX+po+T8EOrOjAcOQeKfP7OIdF96OKHDU=; b=ExSNVE6tvT2iiyztBExHgevHONr6rdeFIegF52SVOPp+Q+NDxd/VnCK0C5+wGvqBM47nUa d8uMlc9wULH9JBDl1HFAzuD229JUw/TGhAtvMZbI2jxvX3JRmFxYr/JnJeWqzE0pvn9zvY z5+8wJ1h9fjnTI1gO44/atlYxtc+oK4= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-381-dwhzyeQ3OGSoMl8uyf57FQ-1; Wed, 30 Nov 2022 11:29:33 -0500 X-MC-Unique: dwhzyeQ3OGSoMl8uyf57FQ-1 Received: by mail-ed1-f72.google.com with SMTP id c9-20020a05640227c900b00463de74bc15so10135532ede.13 for ; Wed, 30 Nov 2022 08:29:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Y1PU8u2hxhHX+po+T8EOrOjAcOQeKfP7OIdF96OKHDU=; b=Iwt17F62I7qAMxIFoQy8sy9w4pab0BoGJip2Lz3Nre7z8Ws7LHviClfUE4IfZ5yXmr mdig/ygYwERRDkFkAi6wOsDaPZb7StwksbyjZiBPyf95i/87v0MycAYf1L4lArU6neiB UlSSDBvZDmZcSkwYu1REeXh/9OVwDAUtGB0r0xO959AK0lf2XLJP+fViVsoefMiNzmdH +vJsXv8zFriVuZjM+LvAx6UI4i4TdpWoWh13juMswxeqCBkOSo2mgO0L0ld/yvXRkhp3 abfGsCUf2eZ02R0o3s70VqMXSTjxGt0qtlZYpfEpMyS5zS72TsdlHs78azQYwiZTRSib EUZA== X-Gm-Message-State: ANoB5pmleOFcGexXE6CiA325rKHO1V/VNghNoL6+SXsVU7I0/vc3+SZW q7npCJhybwDAjqV0JD9Iau4jm7CFHei35w6+0I+uWtrswGr4Vtb2KUSVyS8di6qG5WFNQsrUqsL buoDFS7U5rzQ5bjmN6avcz8Vd1oMtzF9ACg== X-Received: by 2002:a17:907:c24a:b0:7ac:2e16:bc31 with SMTP id tj10-20020a170907c24a00b007ac2e16bc31mr13148572ejc.242.1669825772606; Wed, 30 Nov 2022 08:29:32 -0800 (PST) X-Google-Smtp-Source: AA0mqf4NynBhLwKJjiZx/eua28kPuRfimcteNpDpW5XitulAlvMAH4oYkzrgcX4xxlFILODzRLYUXQ== X-Received: by 2002:a17:907:c24a:b0:7ac:2e16:bc31 with SMTP id tj10-20020a170907c24a00b007ac2e16bc31mr13148552ejc.242.1669825772365; Wed, 30 Nov 2022 08:29:32 -0800 (PST) Received: from ?IPV6:2001:1c00:c1e:bf00:d69d:5353:dba5:ee81? (2001-1c00-0c1e-bf00-d69d-5353-dba5-ee81.cable.dynamic.v6.ziggo.nl. [2001:1c00:c1e:bf00:d69d:5353:dba5:ee81]) by smtp.gmail.com with ESMTPSA id ay17-20020a056402203100b00461e4498666sm794605edb.11.2022.11.30.08.29.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Nov 2022 08:29:31 -0800 (PST) Message-ID: Date: Wed, 30 Nov 2022 17:29:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH 1/6] media: ov5693: Add support for a privacy-led GPIO Content-Language: en-US, nl To: Laurent Pinchart , Sakari Ailus Cc: Mark Gross , Andy Shevchenko , Daniel Scally , platform-driver-x86@vger.kernel.org, Kate Hsuan , Mark Pearson , linux-media@vger.kernel.org References: <20221129231149.697154-1-hdegoede@redhat.com> <20221129231149.697154-2-hdegoede@redhat.com> From: Hans de Goede In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: platform-driver-x86@vger.kernel.org Hi, On 11/30/22 16:20, Laurent Pinchart wrote: > On Wed, Nov 30, 2022 at 02:52:50PM +0000, Sakari Ailus wrote: >> On Wed, Nov 30, 2022 at 02:56:46PM +0100, Hans de Goede wrote: >>> On 11/30/22 14:41, Sakari Ailus wrote: >>>> On Wed, Nov 30, 2022 at 12:11:44AM +0100, Hans de Goede wrote: >>>>> Add support for a privacy-led GPIO. >>>>> >>>>> Making the privacy LED to controlable from userspace, as using the LED >>>>> class subsystem would do, would make it too easy for spy-ware to disable >>>>> the LED. >>>>> >>>>> To avoid this have the sensor driver directly control the LED. >>>>> >>>>> Signed-off-by: Hans de Goede >>>>> --- >>>>> Note an additional advantage of directly controlling the GPIO is that >>>>> GPIOs are tied directly to consumer devices. Where as with a LED class >>>>> device, there would need to be some mechanism to tie the right LED >>>>> (e.g front or back) to the right sensor. >>>> >>>> Thanks for the patch. >>>> >>>> This approach has the drawback that support needs to be added for each >>>> sensor separately. Any idea how many sensor drivers might need this? >>> >>> Quite a few probably. But as discussed here I plan to write a generic >>> sensor_power helper library since many sensor drivers have a lot of >>> boilerplate code to get clks + regulators + enable/reset gpios. The plan >>> is to add support for a "privacy-led" to this library so that all sensors >>> which use this get support for free. >> >> I'm not sure how well this could be generalised. While most sensors do >> something similar there are subtle differences. If those can be taken into >> account I guess it should be doable. But would it simplify things or reduce >> the number of lines of code as a whole? > > While I think we need a camera sensor helper, I also doubt managing the > power sequence in the helper would help much. The privacy LED, however, > could be handled there. >From a quick peek most of the sensor drivers I've looked at (which is only a few) do: -bulk-enable-regulators -enable 1 clk -set bunch of gpios -sleep a bit Since this requires to first get all the resources for this, which needs error checking + reporting and then requires also error checking the actual enabling + rollback on failure this is quite a bit of code duplicated against many sensor drivers. I agree that if a sensor does not fit in this model, that it then should not use the helper and just open code the sequence but I believe that for a bunch of sensor drivers with a simple power-on sequence this can remove a bunch of code duplication. Anways this is a clear case of the proof is in the tasting of the pudding. So when I can make some time for this I'll submit a patch series with the helper + converting a couple of sensors (those which I can test) and then we can see from there. >> The privacy LED is separate from sensor, including its power on/off >> sequences which suggests it could be at least as well be handled >> separately. > > And if the privacy LED is controllable through a GPIO, I think it should > be turned on at stream on time, not at power on time. That would allow > things like reading the OTP data from the sensor without flashing the > privacy LED. Agreed. Regards, Hans