From: Petar Stepanovic <pstepanovic@axiado.com>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: "Akhila Kavi" <akavi@axiado.com>,
"Prasad Bolisetty" <pbolisetty@axiado.com>,
"Jonathan Cameron" <jic23@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Harshit Shah" <hshah@axiado.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] iio: adc: add Axiado SARADC driver
Date: Tue, 9 Jun 2026 11:09:32 +0200 [thread overview]
Message-ID: <1e2f4756-e944-473a-b4d7-a5692f2b609f@axiado.com> (raw)
In-Reply-To: <aiMU2bOFgKT9NrNQ@ashevche-desk.local>
On 6/5/2026 8:26 PM, Andy Shevchenko wrote:
>> +config AXIADO_SARADC
>> + tristate "Axiado SARADC driver"
>> + depends on ARCH_AXIADO || COMPILE_TEST
>> + depends on OF
> No, in IIO we want a good justification on non-agnostic requirements.
> Why can't this device driver be agnostic?
>
Hi Andy,
Thanks for the review. I will address the comments in v2.
You are right. The driver does not have a hard dependency on OF.
It only uses the OF match table for Device Tree based probing, but the
driver itself can use generic device APIs and does not need to be limited
to OF-only systems.
I will drop the `depends on OF` dependency and use generic match-data
handling where applicable.
...
>> + iowrite32(AX_SARADC_MANUAL_CTRL_EN(chan->channel),
>> + info->regs + AX_SARADC_MANUAL_CTRL);
> Why not writel()?
There is no special reason to use iowrite32() here. This is a normal
MMIO resource, so I will switch the driver to readl()/writel().
...
>> +static int axiado_saradc_probe(struct platform_device *pdev)
>> +{
>> + struct axiado_saradc *info;
>> + const struct axiado_saradc_soc_data *soc_data;
>> + struct iio_dev *indio_dev;
>> + int ret;
>> + u32 reg;
>> +
>> + indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
>> + if (!indio_dev)
>> + return -ENOMEM;
>> +
>> + info = iio_priv(indio_dev);
>> +
>> + info->regs = devm_platform_ioremap_resource(pdev, 0);
>> + if (IS_ERR(info->regs))
>> + return PTR_ERR(info->regs);
>> +
>> + info->clk = devm_clk_get_enabled(&pdev->dev, NULL);
> Why no name? It will make harder for the next generations of HW in case they
> want more than one clock to be used.
This IP block currently has only one clock input, so I used the unnamed clock.
Since there is no ambiguity for the current hardware, I would prefer to keep
the binding simple unless a named clock is required.
...
>> + reg = FIELD_PREP(AX_SARADC_CH_EN_MASK,
>> + GENMASK(soc_data->num_channels - 1, 0)) |
>> + AX_SARADC_SAMPLE_16 | AX_SARADC_MODE | AX_SARADC_ENABLE;
> FIELD_PREP_CONST() ?
FIELD_PREP_CONST() cannot be used here because the channel-enable value is
derived from soc_data->num_channels, which is runtime match data.
Best regards,
Petar
next prev parent reply other threads:[~2026-06-09 9:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 8:10 [PATCH 0/3] Subject: [PATCH 0/3] iio: adc: Add " Petar Stepanovic
2026-05-28 8:10 ` [PATCH 1/3] dt-bindings: iio: adc: add Axiado AX3000/AX3005 SARADC Petar Stepanovic
2026-05-28 9:20 ` Jonathan Cameron
2026-05-28 16:58 ` Conor Dooley
2026-05-28 8:10 ` [PATCH 2/3] iio: adc: add Axiado SARADC driver Petar Stepanovic
2026-05-28 9:02 ` Joshua Crofts
2026-05-28 9:44 ` Jonathan Cameron
2026-06-02 10:27 ` Petar Stepanovic
2026-06-05 18:26 ` Andy Shevchenko
2026-06-09 9:09 ` Petar Stepanovic [this message]
2026-06-09 13:26 ` Andy Shevchenko
2026-05-28 8:10 ` [PATCH 3/3] MAINTAINERS: add Axiado SARADC driver entry Petar Stepanovic
2026-05-28 8:29 ` Joshua Crofts
2026-05-28 9:17 ` [PATCH 0/3] Subject: [PATCH 0/3] iio: adc: Add Axiado SARADC driver Jonathan Cameron
2026-06-03 14:19 ` Andy Shevchenko
2026-06-05 18:16 ` Andy Shevchenko
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=1e2f4756-e944-473a-b4d7-a5692f2b609f@axiado.com \
--to=pstepanovic@axiado.com \
--cc=akavi@axiado.com \
--cc=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=hshah@axiado.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=pbolisetty@axiado.com \
--cc=robh@kernel.org \
/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
all inboxes | Powered by JetHome®