Hi both On 20/01/2021 11:44, Andy Shevchenko wrote: > On Wed, Jan 20, 2021 at 06:18:53AM +0200, Laurent Pinchart wrote: >> On Tue, Jan 19, 2021 at 07:43:15PM +0200, Andy Shevchenko wrote: >>> On Tue, Jan 19, 2021 at 06:36:31PM +0200, Laurent Pinchart wrote: >>>> On Tue, Jan 19, 2021 at 11:33:58AM +0200, Andy Shevchenko wrote: >>>>> On Tue, Jan 19, 2021 at 12:11:40AM +0000, Daniel Scally wrote: >>>>>> On 18/01/2021 21:19, Daniel Scally wrote: > ... > >>>>> See my previous reply. TL;DR: you have to modify clk-gpio.c to export couple of >>>>> methods to be able to use it as a library. >>>> That seems really overkill given the very simple implementation of the >>>> clock provided here. >>> Less code in the end is called an overkill? Hmm... >>> I think since we in Linux it's better to utilize what it provides. Do you want >>> me to prepare a patch to show that there is no overkill at all? >> The amount of code we would save it very small. It's not necessarily a >> bad idea, but I think such an improvement could be made on top, it >> shouldn't block this series. > Okay, let's wait what Dan will say on this. > I can probably help to achieve this improvement sooner than later. Well; turns out that we missed an operation we really need to add (clk_recalc_rate) which in our case needs to read a fixed value stored in a buffer in ACPI; most of the code is shared with an existing function in the driver so it's not much extra to add, but I think it kinda precludes using clk-gpio for this anyway >>>>>> (also, Laurent, if we did it this way we wouldn't be able to also handle >>>>>> the led-indicator GPIO here without some fairly major rework) >>>>> LED indicators are done as LED class devices (see plenty of examples in PDx86 >>>>> drivers: drivers/platform/x86/) >>>> How do you expose the link between the sensor and its indicator LED to >>>> userspace ? Isn't it better to handle it in the kernel to avoid rogue >>>> userspace turning the camera on without notifying the user ? >>> I didn't get this. It's completely a LED handling driver business. We may >>> expose it to user space or not, but it's orthogonal to the usage of LED class >>> IIUC. Am I mistaken here? >> If it stays internal to the kernel and is solely controlled from the >> int3472 driver, there's no need to involve the LED class. If we want to >> expose the privacy LED to userspace then the LED framework is the way to >> go, but we will also need to find a way to expose the link between the >> camera sensor and the LED to userspace. If there are two privacy LEDs, >> one for the front sensor and one for the back sensor, userspace will >> need to know which is which. > I see. For now we probably can keep GPIO LED implementation internally. >
