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: 7+ 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 4/8] dt-bindings: iio: dfsdm: move to backend framework Olivier Moysan
2024-07-08 17:08 ` Rob Herring
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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox