linux-kernel - Re: [PATCH 0/3] iio: light: veml6030: add support for veml7700

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] [day] [month] [year] [list]

Message-ID: <20241012151146.3cd5464b@jic23-huawei>
Date: Sat, 12 Oct 2024 15:11:46 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Javier Carrasco <javier.carrasco.cruz@...il.com>
Cc: Lars-Peter Clausen <lars@...afoo.de>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Rishi Gupta <gupt21@...il.com>, Jonathan Cameron
 <Jonathan.Cameron@...wei.com>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 0/3] iio: light: veml6030: add support for veml7700

On Mon, 07 Oct 2024 22:36:35 +0200
Javier Carrasco <javier.carrasco.cruz@...il.com> wrote:

> This series adds support for the veml7700 ALS sensor, which is basically
> a vem6030 within a different package, with no pins for the interrupt and
> the I2C address. The changes introduced are meant to hide the event
> functionality in that case, while borrowing the rest from the veml6030.
> 
> In theory, the interrupt functionality would still be available as all
> the registers are the same, and some polling could be done to read the
> threshold indicators to generate events. I did not find examples in iio
> where the INIT_DELAYED_WORK() queue_delayed_work() mechanism is used for
> that (some drivers do it to read results), so I am not sure if that
> would be the desired approach. I am open for discussions about that, but
> probably to be applied later on.
> 
> While testing this "no_irq" device, I noticed that the veml6035 is still
> using dedicated structs for the iio_info, which were there to account
> for the device-specific attribute values before read_avail() was
> introduced in the driver in later versions of the patch series, and they
> managed to survive until v3 was applied.
> Once read_avail() was introduced, the device-specific structs were not
> required anymore, and they are repetitive. Moreover, the initialization
> of the no_irq iio_info for the veml6035 was not updated to account for
> the new read_avail(), which is a bug if no irq is provided, as there is
> no callback to retrieve the available values.
> 
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@...il.com>
Series applied to the to togreg branch of iio.git. Pushed out as testing for 
0-day to take a first look at it.

Jonathan

> ---
> Javier Carrasco (3):
>       iio: light: veml6035: fix read_avail in no_irq case for veml6035
>       dt-bindings: iio: light: veml6030: add veml7700
>       iio: light: veml6030: add support for veml7700
> 
>  .../bindings/iio/light/vishay,veml6030.yaml        |  16 ++-
>  drivers/iio/light/veml6030.c                       | 130 ++++++++++++++-------
>  2 files changed, 106 insertions(+), 40 deletions(-)
> ---
> base-commit: 96be67caa0f0420d4128cb67f07bbd7a6f49e03a
> change-id: 20241007-veml7700-83f54cf94262
> 
> Best regards,