linux-kernel - Re: [PATCH v2 2/3] iio: light: bu27008: add chip info

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]

Message-ID: <20230708171621.616fad8f@jic23-huawei>
Date:   Sat, 8 Jul 2023 17:16:21 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Matti Vaittinen <mazziesaccount@...il.com>
Cc:     Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>, linux-iio@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/3] iio: light: bu27008: add chip info

On Fri, 7 Jul 2023 14:23:03 +0300
Matti Vaittinen <mazziesaccount@...il.com> wrote:

> The ROHM BU27010 RGB + flickering sensor is in many regards similar to
> the BU27008. Prepare for adding support for BU27010 by allowing
> chip-specific properties to be brought from the of_device_id data.
> 
> Signed-off-by: Matti Vaittinen <mazziesaccount@...il.com>
> 
One trivial comment.

The ffs stuff is a pain.  There have been a few goes at defining
standard functions for doing that but I don' think anything ever landed
upstream.

> ---
> Revision history:
> v1 => v2:
>  - Move all generic refactoring from next patch to this one so that the
>    next one will only contain the BU27010 specific additions.
>  - reorder bu27008 chip-data assignments to match the struct member
>    placement
>  - Cleanup
> ---
>  drivers/iio/light/rohm-bu27008.c | 323 ++++++++++++++++++++-----------
>  1 file changed, 208 insertions(+), 115 deletions(-)
> 
> diff --git a/drivers/iio/light/rohm-bu27008.c b/drivers/iio/light/rohm-bu27008.c
> index b50bf8973d9a..08e2b1194bf4 100644
> --- a/drivers/iio/light/rohm-bu27008.c
> +++ b/drivers/iio/light/rohm-bu27008.c
> @@ -211,7 +211,35 @@ static const struct iio_chan_spec bu27008_channels[] = {


> @@ -993,14 +1086,14 @@ static int bu27008_probe(struct i2c_client *i2c)
>  	data->dev = dev;
>  	data->irq = i2c->irq;
>  
> -	idev->channels = bu27008_channels;
> +	idev->channels = &bu27008_channels[0];

Why?  When setting a pointer to the 'whole' array I tend to prefer
the original. Can't see a reason why this should be changed to the
second one.


>  	idev->num_channels = ARRAY_SIZE(bu27008_channels);
> -	idev->name = "bu27008";
> +	idev->name = data->cd->name;
>  	idev->info = &bu27008_info;
>  	idev->modes = INDIO_DIRECT_MODE;
>  	idev->available_scan_masks = bu27008_scan_masks;
>  
> -	ret = bu27008_chip_init(data);
> +	ret = data->cd->chip_init(data);
>  	if (ret)
>  		return ret;
>  
> @@ -1021,7 +1114,7 @@ static int bu27008_probe(struct i2c_client *i2c)
>  }
>  
>  static const struct of_device_id bu27008_of_match[] = {
> -	{ .compatible = "rohm,bu27008" },
> +	{ .compatible = "rohm,bu27008", .data = &bu27008_chip },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, bu27008_of_match);