From: Jonathan Cameron <jic23@kernel.org>
To: Olivier Moysan <olivier.moysan@foss.st.com>
Cc: <fabrice.gasnier@foss.st.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
<linux-iio@vger.kernel.org>,
<linux-stm32@st-md-mailman.stormreply.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 6/8] iio: adc: stm32-dfsdm: adopt generic channels bindings
Date: Sun, 7 Jul 2024 16:18:03 +0100 [thread overview]
Message-ID: <20240707161803.35b6f79f@jic23-huawei> (raw)
In-Reply-To: <20240704155338.2387858-7-olivier.moysan@foss.st.com>
On Thu, 4 Jul 2024 17:53:34 +0200
Olivier Moysan <olivier.moysan@foss.st.com> wrote:
> Move to generic channels binding to ease new backend framework adoption
> and prepare the convergence with MDF IP support on STM32MP2 SoC family.
>
> Legacy binding:
> DFSDM is an IIO channel consumer.
> SD modulator is an IIO channels provider.
> The channel phandles are provided in DT through io-channels property
> and channel indexes through st,adc-channels property.
>
> New binding:
> DFSDM is an IIO channel provider.
> The channel indexes are given by reg property in channel child node.
>
> This new binding is intended to be used with SD modulator IIO backends.
> It does not support SD modulator legacy IIO devices.
> The st,adc-channels property presence is used to discriminate
> between legacy and backend bindings.
>
> The support of the DFSDM legacy channels and SD modulator IIO devices
> is kept for backward compatibility.
>
> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Hi Olivier
A few minor comments inline given looks like you are going to be doing a v5.
Jonathan
> ---
> drivers/iio/adc/stm32-dfsdm-adc.c | 200 ++++++++++++++++++++++++------
> 1 file changed, 164 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
> index fabd654245f5..ae5d95e38cd7 100644
> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> @@ -666,6 +666,64 @@ static int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
> return 0;
> }
>
> +static int stm32_dfsdm_generic_channel_parse_of(struct stm32_dfsdm *dfsdm,
> + struct iio_dev *indio_dev,
> + struct iio_chan_spec *ch,
> + struct fwnode_handle *node)
> +{
> + struct stm32_dfsdm_channel *df_ch;
> + const char *of_str;
> + int ret, val;
> +
> + ret = fwnode_property_read_u32(node, "reg", &ch->channel);
> + if (ret < 0) {
> + dev_err(&indio_dev->dev, "Missing channel index %d\n", ret);
> + return ret;
I think this is only called from probe?
If so, return dev_err_probe() throughout is probably appropriate.
> + }
...
> @@ -1430,43 +1540,61 @@ static int stm32_dfsdm_adc_init(struct device *dev, struct iio_dev *indio_dev)
> {
...
> - for (chan_idx = 0; chan_idx < num_ch; chan_idx++) {
> - ch[chan_idx].scan_index = chan_idx;
> - ret = stm32_dfsdm_adc_chan_init_one(indio_dev, &ch[chan_idx]);
> - if (ret < 0) {
> - dev_err(&indio_dev->dev, "Channels init failed\n");
> - return ret;
> - }
> + adc->backend = devm_kzalloc(&indio_dev->dev, sizeof(*adc->backend) * num_ch,
devm_kcalloc maybe?
We aren't going to overflow here, but perhaps it is also more readable in that it makes
it clear this is an array of pointers.
However I also wanted to check the type of backend. Tricky as you don't introduce
it until 2 patches later. Fix that. Also on a series like this, make sure to
step patch by patch and ensure it at least builds. Otherwise bisection might not work
and people get very grumpy if that happens.
> + GFP_KERNEL);
> + if (!adc->backend)
> + return -ENOMEM;
> }
>
> - indio_dev->num_channels = num_ch;
> + ch = devm_kcalloc(&indio_dev->dev, num_ch, sizeof(*ch), GFP_KERNEL);
> + if (!ch)
> + return -ENOMEM;
> indio_dev->channels = ch;
>
> + if (legacy)
> + ret = stm32_dfsdm_chan_init(indio_dev, ch);
> + else
> + ret = stm32_dfsdm_generic_chan_init(indio_dev, ch);
> + if (ret < 0)
> + return ret;
> +
> init_completion(&adc->completion);
>
> /* Optionally request DMA */
next prev parent reply other threads:[~2024-07-07 15:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-04 15:53 [PATCH v4 0/8] iio: adc: dfsdm: add scaling support Olivier Moysan
2024-07-04 15:53 ` [PATCH v4 1/8] iio: add read scale and offset services to iio backend framework Olivier Moysan
2024-07-05 10:18 ` Nuno Sá
2024-07-04 15:53 ` [PATCH v4 2/8] iio: add enable and disable " Olivier Moysan
2024-07-04 15:53 ` [PATCH v4 3/8] iio: add child nodes support in " Olivier Moysan
2024-07-04 15:53 ` [PATCH v4 4/8] dt-bindings: iio: dfsdm: move to " Olivier Moysan
2024-07-08 17:08 ` Rob Herring
2024-07-04 15:53 ` [PATCH v4 5/8] dt-bindings: iio: add backend support to sd modulator Olivier Moysan
2024-07-04 16:36 ` Conor Dooley
2024-07-04 15:53 ` [PATCH v4 6/8] iio: adc: stm32-dfsdm: adopt generic channels bindings Olivier Moysan
2024-07-07 15:18 ` Jonathan Cameron [this message]
2024-07-04 15:53 ` [PATCH v4 7/8] iio: add iio backend support to sd modulator Olivier Moysan
2024-07-04 15:53 ` [PATCH v4 8/8] iio: adc: stm32-dfsdm: add scaling support to dfsdm Olivier Moysan
2024-07-07 15:21 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240707161803.35b6f79f@jic23-huawei \
--to=jic23@kernel.org \
--cc=alexandre.torgue@foss.st.com \
--cc=fabrice.gasnier@foss.st.com \
--cc=lars@metafoo.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=olivier.moysan@foss.st.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.