Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 8 Jul 2023 17:16:21 +0100
From:   Jonathan Cameron <jic23@kernel.org>
To:     Matti Vaittinen <mazziesaccount@gmail.com>
Cc:     Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>, linux-iio@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] iio: light: bu27008: add chip info
Message-ID: <20230708171621.616fad8f@jic23-huawei>
In-Reply-To: <b4cdb81ef9522e94150673b3b78a4cbae5fa67f2.1688723839.git.mazziesaccount@gmail.com>
References: <cover.1688723839.git.mazziesaccount@gmail.com>
        <b4cdb81ef9522e94150673b3b78a4cbae5fa67f2.1688723839.git.mazziesaccount@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Fri, 7 Jul 2023 14:23:03 +0300
Matti Vaittinen <mazziesaccount@gmail.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@gmail.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);