* [PATCH v5 01/13] iio: core: validate file offset in iio_debugfs_write_reg()
2026-05-17 18:37 [PATCH v5 00/13] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
@ 2026-05-17 18:37 ` Rodrigo Alencar via B4 Relay
2026-05-18 10:43 ` Rodrigo Alencar
2026-05-17 18:37 ` [PATCH v5 02/13] iio: core: support 64-bit register through debugfs Rodrigo Alencar via B4 Relay
` (11 subsequent siblings)
12 siblings, 1 reply; 28+ messages in thread
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar, sashiko-bot
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Check that a file offset is zero so that simple_write_to_buffer() can be
used safely, i.e., buf array is not left with uninitialized memory at its
start. It is not a big concern as it is a debug interface, but it is still
a hardening measure. The issue was introduced when direct call to
copy_from_user() was replaced by simple_write_to_buffer().
Fixes: 6d5dd486c715 ("iio: core: make use of simple_write_to_buffer()")
Reported-by: sashiko-bot@kernel.org
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
drivers/iio/industrialio-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index bd6f4f9f4533..e587aca79b8e 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -419,7 +419,7 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
char buf[80];
int ret;
- if (count >= sizeof(buf))
+ if (count >= sizeof(buf) || *ppos != 0)
return -EINVAL;
ret = simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, userbuf,
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v5 01/13] iio: core: validate file offset in iio_debugfs_write_reg()
2026-05-17 18:37 ` [PATCH v5 01/13] iio: core: validate file offset in iio_debugfs_write_reg() Rodrigo Alencar via B4 Relay
@ 2026-05-18 10:43 ` Rodrigo Alencar
0 siblings, 0 replies; 28+ messages in thread
From: Rodrigo Alencar @ 2026-05-18 10:43 UTC (permalink / raw)
To: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, sashiko-bot
On 26/05/17 07:04PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The `*ppos != 0` check introduces a functional regression for sequential writes, masking the true bug which is the inappropriate use of `simple_write_to_buffer()`.
> - [High] Unpatched uninitialized stack memory reads in other IIO drivers caused by the identical anti-pattern.
> --
>
> commit 7c5ddbc34738b9e84e226b9906348d61e3569bf4
> Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> iio: core: validate file offset in iio_debugfs_write_reg()
>
> This patch adds a check to ensure that the file offset is zero in
> iio_debugfs_write_reg() before calling simple_write_to_buffer(). This is
> intended to prevent leaving the start of the buffer uninitialized if a write
> occurs at a non-zero offset.
>
> > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> > index bd6f4f9f45330..e587aca79b8e7 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -419,7 +419,7 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
> > char buf[80];
> > int ret;
> >
> > - if (count >= sizeof(buf))
> > + if (count >= sizeof(buf) || *ppos != 0)
>
> Does this cause a functional regression for sequential writes?
>
> If a user writes multiple commands to the same open file descriptor, for
> example using (echo "cmd1"; echo "cmd2") > direct_reg_access, the first
> write advances the file position. This means *ppos will be non-zero on the
> second write, causing it to fail with -EINVAL.
>
> Before simple_write_to_buffer() was introduced, the code used
> copy_from_user() and ignored *ppos, correctly treating every write() call
> as a distinct command starting at the beginning of the buffer.
>
> Since simple_write_to_buffer() is designed for stateful linear memory buffers
> rather than stateless command endpoints using local stack arrays, would it be
> better to revert the use of simple_write_to_buffer() entirely and use
> copy_from_user() or strndup_user() to parse each write independently?
>
> Additionally, does this leave a similar pattern unpatched in other IIO
> drivers?
>
> While this patch addresses the issue in iio_debugfs_write_reg(), the same
> pattern of using simple_write_to_buffer() into a local stack array still
> exists in other locations:
>
> 1. iio_backend_debugfs_write_reg() in drivers/iio/industrialio-backend.c
> 2. ad3552r_hs_write_data_source() in drivers/iio/dac/ad3552r-hs.c
>
> Both functions use simple_write_to_buffer() into uninitialized local stack
> arrays without checking *ppos.
>
> Furthermore, ad9467_chan_test_mode_write() in drivers/iio/adc/ad9467.c
> uses the same pattern. While the buffer is zero-initialized there,
> sequential writes will still be functionally broken.
>
> > return -EINVAL;
This was me trying to fix an issue and maybe creating another.
Probably I would just drop this, and leave this to be handled later.
At least it was good to indicate that such issue exist.
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260517-ad9910-iio-driver-v5-0-31599c88314a@analog.com?part=1
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v5 02/13] iio: core: support 64-bit register through debugfs
2026-05-17 18:37 [PATCH v5 00/13] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
2026-05-17 18:37 ` [PATCH v5 01/13] iio: core: validate file offset in iio_debugfs_write_reg() Rodrigo Alencar via B4 Relay
@ 2026-05-17 18:37 ` Rodrigo Alencar via B4 Relay
2026-05-18 13:56 ` Rodrigo Alencar
2026-05-17 18:37 ` [PATCH v5 03/13] iio: core: add hierarchical channel relationships Rodrigo Alencar via B4 Relay
` (10 subsequent siblings)
12 siblings, 1 reply; 28+ messages in thread
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add debugfs_reg64_access function pointer field into iio_info and modify
file operation callbacks to favor 64-bit variant when it is available.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
drivers/iio/industrialio-core.c | 33 ++++++++++++++++++++++++---------
include/linux/iio/iio-opaque.h | 2 +-
include/linux/iio/iio.h | 4 ++++
3 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index e587aca79b8e..5c8404efd0a5 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -386,6 +386,7 @@ static ssize_t iio_debugfs_read_reg(struct file *file, char __user *userbuf,
struct iio_dev *indio_dev = file->private_data;
struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
unsigned int val = 0;
+ u64 val64 = 0;
int ret;
if (*ppos > 0)
@@ -393,9 +394,17 @@ static ssize_t iio_debugfs_read_reg(struct file *file, char __user *userbuf,
iio_dev_opaque->read_buf,
iio_dev_opaque->read_buf_len);
- ret = indio_dev->info->debugfs_reg_access(indio_dev,
- iio_dev_opaque->cached_reg_addr,
- 0, &val);
+ if (indio_dev->info->debugfs_reg64_access) {
+ ret = indio_dev->info->debugfs_reg64_access(indio_dev,
+ iio_dev_opaque->cached_reg_addr,
+ 0, &val64);
+ } else {
+ ret = indio_dev->info->debugfs_reg_access(indio_dev,
+ iio_dev_opaque->cached_reg_addr,
+ 0, &val);
+ val64 = val;
+ }
+
if (ret) {
dev_err(indio_dev->dev.parent, "%s: read failed\n", __func__);
return ret;
@@ -403,7 +412,7 @@ static ssize_t iio_debugfs_read_reg(struct file *file, char __user *userbuf,
iio_dev_opaque->read_buf_len = snprintf(iio_dev_opaque->read_buf,
sizeof(iio_dev_opaque->read_buf),
- "0x%X\n", val);
+ "0x%llX\n", val64);
return simple_read_from_buffer(userbuf, count, ppos,
iio_dev_opaque->read_buf,
@@ -415,8 +424,9 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
{
struct iio_dev *indio_dev = file->private_data;
struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
- unsigned int reg, val;
+ unsigned int reg;
char buf[80];
+ u64 val64;
int ret;
if (count >= sizeof(buf) || *ppos != 0)
@@ -429,7 +439,7 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
buf[ret] = '\0';
- ret = sscanf(buf, "%i %i", ®, &val);
+ ret = sscanf(buf, "%i %lli", ®, &val64);
switch (ret) {
case 1:
@@ -437,8 +447,12 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
break;
case 2:
iio_dev_opaque->cached_reg_addr = reg;
- ret = indio_dev->info->debugfs_reg_access(indio_dev, reg,
- val, NULL);
+ if (indio_dev->info->debugfs_reg64_access)
+ ret = indio_dev->info->debugfs_reg64_access(indio_dev, reg,
+ val64, NULL);
+ else
+ ret = indio_dev->info->debugfs_reg_access(indio_dev, reg,
+ val64, NULL);
if (ret) {
dev_err(indio_dev->dev.parent, "%s: write failed\n",
__func__);
@@ -469,7 +483,8 @@ static void iio_device_register_debugfs(struct iio_dev *indio_dev)
{
struct iio_dev_opaque *iio_dev_opaque;
- if (indio_dev->info->debugfs_reg_access == NULL)
+ if (!indio_dev->info->debugfs_reg_access &&
+ !indio_dev->info->debugfs_reg64_access)
return;
if (!iio_debugfs_dentry)
diff --git a/include/linux/iio/iio-opaque.h b/include/linux/iio/iio-opaque.h
index b87841a355f8..98330385e08d 100644
--- a/include/linux/iio/iio-opaque.h
+++ b/include/linux/iio/iio-opaque.h
@@ -73,7 +73,7 @@ struct iio_dev_opaque {
#if defined(CONFIG_DEBUG_FS)
struct dentry *debugfs_dentry;
unsigned int cached_reg_addr;
- char read_buf[20];
+ char read_buf[24];
unsigned int read_buf_len;
#endif
};
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 96b05c86c325..86d17ee69e05 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -484,6 +484,7 @@ struct iio_trigger; /* forward declaration */
* @update_scan_mode: function to configure device and scan buffer when
* channels have changed
* @debugfs_reg_access: function to read or write register value of device
+ * @debugfs_reg64_access: function to read or write 64-bit register value of device
* @fwnode_xlate: fwnode based function pointer to obtain channel specifier index.
* @hwfifo_set_watermark: function pointer to set the current hardware
* fifo watermark level; see hwfifo_* entries in
@@ -572,6 +573,9 @@ struct iio_info {
int (*debugfs_reg_access)(struct iio_dev *indio_dev,
unsigned int reg, unsigned int writeval,
unsigned int *readval);
+ int (*debugfs_reg64_access)(struct iio_dev *indio_dev,
+ unsigned int reg, u64 writeval,
+ u64 *readval);
int (*fwnode_xlate)(struct iio_dev *indio_dev,
const struct fwnode_reference_args *iiospec);
int (*hwfifo_set_watermark)(struct iio_dev *indio_dev, unsigned int val);
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v5 02/13] iio: core: support 64-bit register through debugfs
2026-05-17 18:37 ` [PATCH v5 02/13] iio: core: support 64-bit register through debugfs Rodrigo Alencar via B4 Relay
@ 2026-05-18 13:56 ` Rodrigo Alencar
2026-05-20 11:31 ` Jonathan Cameron
0 siblings, 1 reply; 28+ messages in thread
From: Rodrigo Alencar @ 2026-05-18 13:56 UTC (permalink / raw)
To: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
On 26/05/17 06:56PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Silent truncation of 64-bit values when written to a 32-bit register access function.
> --
>
> commit 64785a0c1416e2cf718b558aa7a2cc9ac39b2d81
> Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> iio: core: support 64-bit register through debugfs
>
> This commit introduces a debugfs_reg64_access function pointer to iio_info
> to allow 64-bit register reads and writes through debugfs. The file operation
> callbacks are modified to prefer the 64-bit variant when available.
>
> > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> > index e587aca79b8e7..5c8404efd0a56 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
>
> [ ... ]
>
> > @@ -429,7 +439,7 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
> >
> > buf[ret] = '\0';
> >
> > - ret = sscanf(buf, "%i %i", ®, &val);
> > + ret = sscanf(buf, "%i %lli", ®, &val64);
> >
> > switch (ret) {
> > case 1:
> > @@ -437,8 +447,12 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
> > break;
> > case 2:
> > iio_dev_opaque->cached_reg_addr = reg;
> > - ret = indio_dev->info->debugfs_reg_access(indio_dev, reg,
> > - val, NULL);
> > + if (indio_dev->info->debugfs_reg64_access)
> > + ret = indio_dev->info->debugfs_reg64_access(indio_dev, reg,
> > + val64, NULL);
> > + else
> > + ret = indio_dev->info->debugfs_reg_access(indio_dev, reg,
> > + val64, NULL);
>
> Could this introduce a regression where values are silently truncated if the
> provided input exceeds 32 bits?
>
> Since the input is now unconditionally parsed as a 64-bit integer, falling
> back to debugfs_reg_access (which takes an unsigned int for writeval) will
> implicitly cast val64. If a user provides a value larger than UINT_MAX to a
> driver that only provides the 32-bit callback, it appears the value will be
> truncated rather than rejected with an error like -EINVAL.
Maybe -EINVAL can be returned for that case indeed. For a debug interface I
did not see that as a problem.
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260517-ad9910-iio-driver-v5-0-31599c88314a@analog.com?part=2
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH v5 02/13] iio: core: support 64-bit register through debugfs
2026-05-18 13:56 ` Rodrigo Alencar
@ 2026-05-20 11:31 ` Jonathan Cameron
0 siblings, 0 replies; 28+ messages in thread
From: Jonathan Cameron @ 2026-05-20 11:31 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
On Mon, 18 May 2026 14:56:06 +0100
Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> On 26/05/17 06:56PM, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Medium] Silent truncation of 64-bit values when written to a 32-bit register access function.
> > --
> >
> > commit 64785a0c1416e2cf718b558aa7a2cc9ac39b2d81
> > Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > iio: core: support 64-bit register through debugfs
> >
> > This commit introduces a debugfs_reg64_access function pointer to iio_info
> > to allow 64-bit register reads and writes through debugfs. The file operation
> > callbacks are modified to prefer the 64-bit variant when available.
> >
> > > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> > > index e587aca79b8e7..5c8404efd0a56 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> >
> > [ ... ]
> >
> > > @@ -429,7 +439,7 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
> > >
> > > buf[ret] = '\0';
> > >
> > > - ret = sscanf(buf, "%i %i", ®, &val);
> > > + ret = sscanf(buf, "%i %lli", ®, &val64);
> > >
> > > switch (ret) {
> > > case 1:
> > > @@ -437,8 +447,12 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
> > > break;
> > > case 2:
> > > iio_dev_opaque->cached_reg_addr = reg;
> > > - ret = indio_dev->info->debugfs_reg_access(indio_dev, reg,
> > > - val, NULL);
> > > + if (indio_dev->info->debugfs_reg64_access)
> > > + ret = indio_dev->info->debugfs_reg64_access(indio_dev, reg,
> > > + val64, NULL);
> > > + else
> > > + ret = indio_dev->info->debugfs_reg_access(indio_dev, reg,
> > > + val64, NULL);
> >
> > Could this introduce a regression where values are silently truncated if the
> > provided input exceeds 32 bits?
> >
> > Since the input is now unconditionally parsed as a 64-bit integer, falling
> > back to debugfs_reg_access (which takes an unsigned int for writeval) will
> > implicitly cast val64. If a user provides a value larger than UINT_MAX to a
> > driver that only provides the 32-bit callback, it appears the value will be
> > truncated rather than rejected with an error like -EINVAL.
>
> Maybe -EINVAL can be returned for that case indeed. For a debug interface I
> did not see that as a problem.
Agreed - I don't see this as important either way.
>
> > --
> > Sashiko AI review · https://sashiko.dev/#/patchset/20260517-ad9910-iio-driver-v5-0-31599c88314a@analog.com?part=2
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v5 03/13] iio: core: add hierarchical channel relationships
2026-05-17 18:37 [PATCH v5 00/13] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
2026-05-17 18:37 ` [PATCH v5 01/13] iio: core: validate file offset in iio_debugfs_write_reg() Rodrigo Alencar via B4 Relay
2026-05-17 18:37 ` [PATCH v5 02/13] iio: core: support 64-bit register through debugfs Rodrigo Alencar via B4 Relay
@ 2026-05-17 18:37 ` Rodrigo Alencar via B4 Relay
2026-05-21 13:48 ` Rodrigo Alencar
2026-05-17 18:37 ` [PATCH v5 04/13] Documentation: ABI: testing: add parent entry for iio channels Rodrigo Alencar via B4 Relay
` (9 subsequent siblings)
12 siblings, 1 reply; 28+ messages in thread
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add parent-child relationship between iio channels by creating a parent
pointer field in iio_chan_spec struct and exposing a sysfs attribute that
returns the parent channel label.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
drivers/iio/industrialio-core.c | 38 ++++++++++++++++++++++++++++++++++++++
include/linux/iio/iio.h | 5 +++++
2 files changed, 43 insertions(+)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 5c8404efd0a5..348ac7a59738 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -776,6 +776,14 @@ static ssize_t iio_read_channel_label(struct device *dev,
to_iio_dev_attr(attr)->c, buf);
}
+static ssize_t iio_read_channel_parent(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return do_iio_read_channel_label(dev_to_iio_dev(dev),
+ to_iio_dev_attr(attr)->c->parent, buf);
+}
+
static ssize_t iio_read_channel_info(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -1263,6 +1271,31 @@ static int iio_device_add_channel_label(struct iio_dev *indio_dev,
return 1;
}
+static int iio_device_add_channel_parent(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan)
+{
+ struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
+ int ret;
+
+ if (!chan->parent || (!indio_dev->info->read_label &&
+ !chan->parent->extend_name))
+ return 0;
+
+ ret = __iio_add_chan_devattr("parent",
+ chan,
+ &iio_read_channel_parent,
+ NULL,
+ 0,
+ IIO_SEPARATE,
+ &indio_dev->dev,
+ NULL,
+ &iio_dev_opaque->channel_attr_list);
+ if (ret < 0)
+ return ret;
+
+ return 1;
+}
+
static int iio_device_add_info_mask_type(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
enum iio_shared_by shared_by,
@@ -1401,6 +1434,11 @@ static int iio_device_add_channel_sysfs(struct iio_dev *indio_dev,
return ret;
attrcount += ret;
+ ret = iio_device_add_channel_parent(indio_dev, chan);
+ if (ret < 0)
+ return ret;
+ attrcount += ret;
+
if (chan->ext_info) {
unsigned int i = 0;
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 86d17ee69e05..09a97518e4bd 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -258,6 +258,10 @@ struct iio_scan_type {
* by all channels.
* @info_mask_shared_by_all_available: What availability information is to be
* exported that is shared by all channels.
+ * @parent: Optional pointer to the parent channel spec for
+ * hierarchical channel relationships. When set, a read-only
+ * "parent" sysfs attribute is created containing the
+ * parent channel's label.
* @event_spec: Array of events which should be registered for this
* channel.
* @num_event_specs: Size of the event_spec array.
@@ -306,6 +310,7 @@ struct iio_chan_spec {
unsigned long info_mask_shared_by_dir_available;
unsigned long info_mask_shared_by_all;
unsigned long info_mask_shared_by_all_available;
+ const struct iio_chan_spec *parent;
const struct iio_event_spec *event_spec;
unsigned int num_event_specs;
const struct iio_chan_spec_ext_info *ext_info;
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v5 03/13] iio: core: add hierarchical channel relationships
2026-05-17 18:37 ` [PATCH v5 03/13] iio: core: add hierarchical channel relationships Rodrigo Alencar via B4 Relay
@ 2026-05-21 13:48 ` Rodrigo Alencar
2026-05-22 17:45 ` Jonathan Cameron
0 siblings, 1 reply; 28+ messages in thread
From: Rodrigo Alencar @ 2026-05-21 13:48 UTC (permalink / raw)
To: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
On 26/05/18 03:26PM, Rodrigo Alencar wrote:
> On 26/05/17 06:56PM, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Medium] Exposing the hierarchical relationship via channel labels creates an ambiguous UAPI for userspace.
> > --
> >
> > commit 64c6f961f1d7645c58f732e4bd4c11200b999e93
> > Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > iio: core: add hierarchical channel relationships
> >
> > This commit introduces a parent-child relationship between IIO channels.
> > It adds a parent pointer to the iio_chan_spec struct and exposes this
> > relationship to userspace through a new "parent" sysfs attribute that
> > returns the parent channel's label.
> >
> > > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> > > index 5c8404efd0a56..348ac7a597385 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> >
> > [ ... ]
> >
> > > @@ -1263,6 +1271,31 @@ static int iio_device_add_channel_label(struct iio_dev *indio_dev,
> > > return 1;
> > > }
> > >
> > > +static int iio_device_add_channel_parent(struct iio_dev *indio_dev,
> > > + struct iio_chan_spec const *chan)
> > > +{
> > > + struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
> > > + int ret;
> > > +
> > > + if (!chan->parent || (!indio_dev->info->read_label &&
> > > + !chan->parent->extend_name))
> > > + return 0;
> >
> > Is relying on channel labels robust enough for programmatic parent resolution?
> >
> > IIO channel labels are optional, human-readable descriptors and are not
> > guaranteed by the core to be unique. If multiple channels within a device
> > share the same label, how can userspace definitively resolve which specific
> > channel is the parent?
> >
> > Also, if a driver establishes a hierarchy where chan->parent is set, but the
> > parent channel lacks a label, this attribute is silently omitted, hiding the
> > relationship entirely.
> >
> > Would it be more reliable to expose a definitive, unique identifier (such as
> > the parent channel's sysfs prefix or index) rather than relying on an optional
> > descriptive string?
>
> A bit impressive that sashiko can comment on that architecture level.
>
> Those are all good points. I suppose I went for this because otherwise it would
> require refactoring core code to get the needed parts from __iio_device_attr_init()
> that gets you the channel name without the attribute part.
>
> Maybe we should have a function that outputs a channel name into a buffer based on
> __iio_device_attr_init() behavior, and that could be reused.
This is the function with behavior extracted from __iio_device_attr_init():
static int __iio_chan_prefix_emit(const struct iio_chan_spec *chan,
enum iio_shared_by shared_by,
char *buf, size_t len)
{
const char *dir = iio_direction[chan->output];
const char *type = iio_chan_type_name_spec[chan->type];
int n = 0;
switch (shared_by) {
case IIO_SHARED_BY_ALL:
break;
case IIO_SHARED_BY_DIR:
n = scnprintf(buf, len, "%s", dir);
break;
case IIO_SHARED_BY_TYPE:
n = scnprintf(buf, len, "%s_%s", dir, type);
if (chan->differential)
n += scnprintf(buf + n, len - n, "-%s", type);
break;
case IIO_SEPARATE:
if (chan->indexed) {
n = scnprintf(buf, len, "%s_%s%d", dir, type,
chan->channel);
if (chan->differential)
n += scnprintf(buf + n, len - n, "-%s%d", type,
chan->channel2);
} else {
if (chan->differential) {
WARN(1, "Differential channels must be indexed\n");
return -EINVAL;
}
n = scnprintf(buf, len, "%s_%s", dir, type);
}
if (chan->modified) {
if (chan->differential) {
WARN(1, "Differential channels can not have modifier\n");
return -EINVAL;
}
n += scnprintf(buf + n, len - n, "_%s",
iio_modifier_names[chan->channel2]);
}
if (chan->extend_name)
n += scnprintf(buf + n, len - n, "_%s", chan->extend_name);
break;
}
return n;
}
I think it is clear and reusable.
> > > +
> > > + ret = __iio_add_chan_devattr("parent",
> > > + chan,
> > > + &iio_read_channel_parent,
> > > + NULL,
> > > + 0,
> > > + IIO_SEPARATE,
> > > + &indio_dev->dev,
> > > + NULL,
> > > + &iio_dev_opaque->channel_attr_list);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + return 1;
> > > +}
> >
> > --
> > Sashiko AI review · https://sashiko.dev/#/patchset/20260517-ad9910-iio-driver-v5-0-31599c88314a@analog.com?part=3
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH v5 03/13] iio: core: add hierarchical channel relationships
2026-05-21 13:48 ` Rodrigo Alencar
@ 2026-05-22 17:45 ` Jonathan Cameron
0 siblings, 0 replies; 28+ messages in thread
From: Jonathan Cameron @ 2026-05-22 17:45 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
On Thu, 21 May 2026 14:48:30 +0100
Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> On 26/05/18 03:26PM, Rodrigo Alencar wrote:
> > On 26/05/17 06:56PM, sashiko-bot@kernel.org wrote:
> > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > > - [Medium] Exposing the hierarchical relationship via channel labels creates an ambiguous UAPI for userspace.
> > > --
> > >
> > > commit 64c6f961f1d7645c58f732e4bd4c11200b999e93
> > > Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > >
> > > iio: core: add hierarchical channel relationships
> > >
> > > This commit introduces a parent-child relationship between IIO channels.
> > > It adds a parent pointer to the iio_chan_spec struct and exposes this
> > > relationship to userspace through a new "parent" sysfs attribute that
> > > returns the parent channel's label.
> > >
> > > > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> > > > index 5c8404efd0a56..348ac7a597385 100644
> > > > --- a/drivers/iio/industrialio-core.c
> > > > +++ b/drivers/iio/industrialio-core.c
> > >
> > > [ ... ]
> > >
> > > > @@ -1263,6 +1271,31 @@ static int iio_device_add_channel_label(struct iio_dev *indio_dev,
> > > > return 1;
> > > > }
> > > >
> > > > +static int iio_device_add_channel_parent(struct iio_dev *indio_dev,
> > > > + struct iio_chan_spec const *chan)
> > > > +{
> > > > + struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
> > > > + int ret;
> > > > +
> > > > + if (!chan->parent || (!indio_dev->info->read_label &&
> > > > + !chan->parent->extend_name))
> > > > + return 0;
> > >
> > > Is relying on channel labels robust enough for programmatic parent resolution?
> > >
> > > IIO channel labels are optional, human-readable descriptors and are not
> > > guaranteed by the core to be unique. If multiple channels within a device
> > > share the same label, how can userspace definitively resolve which specific
> > > channel is the parent?
> > >
> > > Also, if a driver establishes a hierarchy where chan->parent is set, but the
> > > parent channel lacks a label, this attribute is silently omitted, hiding the
> > > relationship entirely.
> > >
> > > Would it be more reliable to expose a definitive, unique identifier (such as
> > > the parent channel's sysfs prefix or index) rather than relying on an optional
> > > descriptive string?
> >
> > A bit impressive that sashiko can comment on that architecture level.
> >
> > Those are all good points. I suppose I went for this because otherwise it would
> > require refactoring core code to get the needed parts from __iio_device_attr_init()
> > that gets you the channel name without the attribute part.
> >
> > Maybe we should have a function that outputs a channel name into a buffer based on
> > __iio_device_attr_init() behavior, and that could be reused.
>
> This is the function with behavior extracted from __iio_device_attr_init():
>
> static int __iio_chan_prefix_emit(const struct iio_chan_spec *chan,
> enum iio_shared_by shared_by,
> char *buf, size_t len)
> {
> const char *dir = iio_direction[chan->output];
> const char *type = iio_chan_type_name_spec[chan->type];
> int n = 0;
>
> switch (shared_by) {
> case IIO_SHARED_BY_ALL:
> break;
> case IIO_SHARED_BY_DIR:
> n = scnprintf(buf, len, "%s", dir);
> break;
> case IIO_SHARED_BY_TYPE:
> n = scnprintf(buf, len, "%s_%s", dir, type);
> if (chan->differential)
> n += scnprintf(buf + n, len - n, "-%s", type);
> break;
> case IIO_SEPARATE:
> if (chan->indexed) {
> n = scnprintf(buf, len, "%s_%s%d", dir, type,
> chan->channel);
> if (chan->differential)
> n += scnprintf(buf + n, len - n, "-%s%d", type,
> chan->channel2);
> } else {
> if (chan->differential) {
> WARN(1, "Differential channels must be indexed\n");
> return -EINVAL;
> }
> n = scnprintf(buf, len, "%s_%s", dir, type);
> }
>
> if (chan->modified) {
> if (chan->differential) {
> WARN(1, "Differential channels can not have modifier\n");
> return -EINVAL;
> }
> n += scnprintf(buf + n, len - n, "_%s",
> iio_modifier_names[chan->channel2]);
> }
>
> if (chan->extend_name)
> n += scnprintf(buf + n, len - n, "_%s", chan->extend_name);
> break;
> }
>
> return n;
> }
>
> I think it is clear and reusable.
You only what the SEPARATE case but given the rest is much simpler anyway probably fine
to just use this function.
Jonathan
>
> > > > +
> > > > + ret = __iio_add_chan_devattr("parent",
> > > > + chan,
> > > > + &iio_read_channel_parent,
> > > > + NULL,
> > > > + 0,
> > > > + IIO_SEPARATE,
> > > > + &indio_dev->dev,
> > > > + NULL,
> > > > + &iio_dev_opaque->channel_attr_list);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + return 1;
> > > > +}
> > >
> > > --
> > > Sashiko AI review · https://sashiko.dev/#/patchset/20260517-ad9910-iio-driver-v5-0-31599c88314a@analog.com?part=3
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v5 04/13] Documentation: ABI: testing: add parent entry for iio channels
2026-05-17 18:37 [PATCH v5 00/13] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
` (2 preceding siblings ...)
2026-05-17 18:37 ` [PATCH v5 03/13] iio: core: add hierarchical channel relationships Rodrigo Alencar via B4 Relay
@ 2026-05-17 18:37 ` Rodrigo Alencar via B4 Relay
2026-05-22 17:47 ` Jonathan Cameron
2026-05-17 18:37 ` [PATCH v5 05/13] dt-bindings: iio: frequency: add ad9910 Rodrigo Alencar via B4 Relay
` (8 subsequent siblings)
12 siblings, 1 reply; 28+ messages in thread
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add documentation for a read-only sysfs attribute that allows to expose
parent-child relationships between IIO channels.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
Documentation/ABI/testing/sysfs-bus-iio | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 925a33fd309a..399944974e34 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -2118,6 +2118,19 @@ Description:
specific attributes. This is useful for userspace to be able to
better identify an individual channel.
+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_parent
+What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_parent
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltageY_parent
+What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_parent
+KernelVersion: 7.1
+Contact: linux-iio@vger.kernel.org
+Description:
+ Read-only attribute containing the label of the parent channel
+ for hierarchical channel relationships. Only present on channels
+ that have a parent channel with a valid label. This is useful for
+ userspace to organize channels in tree-like structures that reflects
+ the physical or logical relationships between them.
+
What: /sys/bus/iio/devices/iio:deviceX/in_phaseY_raw
KernelVersion: 4.18
Contact: linux-iio@vger.kernel.org
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v5 04/13] Documentation: ABI: testing: add parent entry for iio channels
2026-05-17 18:37 ` [PATCH v5 04/13] Documentation: ABI: testing: add parent entry for iio channels Rodrigo Alencar via B4 Relay
@ 2026-05-22 17:47 ` Jonathan Cameron
0 siblings, 0 replies; 28+ messages in thread
From: Jonathan Cameron @ 2026-05-22 17:47 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
On Sun, 17 May 2026 19:37:48 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Add documentation for a read-only sysfs attribute that allows to expose
> parent-child relationships between IIO channels.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> index 925a33fd309a..399944974e34 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -2118,6 +2118,19 @@ Description:
> specific attributes. This is useful for userspace to be able to
> better identify an individual channel.
>
> +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_parent
> +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_parent
> +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltageY_parent
> +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_parent
> +KernelVersion: 7.1
> +Contact: linux-iio@vger.kernel.org
> +Description:
> + Read-only attribute containing the label of the parent channel
> + for hierarchical channel relationships. Only present on channels
> + that have a parent channel with a valid label. This is useful for
> + userspace to organize channels in tree-like structures that reflects
> + the physical or logical relationships between them.
Perhaps an example would be useful?
Otherwise it seems reasonable. One vague concern I have is maybe we end
up with a channel that actually has no other existence than as a parent.
Image two signals mixed into one. If that mixed signal has nothing to control
it wouldn't normally show up in the ABI.
I guess we can give it a label though to ensure there is something there
(even when not using labels for this!).
J
> +
> What: /sys/bus/iio/devices/iio:deviceX/in_phaseY_raw
> KernelVersion: 4.18
> Contact: linux-iio@vger.kernel.org
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v5 05/13] dt-bindings: iio: frequency: add ad9910
2026-05-17 18:37 [PATCH v5 00/13] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
` (3 preceding siblings ...)
2026-05-17 18:37 ` [PATCH v5 04/13] Documentation: ABI: testing: add parent entry for iio channels Rodrigo Alencar via B4 Relay
@ 2026-05-17 18:37 ` Rodrigo Alencar via B4 Relay
2026-05-18 7:52 ` Krzysztof Kozlowski
2026-05-17 18:37 ` [PATCH v5 06/13] iio: frequency: ad9910: initial driver implementation Rodrigo Alencar via B4 Relay
` (7 subsequent siblings)
12 siblings, 1 reply; 28+ messages in thread
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
DT-bindings for AD9910, a 1 GSPS DDS with 14-bit DAC. It includes
configurations for clocks, DAC current, reset and basic GPIO control.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
.../bindings/iio/frequency/adi,ad9910.yaml | 200 +++++++++++++++++++++
MAINTAINERS | 7 +
2 files changed, 207 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml
new file mode 100644
index 000000000000..5ab0db62dbf1
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml
@@ -0,0 +1,200 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/frequency/adi,ad9910.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD9910 Direct Digital Synthesizer
+
+maintainers:
+ - Rodrigo Alencar <rodrigo.alencar@analog.com>
+
+description:
+ The AD9910 is a 1 GSPS direct digital synthesizer (DDS) with an integrated
+ 14-bit DAC. It features single tone mode with 8 configurable profiles,
+ a digital ramp generator, RAM control, OSK, and a parallel data port for
+ high-speed streaming.
+
+ https://www.analog.com/en/products/ad9910.html
+
+properties:
+ compatible:
+ const: adi,ad9910
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 70000000
+
+ clocks:
+ minItems: 1
+ items:
+ - description: Reference clock (REF_CLK).
+ - description: Optional synchronization clock (SYNC_IN).
+
+ clock-names:
+ oneOf:
+ - items:
+ - const: ref_clk
+ - items:
+ - const: ref_clk
+ - const: sync_in
+
+ '#clock-cells':
+ const: 1
+
+ clock-output-names:
+ minItems: 1
+ maxItems: 3
+ items:
+ enum: [ sync_clk, pdclk, sync_out ]
+
+ interrupts:
+ minItems: 1
+ items:
+ - description:
+ Signal that indicates that Digital Ramp Generator has reached a limit.
+ - description:
+ Signal that indicates the end of a RAM Sweep.
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum: [ drover, ram_swp_ovr ]
+
+ dvdd-io33-supply:
+ description: 3.3V Digital I/O supply.
+
+ avdd33-supply:
+ description: 3.3V Analog DAC supply.
+
+ dvdd18-supply:
+ description: 1.8V Digital Core supply.
+
+ avdd18-supply:
+ description: 1.8V Analog Core supply.
+
+ reset-gpios:
+ description:
+ GPIOs controlling the Main Device reset.
+
+ io-reset-gpios:
+ maxItems: 1
+ description:
+ GPIO controlling the I/O_RESET pin.
+
+ powerdown-gpios:
+ maxItems: 1
+ description:
+ GPIO controlling the EXT_PWR_DWN pin.
+
+ update-gpios:
+ maxItems: 1
+ description:
+ GPIO controlling the I/O_UPDATE pin.
+
+ profile-gpios:
+ minItems: 3
+ maxItems: 3
+ description:
+ GPIOs controlling the PROFILE[2:0] pins for profile selection.
+
+ sync-err-gpios:
+ maxItems: 1
+ description:
+ GPIO used to read SYNC_SMP_ERR pin status.
+
+ lock-detect-gpios:
+ maxItems: 1
+ description:
+ GPIO used to read PLL_LOCK pin status.
+
+ adi,pll-enable:
+ type: boolean
+ description:
+ Indicates that a loop filter is connected and the internal PLL is enabled.
+ Often used when the reference clock is provided by a crystal or by a
+ single-ended on-board oscillator.
+
+ adi,charge-pump-current-microamp:
+ minimum: 212
+ maximum: 387
+ default: 212
+ description:
+ PLL charge pump current in microamps. Only applicable when the internal
+ PLL is enabled. The value is rounded to the nearest supported step. This
+ value depends mostly on the loop filter design.
+
+ adi,refclk-out-drive-strength:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [ disabled, low, medium, high ]
+ default: disabled
+ description:
+ Reference clock output (DRV0) drive strength. Only applicable when
+ the internal PLL is enabled.
+
+ output-range-microamp:
+ description: DAC full-scale output current in microamps.
+ items:
+ - const: 0
+ - minimum: 8640
+ maximum: 31590
+ default: 20070
+
+dependencies:
+ adi,charge-pump-current-microamp: [ 'adi,pll-enable' ]
+ adi,refclk-out-drive-strength: [ 'adi,pll-enable' ]
+ lock-detect-gpios: [ 'adi,pll-enable' ]
+ interrupts: [ interrupt-names ]
+ clocks: [ clock-names ]
+ '#clock-cells': [ clock-output-names ]
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - dvdd-io33-supply
+ - avdd33-supply
+ - dvdd18-supply
+ - avdd18-supply
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dds@0 {
+ compatible = "adi,ad9910";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ clocks = <&ad9910_refclk>;
+ clock-names = "ref_clk";
+
+ dvdd-io33-supply = <&vdd_io33>;
+ avdd33-supply = <&vdd_a33>;
+ dvdd18-supply = <&vdd_d18>;
+ avdd18-supply = <&vdd_a18>;
+
+ reset-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
+ io-reset-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+ powerdown-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
+ update-gpios = <&gpio 3 GPIO_ACTIVE_HIGH>;
+ profile-gpios = <&gpio 4 GPIO_ACTIVE_HIGH>,
+ <&gpio 5 GPIO_ACTIVE_HIGH>,
+ <&gpio 6 GPIO_ACTIVE_HIGH>;
+
+ adi,pll-enable;
+ adi,charge-pump-current-microamp = <387>;
+ adi,refclk-out-drive-strength = "disabled";
+ output-range-microamp = <0 20070>;
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 3115538ce829..ea70b8449eb4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1638,6 +1638,13 @@ W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/iio/dac/adi,ad9739a.yaml
F: drivers/iio/dac/ad9739a.c
+ANALOG DEVICES INC AD9910 DRIVER
+M: Rodrigo Alencar <rodrigo.alencar@analog.com>
+L: linux-iio@vger.kernel.org
+S: Supported
+W: https://ez.analog.com/linux-software-drivers
+F: Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml
+
ANALOG DEVICES INC MAX22007 DRIVER
M: Janani Sunil <janani.sunil@analog.com>
L: linux-iio@vger.kernel.org
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v5 05/13] dt-bindings: iio: frequency: add ad9910
2026-05-17 18:37 ` [PATCH v5 05/13] dt-bindings: iio: frequency: add ad9910 Rodrigo Alencar via B4 Relay
@ 2026-05-18 7:52 ` Krzysztof Kozlowski
2026-05-18 10:03 ` Rodrigo Alencar
0 siblings, 1 reply; 28+ messages in thread
From: Krzysztof Kozlowski @ 2026-05-18 7:52 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening,
Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
On Sun, May 17, 2026 at 07:37:49PM +0100, Rodrigo Alencar wrote:
> +maintainers:
> + - Rodrigo Alencar <rodrigo.alencar@analog.com>
> +
> +description:
> + The AD9910 is a 1 GSPS direct digital synthesizer (DDS) with an integrated
> + 14-bit DAC. It features single tone mode with 8 configurable profiles,
> + a digital ramp generator, RAM control, OSK, and a parallel data port for
> + high-speed streaming.
> +
> + https://www.analog.com/en/products/ad9910.html
> +
> +properties:
> + compatible:
> + const: adi,ad9910
> +
> + reg:
> + maxItems: 1
> +
> + spi-max-frequency:
> + maximum: 70000000
> +
> + clocks:
> + minItems: 1
> + items:
> + - description: Reference clock (REF_CLK).
> + - description: Optional synchronization clock (SYNC_IN).
> +
> + clock-names:
> + oneOf:
> + - items:
> + - const: ref_clk
> + - items:
> + - const: ref_clk
> + - const: sync_in
So that's just items with two items and minItems: 1. Like you have in
"clocks:".
You got this comment already at v2.
> +
> + '#clock-cells':
> + const: 1
> +
> + clock-output-names:
> + minItems: 1
> + maxItems: 3
> + items:
> + enum: [ sync_clk, pdclk, sync_out ]
Why are the names fixed? And why is the order random?
> +
> + interrupts:
> + minItems: 1
> + items:
> + - description:
> + Signal that indicates that Digital Ramp Generator has reached a limit.
> + - description:
> + Signal that indicates the end of a RAM Sweep.
> +
> + interrupt-names:
> + minItems: 1
> + maxItems: 2
> + items:
> + enum: [ drover, ram_swp_ovr ]
Your "interrupts:" do not allow flexibility. Are you sure interrupts are
optional in the hardware?
> +
> + dvdd-io33-supply:
> + description: 3.3V Digital I/O supply.
> +
> + avdd33-supply:
> + description: 3.3V Analog DAC supply.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 05/13] dt-bindings: iio: frequency: add ad9910
2026-05-18 7:52 ` Krzysztof Kozlowski
@ 2026-05-18 10:03 ` Rodrigo Alencar
0 siblings, 0 replies; 28+ messages in thread
From: Rodrigo Alencar @ 2026-05-18 10:03 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rodrigo Alencar
Cc: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening,
Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
On 26/05/18 09:52AM, Krzysztof Kozlowski wrote:
> On Sun, May 17, 2026 at 07:37:49PM +0100, Rodrigo Alencar wrote:
> > +maintainers:
> > + - Rodrigo Alencar <rodrigo.alencar@analog.com>
> > +
> > +description:
> > + The AD9910 is a 1 GSPS direct digital synthesizer (DDS) with an integrated
> > + 14-bit DAC. It features single tone mode with 8 configurable profiles,
> > + a digital ramp generator, RAM control, OSK, and a parallel data port for
> > + high-speed streaming.
> > +
> > + https://www.analog.com/en/products/ad9910.html
> > +
> > +properties:
> > + compatible:
> > + const: adi,ad9910
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + spi-max-frequency:
> > + maximum: 70000000
> > +
> > + clocks:
> > + minItems: 1
> > + items:
> > + - description: Reference clock (REF_CLK).
> > + - description: Optional synchronization clock (SYNC_IN).
> > +
> > + clock-names:
> > + oneOf:
> > + - items:
> > + - const: ref_clk
> > + - items:
> > + - const: ref_clk
> > + - const: sync_in
>
> So that's just items with two items and minItems: 1. Like you have in
> "clocks:".
>
> You got this comment already at v2.
You're right! will adjust. For some reason I thought I had problems with
the dt-binding check without this.
>
> > +
> > + '#clock-cells':
> > + const: 1
> > +
> > + clock-output-names:
> > + minItems: 1
> > + maxItems: 3
> > + items:
> > + enum: [ sync_clk, pdclk, sync_out ]
>
> Why are the names fixed? And why is the order random?
All of those would be optional. Having it in a specific order we would need
to register all the clocks even if only one (or none) is used?
> > +
> > + interrupts:
> > + minItems: 1
> > + items:
> > + - description:
> > + Signal that indicates that Digital Ramp Generator has reached a limit.
> > + - description:
> > + Signal that indicates the end of a RAM Sweep.
> > +
> > + interrupt-names:
> > + minItems: 1
> > + maxItems: 2
> > + items:
> > + enum: [ drover, ram_swp_ovr ]
>
> Your "interrupts:" do not allow flexibility. Are you sure interrupts are
> optional in the hardware?
Good point, They are optional. Should I drop the items and descriptions in "interrupts"?
> > +
> > + dvdd-io33-supply:
> > + description: 3.3V Digital I/O supply.
> > +
> > + avdd33-supply:
> > + description: 3.3V Analog DAC supply.
>
> Best regards,
> Krzysztof
>
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v5 06/13] iio: frequency: ad9910: initial driver implementation
2026-05-17 18:37 [PATCH v5 00/13] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
` (4 preceding siblings ...)
2026-05-17 18:37 ` [PATCH v5 05/13] dt-bindings: iio: frequency: add ad9910 Rodrigo Alencar via B4 Relay
@ 2026-05-17 18:37 ` Rodrigo Alencar via B4 Relay
2026-05-18 11:45 ` Rodrigo Alencar
2026-05-22 18:03 ` Jonathan Cameron
2026-05-17 18:37 ` [PATCH v5 07/13] iio: frequency: ad9910: add basic parallel port support Rodrigo Alencar via B4 Relay
` (6 subsequent siblings)
12 siblings, 2 replies; 28+ messages in thread
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add the core AD9910 DDS driver infrastructure with single tone mode
support. This includes SPI register access, profile management via GPIO
pins, PLL/DAC configuration from firmware properties, and single tone
frequency/phase/amplitude control through IIO attributes.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
MAINTAINERS | 1 +
drivers/iio/frequency/Kconfig | 18 +
drivers/iio/frequency/Makefile | 1 +
drivers/iio/frequency/ad9910.c | 1060 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 1080 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea70b8449eb4..b2b7f54f5a24 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1644,6 +1644,7 @@ L: linux-iio@vger.kernel.org
S: Supported
W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml
+F: drivers/iio/frequency/ad9910.c
ANALOG DEVICES INC MAX22007 DRIVER
M: Janani Sunil <janani.sunil@analog.com>
diff --git a/drivers/iio/frequency/Kconfig b/drivers/iio/frequency/Kconfig
index 583cbdf4e8cd..180e74f62d11 100644
--- a/drivers/iio/frequency/Kconfig
+++ b/drivers/iio/frequency/Kconfig
@@ -23,6 +23,24 @@ config AD9523
endmenu
+menu "Direct Digital Synthesis"
+
+config AD9910
+ tristate "Analog Devices AD9910 Direct Digital Synthesizer"
+ depends on SPI
+ depends on GPIOLIB
+ help
+ Say yes here to build support for Analog Devices AD9910
+ 1 GSPS, 14-Bit DDS with integrated DAC.
+
+ Supports single tone mode with 8 configurable profiles
+ and digital ramp generation.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad9910.
+
+endmenu
+
#
# Phase-Locked Loop (PLL) frequency synthesizers
#
diff --git a/drivers/iio/frequency/Makefile b/drivers/iio/frequency/Makefile
index 70d0e0b70e80..39271dd209ca 100644
--- a/drivers/iio/frequency/Makefile
+++ b/drivers/iio/frequency/Makefile
@@ -5,6 +5,7 @@
# When adding new entries keep the list in alphabetical order
obj-$(CONFIG_AD9523) += ad9523.o
+obj-$(CONFIG_AD9910) += ad9910.o
obj-$(CONFIG_ADF4350) += adf4350.o
obj-$(CONFIG_ADF4371) += adf4371.o
obj-$(CONFIG_ADF4377) += adf4377.o
diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
new file mode 100644
index 000000000000..c7b1e474c92d
--- /dev/null
+++ b/drivers/iio/frequency/ad9910.c
@@ -0,0 +1,1060 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * AD9910 SPI DDS (Direct Digital Synthesizer) driver
+ *
+ * Copyright 2026 Analog Devices Inc.
+ */
+
+#include <linux/array_size.h>
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device/devres.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/log2.h>
+#include <linux/math64.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/property.h>
+#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
+#include <linux/spi/spi.h>
+#include <linux/sysfs.h>
+#include <linux/types.h>
+#include <linux/units.h>
+#include <linux/unaligned.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+/* Register addresses */
+#define AD9910_REG_CFR1 0x00
+#define AD9910_REG_CFR2 0x01
+#define AD9910_REG_CFR3 0x02
+#define AD9910_REG_AUX_DAC 0x03
+#define AD9910_REG_IO_UPDATE_RATE 0x04
+#define AD9910_REG_FTW 0x07
+#define AD9910_REG_POW 0x08
+#define AD9910_REG_ASF 0x09
+#define AD9910_REG_MULTICHIP_SYNC 0x0A
+#define AD9910_REG_DRG_LIMIT 0x0B
+#define AD9910_REG_DRG_STEP 0x0C
+#define AD9910_REG_DRG_RATE 0x0D
+#define AD9910_REG_PROFILE0 0x0E
+#define AD9910_REG_PROFILE1 0x0F
+#define AD9910_REG_PROFILE2 0x10
+#define AD9910_REG_PROFILE3 0x11
+#define AD9910_REG_PROFILE4 0x12
+#define AD9910_REG_PROFILE5 0x13
+#define AD9910_REG_PROFILE6 0x14
+#define AD9910_REG_PROFILE7 0x15
+#define AD9910_REG_RAM 0x16
+
+#define AD9910_REG_NUM_CACHED 0x16
+#define AD9910_REG_PROFILE(x) (AD9910_REG_PROFILE0 + (x))
+
+/* CFR1 bit definitions */
+#define AD9910_CFR1_RAM_ENABLE_MSK BIT(31)
+#define AD9910_CFR1_RAM_PLAYBACK_DEST_MSK GENMASK(30, 29)
+#define AD9910_CFR1_OSK_MANUAL_EXT_CTL_MSK BIT(23)
+#define AD9910_CFR1_INV_SINC_EN_MSK BIT(22)
+#define AD9910_CFR1_INT_PROFILE_CTL_MSK GENMASK(20, 17)
+#define AD9910_CFR1_SELECT_SINE_MSK BIT(16)
+#define AD9910_CFR1_LOAD_LRR_IO_UPDATE_MSK BIT(15)
+#define AD9910_CFR1_AUTOCLR_DIG_RAMP_ACCUM_MSK BIT(14)
+#define AD9910_CFR1_AUTOCLR_PHASE_ACCUM_MSK BIT(13)
+#define AD9910_CFR1_CLEAR_DIG_RAMP_ACCUM_MSK BIT(12)
+#define AD9910_CFR1_CLEAR_PHASE_ACCUM_MSK BIT(11)
+#define AD9910_CFR1_LOAD_ARR_IO_UPDATE_MSK BIT(10)
+#define AD9910_CFR1_OSK_ENABLE_MSK BIT(9)
+#define AD9910_CFR1_SELECT_AUTO_OSK_MSK BIT(8)
+#define AD9910_CFR1_DIGITAL_POWER_DOWN_MSK BIT(7)
+#define AD9910_CFR1_DAC_POWER_DOWN_MSK BIT(6)
+#define AD9910_CFR1_REFCLK_INPUT_POWER_DOWN_MSK BIT(5)
+#define AD9910_CFR1_AUX_DAC_POWER_DOWN_MSK BIT(4)
+#define AD9910_CFR1_SOFT_POWER_DOWN_MSK GENMASK(7, 4)
+#define AD9910_CFR1_EXT_POWER_DOWN_CTL_MSK BIT(3)
+#define AD9910_CFR1_SDIO_INPUT_ONLY_MSK BIT(1)
+#define AD9910_CFR1_LSB_FIRST_MSK BIT(0)
+
+/* CFR2 bit definitions */
+#define AD9910_CFR2_AMP_SCALE_SINGLE_TONE_MSK BIT(24)
+#define AD9910_CFR2_INTERNAL_IO_UPDATE_MSK BIT(23)
+#define AD9910_CFR2_SYNC_CLK_EN_MSK BIT(22)
+#define AD9910_CFR2_DRG_DEST_MSK GENMASK(21, 20)
+#define AD9910_CFR2_DRG_ENABLE_MSK BIT(19)
+#define AD9910_CFR2_DRG_NO_DWELL_HIGH_MSK BIT(18)
+#define AD9910_CFR2_DRG_NO_DWELL_LOW_MSK BIT(17)
+#define AD9910_CFR2_DRG_NO_DWELL_MSK GENMASK(18, 17)
+#define AD9910_CFR2_READ_EFFECTIVE_FTW_MSK BIT(16)
+#define AD9910_CFR2_IO_UPDATE_RATE_CTL_MSK GENMASK(15, 14)
+#define AD9910_CFR2_PDCLK_ENABLE_MSK BIT(11)
+#define AD9910_CFR2_PDCLK_INVERT_MSK BIT(10)
+#define AD9910_CFR2_TXENABLE_INVERT_MSK BIT(9)
+#define AD9910_CFR2_MATCHED_LATENCY_EN_MSK BIT(7)
+#define AD9910_CFR2_DATA_ASM_HOLD_LAST_MSK BIT(6)
+#define AD9910_CFR2_SYNC_TIMING_VAL_DISABLE_MSK BIT(5)
+#define AD9910_CFR2_PARALLEL_DATA_PORT_EN_MSK BIT(4)
+#define AD9910_CFR2_FM_GAIN_MSK GENMASK(3, 0)
+
+/* CFR3 bit definitions */
+#define AD9910_CFR3_OPEN_MSK 0x08070000
+#define AD9910_CFR3_DRV0_MSK GENMASK(29, 28)
+#define AD9910_CFR3_VCO_SEL_MSK GENMASK(26, 24)
+#define AD9910_CFR3_ICP_MSK GENMASK(21, 19)
+#define AD9910_CFR3_REFCLK_DIV_BYPASS_MSK BIT(15)
+#define AD9910_CFR3_REFCLK_DIV_RESETB_MSK BIT(14)
+#define AD9910_CFR3_PFD_RESET_MSK BIT(10)
+#define AD9910_CFR3_PLL_EN_MSK BIT(8)
+#define AD9910_CFR3_N_MSK GENMASK(7, 1)
+
+/* Auxiliary DAC Control Register Bits */
+#define AD9910_AUX_DAC_FSC_MSK GENMASK(7, 0)
+
+/* ASF Register Bits */
+#define AD9910_ASF_RAMP_RATE_MSK GENMASK(31, 16)
+#define AD9910_ASF_SCALE_FACTOR_MSK GENMASK(15, 2)
+#define AD9910_ASF_STEP_SIZE_MSK GENMASK(1, 0)
+
+/* Multichip Sync Register Bits */
+#define AD9910_MC_SYNC_VALIDATION_DELAY_MSK GENMASK(31, 28)
+#define AD9910_MC_SYNC_RECEIVER_ENABLE_MSK BIT(27)
+#define AD9910_MC_SYNC_GENERATOR_ENABLE_MSK BIT(26)
+#define AD9910_MC_SYNC_GENERATOR_POLARITY_MSK BIT(25)
+#define AD9910_MC_SYNC_STATE_PRESET_MSK GENMASK(23, 18)
+#define AD9910_MC_SYNC_OUTPUT_DELAY_MSK GENMASK(15, 11)
+#define AD9910_MC_SYNC_INPUT_DELAY_MSK GENMASK(7, 3)
+
+/* Profile Register Format (Single Tone Mode) */
+#define AD9910_PROFILE_ST_ASF_MSK GENMASK_ULL(61, 48)
+#define AD9910_PROFILE_ST_POW_MSK GENMASK_ULL(47, 32)
+#define AD9910_PROFILE_ST_FTW_MSK GENMASK_ULL(31, 0)
+
+/* Device constants */
+#define AD9910_PI_NANORAD 3141592653UL
+
+#define AD9910_MAX_SYSCLK_HZ (1000 * HZ_PER_MHZ)
+#define AD9910_MAX_PHASE_MICRORAD (AD9910_PI_NANORAD / 500)
+
+#define AD9910_ASF_MAX GENMASK(13, 0)
+#define AD9910_POW_MAX GENMASK(15, 0)
+#define AD9910_NUM_PROFILES 8
+
+/* PLL constants */
+#define AD9910_PLL_MIN_N 12
+#define AD9910_PLL_MAX_N 127
+
+#define AD9910_PLL_IN_MIN_FREQ_HZ (3200 * HZ_PER_KHZ)
+#define AD9910_PLL_IN_MAX_FREQ_HZ (60 * HZ_PER_MHZ)
+
+#define AD9910_PLL_OUT_MIN_FREQ_HZ (420 * HZ_PER_MHZ)
+#define AD9910_PLL_OUT_MAX_FREQ_HZ AD9910_MAX_SYSCLK_HZ
+
+#define AD9910_VCO0_RANGE_AUTO_MAX_HZ (457 * HZ_PER_MHZ)
+#define AD9910_VCO1_RANGE_AUTO_MAX_HZ (530 * HZ_PER_MHZ)
+#define AD9910_VCO2_RANGE_AUTO_MAX_HZ (632 * HZ_PER_MHZ)
+#define AD9910_VCO3_RANGE_AUTO_MAX_HZ (775 * HZ_PER_MHZ)
+#define AD9910_VCO4_RANGE_AUTO_MAX_HZ (897 * HZ_PER_MHZ)
+#define AD9910_VCO_RANGE_NUM 6
+
+#define AD9910_REFCLK_OUT_DRV_DISABLED 0
+
+#define AD9910_ICP_MIN_uA 212
+#define AD9910_ICP_MAX_uA 387
+#define AD9910_ICP_STEP_uA 25
+
+#define AD9910_DAC_IOUT_MAX_uA 31590
+#define AD9910_DAC_IOUT_DEFAULT_uA 20070
+#define AD9910_DAC_IOUT_MIN_uA 8640
+
+#define AD9910_REFDIV2_MIN_FREQ_HZ (120 * HZ_PER_MHZ)
+#define AD9910_REFDIV2_MAX_FREQ_HZ (1900 * HZ_PER_MHZ)
+
+#define AD9910_SPI_DATA_IDX 1
+#define AD9910_SPI_DATA_LEN_MAX sizeof(__be64)
+#define AD9910_SPI_MESSAGE_LEN_MAX (AD9910_SPI_DATA_IDX + AD9910_SPI_DATA_LEN_MAX)
+#define AD9910_SPI_READ_MSK BIT(7)
+#define AD9910_SPI_ADDR_MSK GENMASK(4, 0)
+
+/**
+ * enum ad9910_channel - AD9910 channel identifiers in priority order
+ *
+ * @AD9910_CHANNEL_PHY: Physical output channel
+ * @AD9910_CHANNEL_PROFILE_0: Profile 0 output channel
+ * @AD9910_CHANNEL_PROFILE_1: Profile 1 output channel
+ * @AD9910_CHANNEL_PROFILE_2: Profile 2 output channel
+ * @AD9910_CHANNEL_PROFILE_3: Profile 3 output channel
+ * @AD9910_CHANNEL_PROFILE_4: Profile 4 output channel
+ * @AD9910_CHANNEL_PROFILE_5: Profile 5 output channel
+ * @AD9910_CHANNEL_PROFILE_6: Profile 6 output channel
+ * @AD9910_CHANNEL_PROFILE_7: Profile 7 output channel
+ */
+enum ad9910_channel {
+ AD9910_CHANNEL_PHY = 100,
+ AD9910_CHANNEL_PROFILE_0 = 110,
+ AD9910_CHANNEL_PROFILE_1 = 111,
+ AD9910_CHANNEL_PROFILE_2 = 112,
+ AD9910_CHANNEL_PROFILE_3 = 113,
+ AD9910_CHANNEL_PROFILE_4 = 114,
+ AD9910_CHANNEL_PROFILE_5 = 115,
+ AD9910_CHANNEL_PROFILE_6 = 116,
+ AD9910_CHANNEL_PROFILE_7 = 117,
+};
+
+enum {
+ AD9910_CHAN_IDX_PHY,
+ AD9910_CHAN_IDX_PROFILE_0,
+ AD9910_CHAN_IDX_PROFILE_1,
+ AD9910_CHAN_IDX_PROFILE_2,
+ AD9910_CHAN_IDX_PROFILE_3,
+ AD9910_CHAN_IDX_PROFILE_4,
+ AD9910_CHAN_IDX_PROFILE_5,
+ AD9910_CHAN_IDX_PROFILE_6,
+ AD9910_CHAN_IDX_PROFILE_7,
+};
+
+enum {
+ AD9910_POWERDOWN,
+};
+
+struct ad9910_data {
+ u32 sysclk_freq_hz;
+ u32 dac_output_current;
+
+ u16 pll_charge_pump_current;
+ u8 refclk_out_drv;
+ bool pll_enabled;
+};
+
+union ad9910_reg {
+ u64 val64;
+ u32 val32;
+ u16 val16;
+};
+
+struct ad9910_state {
+ struct spi_device *spi;
+ struct clk *refclk;
+
+ struct gpio_desc *gpio_pwdown;
+ struct gpio_desc *gpio_update;
+ struct gpio_descs *gpio_profile;
+
+ /* cached registers */
+ union ad9910_reg reg[AD9910_REG_NUM_CACHED];
+
+ /* Lock for accessing device registers and state variables */
+ struct mutex lock;
+
+ struct ad9910_data data;
+ u8 profile;
+
+ /*
+ * RAM loading requires a reasonable amount of bytes, at the same time
+ * DMA capable SPI drivers requires the transfer buffers to live in
+ * their own cache lines.
+ */
+ u8 tx_buf[AD9910_SPI_MESSAGE_LEN_MAX] __aligned(IIO_DMA_MINALIGN);
+};
+
+/**
+ * ad9910_rational_scale() - Perform scaling of input given a reference.
+ * @input: The input value to be scaled.
+ * @scale: The numerator of the scaling factor.
+ * @reference: The denominator of the scaling factor.
+ *
+ * Closest rounding with mul_u64_add_u64_div_u64
+ *
+ * Return: The scaled value.
+ */
+static inline u64 ad9910_rational_scale(u64 input, u64 scale, u64 reference)
+{
+ return mul_u64_add_u64_div_u64(input, scale, reference >> 1, reference);
+}
+
+static int ad9910_io_update(struct ad9910_state *st)
+{
+ if (st->gpio_update) {
+ gpiod_set_value_cansleep(st->gpio_update, 1);
+ udelay(1);
+ gpiod_set_value_cansleep(st->gpio_update, 0);
+ }
+
+ return 0;
+}
+
+static inline int ad9910_spi_read(struct ad9910_state *st, u8 reg, void *data,
+ size_t len)
+{
+ u8 inst = AD9910_SPI_READ_MSK | FIELD_PREP(AD9910_SPI_ADDR_MSK, reg);
+
+ return spi_write_then_read(st->spi, &inst, sizeof(inst), data, len);
+}
+
+static inline int ad9910_spi_write(struct ad9910_state *st, u8 reg, size_t len,
+ bool update)
+{
+ int ret;
+
+ st->tx_buf[0] = FIELD_PREP(AD9910_SPI_ADDR_MSK, reg);
+ ret = spi_write(st->spi, st->tx_buf, AD9910_SPI_DATA_IDX + len);
+ if (ret)
+ return ret;
+
+ if (update)
+ return ad9910_io_update(st);
+
+ return 0;
+}
+
+#define AD9910_REG_READ_FN(nb) \
+static int ad9910_reg##nb##_read(struct ad9910_state *st, u8 reg, \
+ u##nb * data) \
+{ \
+ __be##nb be_data; \
+ int ret; \
+ \
+ ret = ad9910_spi_read(st, reg, &be_data, sizeof(be_data)); \
+ if (ret) \
+ return ret; \
+ \
+ *data = be##nb##_to_cpu(be_data); \
+ return ret; \
+}
+
+AD9910_REG_READ_FN(16)
+AD9910_REG_READ_FN(32)
+AD9910_REG_READ_FN(64)
+
+#define AD9910_REG_WRITE_FN(nb) \
+static int ad9910_reg##nb##_write(struct ad9910_state *st, u8 reg, \
+ u##nb data, bool update) \
+{ \
+ int ret; \
+ \
+ put_unaligned_be##nb(data, &st->tx_buf[AD9910_SPI_DATA_IDX]); \
+ ret = ad9910_spi_write(st, reg, sizeof(data), update); \
+ if (ret) \
+ return ret; \
+ \
+ st->reg[reg].val##nb = data; \
+ return ret; \
+}
+
+AD9910_REG_WRITE_FN(16)
+AD9910_REG_WRITE_FN(32)
+AD9910_REG_WRITE_FN(64)
+
+#define AD9910_REG_UPDATE_FN(nb) \
+static int ad9910_reg##nb##_update(struct ad9910_state *st, \
+ u8 reg, u##nb mask, \
+ u##nb data, bool update) \
+{ \
+ u##nb reg_val = (st->reg[reg].val##nb & ~mask) | (data & mask); \
+ \
+ if (reg_val == st->reg[reg].val##nb && !update) \
+ return 0; \
+ \
+ return ad9910_reg##nb##_write(st, reg, reg_val, update); \
+}
+
+AD9910_REG_UPDATE_FN(16)
+AD9910_REG_UPDATE_FN(32)
+AD9910_REG_UPDATE_FN(64)
+
+static int ad9910_set_dac_current(struct ad9910_state *st, bool update)
+{
+ u32 fsc_code;
+
+ /* FSC = (86.4 / Rset) * (1 + CODE/256) where Rset = 10k ohms */
+ fsc_code = DIV_ROUND_CLOSEST(st->data.dac_output_current, 90) - 96;
+ fsc_code &= 0xFF;
+
+ return ad9910_reg32_write(st, AD9910_REG_AUX_DAC, fsc_code, update);
+}
+
+static int ad9910_set_sysclk_freq(struct ad9910_state *st, u32 freq_hz,
+ bool update)
+{
+ struct device *dev = &st->spi->dev;
+ u32 sysclk_freq_hz, refclk_freq_hz;
+ u32 tmp32, vco_sel;
+ int ret;
+
+ if (!freq_hz || freq_hz > AD9910_MAX_SYSCLK_HZ)
+ return -EINVAL;
+
+ refclk_freq_hz = clk_get_rate(st->refclk);
+ if (st->data.pll_enabled) {
+ if (refclk_freq_hz < AD9910_PLL_IN_MIN_FREQ_HZ ||
+ refclk_freq_hz > AD9910_PLL_IN_MAX_FREQ_HZ) {
+ dev_err(dev,
+ "REF_CLK frequency %u Hz is out of PLL input range\n",
+ refclk_freq_hz);
+ return -ERANGE;
+ }
+
+ tmp32 = DIV_ROUND_CLOSEST(freq_hz, refclk_freq_hz);
+ tmp32 = clamp(tmp32, DIV_ROUND_UP(AD9910_PLL_OUT_MIN_FREQ_HZ, refclk_freq_hz),
+ AD9910_PLL_OUT_MAX_FREQ_HZ / refclk_freq_hz);
+ tmp32 = clamp(tmp32, AD9910_PLL_MIN_N, AD9910_PLL_MAX_N);
+ sysclk_freq_hz = refclk_freq_hz * tmp32;
+
+ if (sysclk_freq_hz <= AD9910_VCO0_RANGE_AUTO_MAX_HZ)
+ vco_sel = 0;
+ else if (sysclk_freq_hz <= AD9910_VCO1_RANGE_AUTO_MAX_HZ)
+ vco_sel = 1;
+ else if (sysclk_freq_hz <= AD9910_VCO2_RANGE_AUTO_MAX_HZ)
+ vco_sel = 2;
+ else if (sysclk_freq_hz <= AD9910_VCO3_RANGE_AUTO_MAX_HZ)
+ vco_sel = 3;
+ else if (sysclk_freq_hz <= AD9910_VCO4_RANGE_AUTO_MAX_HZ)
+ vco_sel = 4;
+ else
+ vco_sel = 5;
+
+ ret = ad9910_reg32_update(st, AD9910_REG_CFR3,
+ AD9910_CFR3_N_MSK | AD9910_CFR3_VCO_SEL_MSK,
+ FIELD_PREP(AD9910_CFR3_N_MSK, tmp32) |
+ FIELD_PREP(AD9910_CFR3_VCO_SEL_MSK, vco_sel),
+ update);
+ if (ret)
+ return ret;
+ } else {
+ tmp32 = DIV_ROUND_CLOSEST(refclk_freq_hz, freq_hz);
+ tmp32 = clamp(tmp32, 1U, 2U);
+ sysclk_freq_hz = refclk_freq_hz / tmp32;
+ tmp32 = AD9910_CFR3_VCO_SEL_MSK |
+ FIELD_PREP(AD9910_CFR3_REFCLK_DIV_BYPASS_MSK, tmp32 % 2);
+ ret = ad9910_reg32_update(st, AD9910_REG_CFR3,
+ AD9910_CFR3_VCO_SEL_MSK |
+ AD9910_CFR3_REFCLK_DIV_BYPASS_MSK,
+ tmp32, update);
+ if (ret)
+ return ret;
+ }
+
+ st->data.sysclk_freq_hz = sysclk_freq_hz;
+
+ return 0;
+}
+
+static int ad9910_profile_set(struct ad9910_state *st, u8 profile)
+{
+ DECLARE_BITMAP(values, BITS_PER_TYPE(profile));
+
+ st->profile = profile;
+ values[0] = profile;
+ gpiod_multi_set_value_cansleep(st->gpio_profile, values);
+
+ return 0;
+}
+
+static inline bool ad9910_sw_powerdown_get(struct ad9910_state *st)
+{
+ return FIELD_GET(AD9910_CFR1_SOFT_POWER_DOWN_MSK,
+ st->reg[AD9910_REG_CFR1].val32) ? true : false;
+}
+
+static int ad9910_sw_powerdown_set(struct ad9910_state *st, bool enable)
+{
+ if (ad9910_sw_powerdown_get(st) == enable)
+ return 0;
+
+ return ad9910_reg32_update(st, AD9910_REG_CFR1,
+ AD9910_CFR1_SOFT_POWER_DOWN_MSK,
+ enable ? AD9910_CFR1_SOFT_POWER_DOWN_MSK : 0,
+ true);
+}
+
+static ssize_t ad9910_ext_info_read(struct iio_dev *indio_dev,
+ uintptr_t private,
+ const struct iio_chan_spec *chan,
+ char *buf)
+{
+ struct ad9910_state *st = iio_priv(indio_dev);
+ int val;
+
+ guard(mutex)(&st->lock);
+
+ switch (private) {
+ case AD9910_POWERDOWN:
+ val = ad9910_sw_powerdown_get(st);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return iio_format_value(buf, IIO_VAL_INT, 1, &val);
+}
+
+static ssize_t ad9910_ext_info_write(struct iio_dev *indio_dev,
+ uintptr_t private,
+ const struct iio_chan_spec *chan,
+ const char *buf, size_t len)
+{
+ struct ad9910_state *st = iio_priv(indio_dev);
+ u32 val32;
+ int ret;
+
+ ret = kstrtou32(buf, 10, &val32);
+ if (ret)
+ return ret;
+
+ guard(mutex)(&st->lock);
+
+ switch (private) {
+ case AD9910_POWERDOWN:
+ ret = ad9910_sw_powerdown_set(st, val32 ? true : false);
+ if (ret)
+ return ret;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return len;
+}
+
+#define AD9910_EXT_INFO_TMPL(_name, _ident, _shared, _fn_desc) { \
+ .name = _name, \
+ .read = ad9910_ ## _fn_desc ## _read, \
+ .write = ad9910_ ## _fn_desc ## _write, \
+ .private = _ident, \
+ .shared = _shared, \
+}
+
+#define AD9910_EXT_INFO(_name, _ident, _shared) \
+ AD9910_EXT_INFO_TMPL(_name, _ident, _shared, ext_info)
+
+static const struct iio_chan_spec_ext_info ad9910_phy_ext_info[] = {
+ AD9910_EXT_INFO("powerdown", AD9910_POWERDOWN, IIO_SEPARATE),
+ { }
+};
+
+#define AD9910_PROFILE_CHAN(idx) { \
+ .type = IIO_ALTVOLTAGE, \
+ .indexed = 1, \
+ .output = 1, \
+ .channel = AD9910_CHANNEL_PROFILE_ ## idx, \
+ .address = AD9910_CHAN_IDX_PROFILE_ ## idx, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_ENABLE) | \
+ BIT(IIO_CHAN_INFO_FREQUENCY) | \
+ BIT(IIO_CHAN_INFO_PHASE) | \
+ BIT(IIO_CHAN_INFO_SCALE), \
+ .parent = &ad9910_channels[AD9910_CHAN_IDX_PHY], \
+}
+
+static const struct iio_chan_spec ad9910_channels[] = {
+ [AD9910_CHAN_IDX_PHY] = {
+ .type = IIO_ALTVOLTAGE,
+ .indexed = 1,
+ .output = 1,
+ .channel = AD9910_CHANNEL_PHY,
+ .address = AD9910_CHAN_IDX_PHY,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_SAMP_FREQ),
+ .ext_info = ad9910_phy_ext_info,
+ },
+ [AD9910_CHAN_IDX_PROFILE_0] = AD9910_PROFILE_CHAN(0),
+ [AD9910_CHAN_IDX_PROFILE_1] = AD9910_PROFILE_CHAN(1),
+ [AD9910_CHAN_IDX_PROFILE_2] = AD9910_PROFILE_CHAN(2),
+ [AD9910_CHAN_IDX_PROFILE_3] = AD9910_PROFILE_CHAN(3),
+ [AD9910_CHAN_IDX_PROFILE_4] = AD9910_PROFILE_CHAN(4),
+ [AD9910_CHAN_IDX_PROFILE_5] = AD9910_PROFILE_CHAN(5),
+ [AD9910_CHAN_IDX_PROFILE_6] = AD9910_PROFILE_CHAN(6),
+ [AD9910_CHAN_IDX_PROFILE_7] = AD9910_PROFILE_CHAN(7),
+};
+
+static int ad9910_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long info)
+{
+ struct ad9910_state *st = iio_priv(indio_dev);
+ u64 tmp64;
+ u32 tmp32;
+
+ guard(mutex)(&st->lock);
+
+ switch (info) {
+ case IIO_CHAN_INFO_ENABLE:
+ switch (chan->channel) {
+ case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
+ if (ad9910_sw_powerdown_get(st)) {
+ *val = 0;
+ } else {
+ tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
+ *val = (tmp32 == st->profile);
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_FREQUENCY:
+ switch (chan->channel) {
+ case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
+ tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
+ tmp64 = FIELD_GET(AD9910_PROFILE_ST_FTW_MSK,
+ st->reg[AD9910_REG_PROFILE(tmp32)].val64);
+ break;
+ default:
+ return -EINVAL;
+ }
+ tmp64 *= st->data.sysclk_freq_hz;
+ *val = tmp64 >> 32;
+ *val2 = ((tmp64 & GENMASK_ULL(31, 0)) * MICRO) >> 32;
+ return IIO_VAL_INT_PLUS_MICRO;
+ case IIO_CHAN_INFO_PHASE:
+ switch (chan->channel) {
+ case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
+ tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
+ tmp64 = FIELD_GET(AD9910_PROFILE_ST_POW_MSK,
+ st->reg[AD9910_REG_PROFILE(tmp32)].val64);
+ tmp32 = (tmp64 * AD9910_MAX_PHASE_MICRORAD) >> 16;
+ *val = tmp32 / MICRO;
+ *val2 = tmp32 % MICRO;
+ return IIO_VAL_INT_PLUS_MICRO;
+ default:
+ return -EINVAL;
+ }
+ case IIO_CHAN_INFO_SCALE:
+ switch (chan->channel) {
+ case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
+ tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
+ tmp64 = FIELD_GET(AD9910_PROFILE_ST_ASF_MSK,
+ st->reg[AD9910_REG_PROFILE(tmp32)].val64);
+ *val = 0;
+ *val2 = tmp64 * MICRO >> 14;
+ return IIO_VAL_INT_PLUS_MICRO;
+ default:
+ return -EINVAL;
+ }
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ switch (chan->channel) {
+ case AD9910_CHANNEL_PHY:
+ *val = st->data.sysclk_freq_hz;
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+ default:
+ return -EINVAL;
+ }
+}
+
+static int ad9910_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int val, int val2, long info)
+{
+ struct ad9910_state *st = iio_priv(indio_dev);
+ u64 tmp64;
+ u32 tmp32;
+ int ret;
+
+ guard(mutex)(&st->lock);
+
+ switch (info) {
+ case IIO_CHAN_INFO_ENABLE:
+ switch (chan->channel) {
+ case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
+ tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
+ if (!val) {
+ if (tmp32 != st->profile)
+ return 0; /* nothing to do */
+
+ return ad9910_sw_powerdown_set(st, true);
+ }
+
+ ret = ad9910_sw_powerdown_set(st, false);
+ if (ret)
+ return ret;
+
+ return ad9910_profile_set(st, tmp32);
+ default:
+ return -EINVAL;
+ }
+ case IIO_CHAN_INFO_FREQUENCY:
+ if (val < 0 || val2 < 0 || val >= st->data.sysclk_freq_hz / 2)
+ return -EINVAL;
+
+ tmp64 = ad9910_rational_scale((u64)val * MICRO + val2, BIT_ULL(32),
+ (u64)MICRO * st->data.sysclk_freq_hz);
+ tmp64 = min(tmp64, U32_MAX);
+ switch (chan->channel) {
+ case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
+ tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
+ tmp64 = FIELD_PREP(AD9910_PROFILE_ST_FTW_MSK, tmp64);
+ return ad9910_reg64_update(st, AD9910_REG_PROFILE(tmp32),
+ AD9910_PROFILE_ST_FTW_MSK,
+ tmp64, true);
+ default:
+ return -EINVAL;
+ }
+ case IIO_CHAN_INFO_PHASE:
+ if (val < 0 || val2 < 0)
+ return -EINVAL;
+
+ switch (chan->channel) {
+ case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
+ tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
+ tmp64 = (u64)val * MICRO + val2;
+ if (tmp64 >= AD9910_MAX_PHASE_MICRORAD)
+ return -EINVAL;
+
+ tmp64 <<= 16;
+ tmp64 = DIV_U64_ROUND_CLOSEST(tmp64, AD9910_MAX_PHASE_MICRORAD);
+ tmp64 = min(tmp64, AD9910_POW_MAX);
+ tmp64 = FIELD_PREP(AD9910_PROFILE_ST_POW_MSK, tmp64);
+ return ad9910_reg64_update(st, AD9910_REG_PROFILE(tmp32),
+ AD9910_PROFILE_ST_POW_MSK,
+ tmp64, true);
+ default:
+ return -EINVAL;
+ }
+ case IIO_CHAN_INFO_SCALE:
+ if (val < 0 || val2 < 0 || val > 1 || (val == 1 && val2 > 0))
+ return -EINVAL;
+
+ switch (chan->channel) {
+ case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
+ tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
+ tmp64 = ((u64)val * MICRO + val2) << 14;
+ tmp64 = DIV_U64_ROUND_CLOSEST(tmp64, MICRO);
+ tmp64 = min(tmp64, AD9910_ASF_MAX);
+ tmp64 = FIELD_PREP(AD9910_PROFILE_ST_ASF_MSK, tmp64);
+ return ad9910_reg64_update(st, AD9910_REG_PROFILE(tmp32),
+ AD9910_PROFILE_ST_ASF_MSK,
+ tmp64, true);
+ default:
+ return -EINVAL;
+ }
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ return ad9910_set_sysclk_freq(st, val, true);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int ad9910_write_raw_get_fmt(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ long mask)
+{
+ switch (mask) {
+ case IIO_CHAN_INFO_ENABLE:
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_FREQUENCY:
+ return IIO_VAL_INT_PLUS_MICRO;
+ case IIO_CHAN_INFO_PHASE:
+ case IIO_CHAN_INFO_SCALE:
+ switch (chan->channel) {
+ case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
+ return IIO_VAL_INT_PLUS_MICRO;
+ default:
+ return -EINVAL;
+ }
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int ad9910_debugfs_reg_access(struct iio_dev *indio_dev,
+ unsigned int reg, u64 writeval,
+ u64 *readval)
+{
+ struct ad9910_state *st = iio_priv(indio_dev);
+ union ad9910_reg tmp;
+ int ret;
+
+ if (reg >= AD9910_REG_RAM)
+ return -EINVAL;
+
+ guard(mutex)(&st->lock);
+
+ switch (reg) {
+ case AD9910_REG_DRG_LIMIT:
+ case AD9910_REG_DRG_STEP:
+ case AD9910_REG_PROFILE0 ... AD9910_REG_PROFILE7:
+ if (!readval)
+ return ad9910_reg64_write(st, reg, writeval, true);
+
+ ret = ad9910_reg64_read(st, reg, &tmp.val64);
+ if (ret)
+ return ret;
+ *readval = tmp.val64;
+ return 0;
+ case AD9910_REG_POW:
+ if (!readval)
+ return ad9910_reg16_write(st, reg, writeval, true);
+
+ ret = ad9910_reg16_read(st, reg, &tmp.val16);
+ if (ret)
+ return ret;
+ *readval = tmp.val16;
+ return 0;
+ default:
+ if (!readval)
+ return ad9910_reg32_write(st, reg, writeval, true);
+
+ ret = ad9910_reg32_read(st, reg, &tmp.val32);
+ if (ret)
+ return ret;
+ *readval = tmp.val32;
+ return 0;
+ }
+}
+
+static const char * const ad9910_channel_str[] = {
+ [AD9910_CHAN_IDX_PHY] = "phy",
+ [AD9910_CHAN_IDX_PROFILE_0] = "profile0",
+ [AD9910_CHAN_IDX_PROFILE_1] = "profile1",
+ [AD9910_CHAN_IDX_PROFILE_2] = "profile2",
+ [AD9910_CHAN_IDX_PROFILE_3] = "profile3",
+ [AD9910_CHAN_IDX_PROFILE_4] = "profile4",
+ [AD9910_CHAN_IDX_PROFILE_5] = "profile5",
+ [AD9910_CHAN_IDX_PROFILE_6] = "profile6",
+ [AD9910_CHAN_IDX_PROFILE_7] = "profile7",
+};
+
+static int ad9910_read_label(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ char *label)
+{
+ return sysfs_emit(label, "%s\n", ad9910_channel_str[chan->address]);
+}
+
+static const struct iio_info ad9910_info = {
+ .read_raw = ad9910_read_raw,
+ .write_raw = ad9910_write_raw,
+ .write_raw_get_fmt = ad9910_write_raw_get_fmt,
+ .read_label = ad9910_read_label,
+ .debugfs_reg64_access = &ad9910_debugfs_reg_access,
+};
+
+static int ad9910_cfg_sysclk(struct ad9910_state *st, bool update)
+{
+ u32 cfr3 = AD9910_CFR3_OPEN_MSK;
+ u32 tmp32;
+
+ cfr3 |= FIELD_PREP(AD9910_CFR3_DRV0_MSK, st->data.refclk_out_drv);
+
+ if (st->data.pll_enabled) {
+ tmp32 = st->data.pll_charge_pump_current - AD9910_ICP_MIN_uA;
+ tmp32 = DIV_ROUND_CLOSEST(tmp32, AD9910_ICP_STEP_uA);
+ cfr3 |= FIELD_PREP(AD9910_CFR3_ICP_MSK, tmp32) |
+ AD9910_CFR3_PLL_EN_MSK;
+ } else {
+ cfr3 |= AD9910_CFR3_ICP_MSK |
+ AD9910_CFR3_REFCLK_DIV_RESETB_MSK |
+ AD9910_CFR3_PFD_RESET_MSK;
+ }
+ st->reg[AD9910_REG_CFR3].val32 = cfr3;
+
+ return ad9910_set_sysclk_freq(st, AD9910_MAX_SYSCLK_HZ, update);
+}
+
+static int ad9910_parse_fw(struct ad9910_state *st)
+{
+ static const char * const refclk_out_drv0[] = {
+ "disabled", "low", "medium", "high",
+ };
+ struct device *dev = &st->spi->dev;
+ u32 tmp[2];
+ int ret;
+
+ st->data.pll_enabled = device_property_read_bool(dev, "adi,pll-enable");
+ if (st->data.pll_enabled) {
+ tmp[0] = AD9910_ICP_MIN_uA;
+ device_property_read_u32(dev, "adi,charge-pump-current-microamp", &tmp[0]);
+ if (tmp[0] < AD9910_ICP_MIN_uA || tmp[0] > AD9910_ICP_MAX_uA)
+ return dev_err_probe(dev, -ERANGE,
+ "invalid charge pump current %u\n", tmp[0]);
+ st->data.pll_charge_pump_current = tmp[0];
+
+ ret = device_property_match_property_string(dev,
+ "adi,refclk-out-drive-strength",
+ refclk_out_drv0,
+ ARRAY_SIZE(refclk_out_drv0));
+ if (ret < 0)
+ st->data.refclk_out_drv = AD9910_REFCLK_OUT_DRV_DISABLED;
+ else
+ st->data.refclk_out_drv = ret;
+ }
+
+ tmp[1] = AD9910_DAC_IOUT_DEFAULT_uA;
+ device_property_read_u32_array(dev, "output-range-microamp", tmp,
+ ARRAY_SIZE(tmp));
+ if (tmp[1] < AD9910_DAC_IOUT_MIN_uA || tmp[1] > AD9910_DAC_IOUT_MAX_uA)
+ return dev_err_probe(dev, -ERANGE,
+ "Invalid DAC output current %u uA\n", tmp[1]);
+ st->data.dac_output_current = tmp[1];
+
+ return 0;
+}
+
+static void ad9910_sw_powerdown_action(void *data)
+{
+ ad9910_sw_powerdown_set(data, true);
+}
+
+static void ad9910_hw_powerdown_action(void *data)
+{
+ struct ad9910_state *st = data;
+
+ gpiod_set_value_cansleep(st->gpio_pwdown, 1);
+}
+
+static int ad9910_setup(struct device *dev, struct ad9910_state *st,
+ struct reset_control *dev_rst)
+{
+ int ret;
+
+ ret = reset_control_deassert(dev_rst);
+ if (ret)
+ return ret;
+
+ ret = ad9910_reg32_write(st, AD9910_REG_CFR1,
+ (st->spi->mode & SPI_3WIRE ? 0 :
+ AD9910_CFR1_SDIO_INPUT_ONLY_MSK), false);
+ if (ret)
+ return ret;
+
+ ret = devm_add_action_or_reset(dev, ad9910_sw_powerdown_action, st);
+ if (ret)
+ return ret;
+
+ ret = ad9910_reg32_write(st, AD9910_REG_CFR2,
+ AD9910_CFR2_AMP_SCALE_SINGLE_TONE_MSK |
+ AD9910_CFR2_SYNC_TIMING_VAL_DISABLE_MSK |
+ AD9910_CFR2_DRG_NO_DWELL_MSK |
+ AD9910_CFR2_DATA_ASM_HOLD_LAST_MSK |
+ AD9910_CFR2_SYNC_CLK_EN_MSK |
+ AD9910_CFR2_PDCLK_ENABLE_MSK, false);
+ if (ret)
+ return ret;
+
+ ret = ad9910_cfg_sysclk(st, false);
+ if (ret)
+ return ret;
+
+ ret = ad9910_set_dac_current(st, false);
+ if (ret)
+ return ret;
+
+ return ad9910_io_update(st);
+}
+
+static int ad9910_probe(struct spi_device *spi)
+{
+ static const char * const supplies[] = {
+ "dvdd-io33", "avdd33", "dvdd18", "avdd18",
+ };
+ struct device *dev = &spi->dev;
+ struct reset_control *dev_rst;
+ struct gpio_desc *io_rst_gpio;
+ struct iio_dev *indio_dev;
+ struct ad9910_state *st;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*st));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ st = iio_priv(indio_dev);
+ st->spi = spi;
+
+ st->refclk = devm_clk_get_enabled(dev, "ref_clk");
+ if (IS_ERR(st->refclk))
+ return dev_err_probe(dev, PTR_ERR(st->refclk),
+ "Failed to get reference clock\n");
+
+ ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(supplies), supplies);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to get regulators\n");
+
+ ret = devm_mutex_init(dev, &st->lock);
+ if (ret)
+ return ret;
+
+ indio_dev->name = "ad9910";
+ indio_dev->info = &ad9910_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->channels = ad9910_channels;
+ indio_dev->num_channels = ARRAY_SIZE(ad9910_channels);
+
+ dev_rst = devm_reset_control_get_optional_exclusive(dev, NULL);
+ if (IS_ERR(dev_rst))
+ return dev_err_probe(dev, PTR_ERR(dev_rst),
+ "failed to get device reset control\n");
+
+ /*
+ * The IO RESET pin is not used in this driver, as we assume that all
+ * SPI transfers are complete, but if it is wired up, we need to make
+ * sure it is not floating. We can use either a reset controller or a
+ * GPIO for this.
+ */
+ io_rst_gpio = devm_gpiod_get_optional(dev, "io-reset", GPIOD_OUT_LOW);
+ if (IS_ERR(io_rst_gpio))
+ return dev_err_probe(dev, PTR_ERR(io_rst_gpio),
+ "failed to get io reset gpio\n");
+
+ st->gpio_update = devm_gpiod_get_optional(dev, "update", GPIOD_OUT_LOW);
+ if (IS_ERR(st->gpio_update))
+ return dev_err_probe(dev, PTR_ERR(st->gpio_update),
+ "failed to get update gpio\n");
+
+ st->gpio_profile = devm_gpiod_get_array_optional(dev, "profile",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(st->gpio_profile))
+ return dev_err_probe(dev, PTR_ERR(st->gpio_profile),
+ "failed to get profile gpios\n");
+
+ st->gpio_pwdown = devm_gpiod_get_optional(dev, "powerdown",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(st->gpio_pwdown))
+ return dev_err_probe(dev, PTR_ERR(st->gpio_pwdown),
+ "failed to get powerdown gpio\n");
+
+ ret = devm_add_action_or_reset(dev, ad9910_hw_powerdown_action, st);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to add hw powerdown action\n");
+
+ ret = ad9910_parse_fw(st);
+ if (ret)
+ return ret;
+
+ ret = ad9910_setup(dev, st, dev_rst);
+ if (ret)
+ return dev_err_probe(dev, ret, "device setup failed\n");
+
+ return devm_iio_device_register(dev, indio_dev);
+}
+
+static const struct spi_device_id ad9910_id[] = {
+ { "ad9910" },
+ { }
+};
+MODULE_DEVICE_TABLE(spi, ad9910_id);
+
+static const struct of_device_id ad9910_of_match[] = {
+ { .compatible = "adi,ad9910" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ad9910_of_match);
+
+static struct spi_driver ad9910_driver = {
+ .driver = {
+ .name = "ad9910",
+ .of_match_table = ad9910_of_match,
+ },
+ .probe = ad9910_probe,
+ .id_table = ad9910_id,
+};
+module_spi_driver(ad9910_driver);
+
+MODULE_AUTHOR("Rodrigo Alencar <rodrigo.alencar@analog.com>");
+MODULE_DESCRIPTION("Analog Devices AD9910 DDS driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v5 06/13] iio: frequency: ad9910: initial driver implementation
2026-05-17 18:37 ` [PATCH v5 06/13] iio: frequency: ad9910: initial driver implementation Rodrigo Alencar via B4 Relay
@ 2026-05-18 11:45 ` Rodrigo Alencar
2026-05-22 18:03 ` Jonathan Cameron
1 sibling, 0 replies; 28+ messages in thread
From: Rodrigo Alencar @ 2026-05-18 11:45 UTC (permalink / raw)
To: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
On 26/05/17 07:20PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
> - [High] Incorrect usage of `device_property_read_u32_array` causes single-value property `output-range-microamp` to be ignored.
> - [High] VCO_SEL field is incorrectly set to an out-of-bounds value (7) when the PLL is bypassed.
> - [High] Stack out-of-bounds read in `ad9910_profile_set()` triggered by unvalidated GPIO descriptor count.
> - [High] Missing resource teardown: device reset line is never asserted on driver removal.
> - [Medium] PLL multiplier clamping logic violates the hardware's minimum VCO operating frequency.
> - [Medium] Missing hardware initialization delay after reset deassertion can cause SPI communications to fail.
> --
>
> commit fb6e130c7d866653f35ab965acf927500a84756c
> Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> iio: frequency: ad9910: initial driver implementation
>
> Add the core AD9910 DDS driver infrastructure with single tone mode
> support. This includes SPI register access, profile management via GPIO
> pins, PLL/DAC configuration from firmware properties, and single tone
> frequency/phase/amplitude control through IIO attributes.
>
> > diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> > new file mode 100644
> > index 0000000000000..c7b1e474c92df
> > --- /dev/null
> > +++ b/drivers/iio/frequency/ad9910.c
> [ ... ]
> > +static int ad9910_set_sysclk_freq(struct ad9910_state *st, u32 freq_hz,
> > + bool update)
> > +{
> [ ... ]
> > + tmp32 = clamp(tmp32, DIV_ROUND_UP(AD9910_PLL_OUT_MIN_FREQ_HZ, refclk_freq_hz),
> > + AD9910_PLL_OUT_MAX_FREQ_HZ / refclk_freq_hz);
> > + tmp32 = clamp(tmp32, AD9910_PLL_MIN_N, AD9910_PLL_MAX_N);
> > + sysclk_freq_hz = refclk_freq_hz * tmp32;
>
> Is it possible for this second clamp to drop the multiplier below the
> minimum frequency constraint? If the input reference clock is 3.2 MHz,
> the first clamp would raise the multiplier to 132 to reach 420 MHz, but
> the second clamp limits it to 127. This results in a VCO frequency of
> 406.4 MHz, violating the hardware minimum. Should the driver return
> -ERANGE instead if the bounds cannot be satisfied?
I suppose that would not be problematic as the PLL does accept that input
frequency. Even though the VCO might not be designed for frequencies as low as
406.4 MHz, we are doing the best effort here to get a proper configuration.
> [ ... ]
> > + } else {
> > + tmp32 = DIV_ROUND_CLOSEST(refclk_freq_hz, freq_hz);
> > + tmp32 = clamp(tmp32, 1U, 2U);
> > + sysclk_freq_hz = refclk_freq_hz / tmp32;
> > + tmp32 = AD9910_CFR3_VCO_SEL_MSK |
> > + FIELD_PREP(AD9910_CFR3_REFCLK_DIV_BYPASS_MSK, tmp32 % 2);
> > + ret = ad9910_reg32_update(st, AD9910_REG_CFR3,
> > + AD9910_CFR3_VCO_SEL_MSK |
> > + AD9910_CFR3_REFCLK_DIV_BYPASS_MSK,
> > + tmp32, update);
>
> Does setting tmp32 with AD9910_CFR3_VCO_SEL_MSK cause the update function
> to write an out-of-bounds value here? Because tmp32 contains the entire
> mask, the underlying field will be set to 7, but the valid range for the
> vco sel field is 0 to 5.
No, 6 and 7 means PLL bypassed (Table 8 in the datasheet). Also, 7 is the
default value of that bitfield.
> [ ... ]
> > +static int ad9910_profile_set(struct ad9910_state *st, u8 profile)
> > +{
> > + DECLARE_BITMAP(values, BITS_PER_TYPE(profile));
> > +
> > + st->profile = profile;
> > + values[0] = profile;
> > + gpiod_multi_set_value_cansleep(st->gpio_profile, values);
> > +
> > + return 0;
> > +}
>
> Could this cause an out-of-bounds read on the stack? The values bitmap is
> sized using BITS_PER_TYPE(profile), which allocates space for 1 unsigned
> long. If the device tree provides more profile gpios than fit in an unsigned
> long, gpiod_multi_set_value_cansleep() might read past the end of the bitmap
> when iterating over the descriptors.
well, profile-gpios are at most 3 pins. I'll see to constraint that in the
probe function.
> [ ... ]
> > +static int ad9910_parse_fw(struct ad9910_state *st)
> > +{
> [ ... ]
> > + tmp[1] = AD9910_DAC_IOUT_DEFAULT_uA;
> > + device_property_read_u32_array(dev, "output-range-microamp", tmp,
> > + ARRAY_SIZE(tmp));
>
> Will this properly read a single-value property? Because ARRAY_SIZE(tmp)
> is passed as the expected element count, device_property_read_u32_array()
> might return -EOVERFLOW and leave the tmp array unmodified if only one
> value is present in the device tree, causing the property to be silently
> ignored.
Ignoring those misconfigurations might be ok too. One can refer to the
bindings to have a proper reference.
>
> [ ... ]
> > +static int ad9910_setup(struct device *dev, struct ad9910_state *st,
> > + struct reset_control *dev_rst)
> > +{
> > + int ret;
> > +
> > + ret = reset_control_deassert(dev_rst);
> > + if (ret)
> > + return ret;
> > +
>
> Is a teardown action missing for the device reset here? Without adding a
> managed action to assert the reset line, the hardware might remain active
> after the driver is unloaded or if a subsequent setup step fails.
I'd say it can't remain active with the power down pin being handled already.
> Might this also require a hardware delay before the first spi write? The
> datasheet specifies waiting for the internal state machine to become ready
> after a low-to-high transition on the reset line. On fast hosts, the
> immediate spi access might be ignored.
Could not find that info in the datasheet. What is says is that the reset
clears memory elements, e.g. registers are set to default values.
> > + ret = ad9910_reg32_write(st, AD9910_REG_CFR1,
> > + (st->spi->mode & SPI_3WIRE ? 0 :
> > + AD9910_CFR1_SDIO_INPUT_ONLY_MSK), false);
> > + if (ret)
> > + return ret;
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260517-ad9910-iio-driver-v5-0-31599c88314a@analog.com?part=6
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH v5 06/13] iio: frequency: ad9910: initial driver implementation
2026-05-17 18:37 ` [PATCH v5 06/13] iio: frequency: ad9910: initial driver implementation Rodrigo Alencar via B4 Relay
2026-05-18 11:45 ` Rodrigo Alencar
@ 2026-05-22 18:03 ` Jonathan Cameron
1 sibling, 0 replies; 28+ messages in thread
From: Jonathan Cameron @ 2026-05-22 18:03 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
On Sun, 17 May 2026 19:37:50 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Add the core AD9910 DDS driver infrastructure with single tone mode
> support. This includes SPI register access, profile management via GPIO
> pins, PLL/DAC configuration from firmware properties, and single tone
> frequency/phase/amplitude control through IIO attributes.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Hi Rodrigo
A couple of potential nice to haves.
Jonathan
> +
> +static int ad9910_parse_fw(struct ad9910_state *st)
> +{
> + static const char * const refclk_out_drv0[] = {
> + "disabled", "low", "medium", "high",
> + };
> + struct device *dev = &st->spi->dev;
> + u32 tmp[2];
> + int ret;
> +
> + st->data.pll_enabled = device_property_read_bool(dev, "adi,pll-enable");
> + if (st->data.pll_enabled) {
> + tmp[0] = AD9910_ICP_MIN_uA;
> + device_property_read_u32(dev, "adi,charge-pump-current-microamp", &tmp[0]);
Might be a good idea to move to the pattern that seems to be becoming
the preferred way to do this and do
if (device_property_present()) {
ret = device_property_read_u32()...
...
} else {
...
}
That is slightly nicer ad picks up malformed DT. I know I was the advocate for
the set a default and don't check ret but I'm learning!
> + if (tmp[0] < AD9910_ICP_MIN_uA || tmp[0] > AD9910_ICP_MAX_uA)
> + return dev_err_probe(dev, -ERANGE,
> + "invalid charge pump current %u\n", tmp[0]);
> + st->data.pll_charge_pump_current = tmp[0];
> +
> + ret = device_property_match_property_string(dev,
> + "adi,refclk-out-drive-strength",
> + refclk_out_drv0,
> + ARRAY_SIZE(refclk_out_drv0));
> + if (ret < 0)
Similarly good to know if failure to match actually means wasn't there or not.
> + st->data.refclk_out_drv = AD9910_REFCLK_OUT_DRV_DISABLED;
> + else
> + st->data.refclk_out_drv = ret;
> + }
> +
> + tmp[1] = AD9910_DAC_IOUT_DEFAULT_uA;
And similar again.
> + device_property_read_u32_array(dev, "output-range-microamp", tmp,
> + ARRAY_SIZE(tmp));
> + if (tmp[1] < AD9910_DAC_IOUT_MIN_uA || tmp[1] > AD9910_DAC_IOUT_MAX_uA)
> + return dev_err_probe(dev, -ERANGE,
> + "Invalid DAC output current %u uA\n", tmp[1]);
> + st->data.dac_output_current = tmp[1];
> +
> + return 0;
> +}
> +static const struct spi_device_id ad9910_id[] = {
> + { "ad9910" },
Request to simplify what Uwe is busy doing (assuming he'll get to spi
at somepoint). Please use a named initializer like we always do for
of_device_id.
> + { }
> +};
> +MODULE_DEVICE_TABLE(spi, ad9910_id);
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v5 07/13] iio: frequency: ad9910: add basic parallel port support
2026-05-17 18:37 [PATCH v5 00/13] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
` (5 preceding siblings ...)
2026-05-17 18:37 ` [PATCH v5 06/13] iio: frequency: ad9910: initial driver implementation Rodrigo Alencar via B4 Relay
@ 2026-05-17 18:37 ` Rodrigo Alencar via B4 Relay
2026-05-17 18:37 ` [PATCH v5 08/13] iio: frequency: ad9910: add digital ramp generator support Rodrigo Alencar via B4 Relay
` (5 subsequent siblings)
12 siblings, 0 replies; 28+ messages in thread
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add parallel port channel with frequency scale, frequency offset, phase
offset, and amplitude offset extended attributes for configuring the
parallel data path. Enabling and disabling of parallel mode will be
implemented with buffer setup ops when an IIO backend integration is in
place.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
drivers/iio/frequency/ad9910.c | 147 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 147 insertions(+)
diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
index c7b1e474c92d..d2f40927b9be 100644
--- a/drivers/iio/frequency/ad9910.c
+++ b/drivers/iio/frequency/ad9910.c
@@ -112,9 +112,13 @@
/* Auxiliary DAC Control Register Bits */
#define AD9910_AUX_DAC_FSC_MSK GENMASK(7, 0)
+/* POW Register Bits */
+#define AD9910_POW_PP_LSB_MSK GENMASK(7, 0)
+
/* ASF Register Bits */
#define AD9910_ASF_RAMP_RATE_MSK GENMASK(31, 16)
#define AD9910_ASF_SCALE_FACTOR_MSK GENMASK(15, 2)
+#define AD9910_ASF_SCALE_FACTOR_PP_LSB_MSK GENMASK(7, 2)
#define AD9910_ASF_STEP_SIZE_MSK GENMASK(1, 0)
/* Multichip Sync Register Bits */
@@ -138,7 +142,9 @@
#define AD9910_MAX_PHASE_MICRORAD (AD9910_PI_NANORAD / 500)
#define AD9910_ASF_MAX GENMASK(13, 0)
+#define AD9910_ASF_PP_LSB_MAX GENMASK(5, 0)
#define AD9910_POW_MAX GENMASK(15, 0)
+#define AD9910_POW_PP_LSB_MAX GENMASK(7, 0)
#define AD9910_NUM_PROFILES 8
/* PLL constants */
@@ -189,6 +195,7 @@
* @AD9910_CHANNEL_PROFILE_5: Profile 5 output channel
* @AD9910_CHANNEL_PROFILE_6: Profile 6 output channel
* @AD9910_CHANNEL_PROFILE_7: Profile 7 output channel
+ * @AD9910_CHANNEL_PARALLEL_PORT: Parallel Port output channel
*/
enum ad9910_channel {
AD9910_CHANNEL_PHY = 100,
@@ -200,6 +207,7 @@ enum ad9910_channel {
AD9910_CHANNEL_PROFILE_5 = 115,
AD9910_CHANNEL_PROFILE_6 = 116,
AD9910_CHANNEL_PROFILE_7 = 117,
+ AD9910_CHANNEL_PARALLEL_PORT = 120,
};
enum {
@@ -212,10 +220,15 @@ enum {
AD9910_CHAN_IDX_PROFILE_5,
AD9910_CHAN_IDX_PROFILE_6,
AD9910_CHAN_IDX_PROFILE_7,
+ AD9910_CHAN_IDX_PARALLEL_PORT,
};
enum {
AD9910_POWERDOWN,
+ AD9910_PP_FREQ_SCALE,
+ AD9910_PP_FREQ_OFFSET,
+ AD9910_PP_PHASE_OFFSET,
+ AD9910_PP_AMP_OFFSET,
};
struct ad9910_data {
@@ -482,6 +495,10 @@ static ssize_t ad9910_ext_info_read(struct iio_dev *indio_dev,
case AD9910_POWERDOWN:
val = ad9910_sw_powerdown_get(st);
break;
+ case AD9910_PP_FREQ_SCALE:
+ val = BIT(FIELD_GET(AD9910_CFR2_FM_GAIN_MSK,
+ st->reg[AD9910_REG_CFR2].val32));
+ break;
default:
return -EINVAL;
}
@@ -510,6 +527,115 @@ static ssize_t ad9910_ext_info_write(struct iio_dev *indio_dev,
if (ret)
return ret;
break;
+ case AD9910_PP_FREQ_SCALE:
+ if (val32 > BIT(15) || !is_power_of_2(val32))
+ return -EINVAL;
+
+ val32 = FIELD_PREP(AD9910_CFR2_FM_GAIN_MSK, ilog2(val32));
+ ret = ad9910_reg32_update(st, AD9910_REG_CFR2,
+ AD9910_CFR2_FM_GAIN_MSK,
+ val32, true);
+ if (ret)
+ return ret;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return len;
+}
+
+static ssize_t ad9910_pp_attrs_read(struct iio_dev *indio_dev,
+ uintptr_t private,
+ const struct iio_chan_spec *chan,
+ char *buf)
+{
+ struct ad9910_state *st = iio_priv(indio_dev);
+ int vals[2];
+ u32 tmp32;
+ u64 tmp64;
+
+ guard(mutex)(&st->lock);
+
+ switch (private) {
+ case AD9910_PP_FREQ_OFFSET:
+ tmp64 = (u64)st->reg[AD9910_REG_FTW].val32 * st->data.sysclk_freq_hz;
+ vals[0] = tmp64 >> 32;
+ vals[1] = ((tmp64 & GENMASK_ULL(31, 0)) * MICRO) >> 32;
+ break;
+ case AD9910_PP_PHASE_OFFSET:
+ tmp32 = FIELD_GET(AD9910_POW_PP_LSB_MSK,
+ st->reg[AD9910_REG_POW].val16);
+ tmp32 = ((u64)tmp32 * AD9910_MAX_PHASE_MICRORAD) >> 16;
+ vals[0] = tmp32 / MICRO;
+ vals[1] = tmp32 % MICRO;
+ break;
+ case AD9910_PP_AMP_OFFSET:
+ tmp32 = FIELD_GET(AD9910_ASF_SCALE_FACTOR_PP_LSB_MSK,
+ st->reg[AD9910_REG_ASF].val32);
+ vals[0] = 0;
+ vals[1] = (u64)tmp32 * MICRO >> 14;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return iio_format_value(buf, IIO_VAL_INT_PLUS_MICRO, ARRAY_SIZE(vals), vals);
+}
+
+static ssize_t ad9910_pp_attrs_write(struct iio_dev *indio_dev,
+ uintptr_t private,
+ const struct iio_chan_spec *chan,
+ const char *buf, size_t len)
+{
+ struct ad9910_state *st = iio_priv(indio_dev);
+ int val, val2;
+ u32 tmp32;
+ int ret;
+
+ ret = iio_str_to_fixpoint(buf, MICRO / 10, &val, &val2);
+ if (ret)
+ return ret;
+
+ guard(mutex)(&st->lock);
+
+ switch (private) {
+ case AD9910_PP_FREQ_OFFSET:
+ if (val < 0 || val2 < 0 || val >= st->data.sysclk_freq_hz / 2)
+ return -EINVAL;
+
+ tmp32 = ad9910_rational_scale((u64)val * MICRO + val2, BIT_ULL(32),
+ (u64)MICRO * st->data.sysclk_freq_hz);
+ ret = ad9910_reg32_write(st, AD9910_REG_FTW, tmp32, true);
+ if (ret)
+ return ret;
+ break;
+ case AD9910_PP_PHASE_OFFSET:
+ if (val != 0 || val2 < 0 || val2 >= (AD9910_MAX_PHASE_MICRORAD >> 8))
+ return -EINVAL;
+
+ tmp32 = DIV_ROUND_CLOSEST((u32)val2 << 16, AD9910_MAX_PHASE_MICRORAD);
+ tmp32 = min(tmp32, AD9910_POW_PP_LSB_MAX);
+ tmp32 = FIELD_PREP(AD9910_POW_PP_LSB_MSK, tmp32);
+ ret = ad9910_reg16_update(st, AD9910_REG_POW,
+ AD9910_POW_PP_LSB_MSK,
+ tmp32, true);
+ if (ret)
+ return ret;
+ break;
+ case AD9910_PP_AMP_OFFSET:
+ if (val != 0 || val2 < 0 || val2 >= (MICRO >> 8))
+ return -EINVAL;
+
+ tmp32 = DIV_ROUND_CLOSEST((u32)val2 << 14, MICRO);
+ tmp32 = min(tmp32, AD9910_ASF_PP_LSB_MAX);
+ tmp32 = FIELD_PREP(AD9910_ASF_SCALE_FACTOR_PP_LSB_MSK, tmp32);
+ ret = ad9910_reg32_update(st, AD9910_REG_ASF,
+ AD9910_ASF_SCALE_FACTOR_PP_LSB_MSK,
+ tmp32, true);
+ if (ret)
+ return ret;
+ break;
default:
return -EINVAL;
}
@@ -528,11 +654,22 @@ static ssize_t ad9910_ext_info_write(struct iio_dev *indio_dev,
#define AD9910_EXT_INFO(_name, _ident, _shared) \
AD9910_EXT_INFO_TMPL(_name, _ident, _shared, ext_info)
+#define AD9910_PP_EXT_INFO(_name, _ident) \
+ AD9910_EXT_INFO_TMPL(_name, _ident, IIO_SEPARATE, pp_attrs)
+
static const struct iio_chan_spec_ext_info ad9910_phy_ext_info[] = {
AD9910_EXT_INFO("powerdown", AD9910_POWERDOWN, IIO_SEPARATE),
{ }
};
+static const struct iio_chan_spec_ext_info ad9910_pp_ext_info[] = {
+ AD9910_EXT_INFO("frequency_scale", AD9910_PP_FREQ_SCALE, IIO_SEPARATE),
+ AD9910_PP_EXT_INFO("frequency_offset", AD9910_PP_FREQ_OFFSET),
+ AD9910_PP_EXT_INFO("phase_offset", AD9910_PP_PHASE_OFFSET),
+ AD9910_PP_EXT_INFO("scale_offset", AD9910_PP_AMP_OFFSET),
+ { }
+};
+
#define AD9910_PROFILE_CHAN(idx) { \
.type = IIO_ALTVOLTAGE, \
.indexed = 1, \
@@ -564,6 +701,15 @@ static const struct iio_chan_spec ad9910_channels[] = {
[AD9910_CHAN_IDX_PROFILE_5] = AD9910_PROFILE_CHAN(5),
[AD9910_CHAN_IDX_PROFILE_6] = AD9910_PROFILE_CHAN(6),
[AD9910_CHAN_IDX_PROFILE_7] = AD9910_PROFILE_CHAN(7),
+ [AD9910_CHAN_IDX_PARALLEL_PORT] = {
+ .type = IIO_ALTVOLTAGE,
+ .indexed = 1,
+ .output = 1,
+ .channel = AD9910_CHANNEL_PARALLEL_PORT,
+ .address = AD9910_CHAN_IDX_PARALLEL_PORT,
+ .ext_info = ad9910_pp_ext_info,
+ .parent = &ad9910_channels[AD9910_CHAN_IDX_PHY],
+ },
};
static int ad9910_read_raw(struct iio_dev *indio_dev,
@@ -816,6 +962,7 @@ static const char * const ad9910_channel_str[] = {
[AD9910_CHAN_IDX_PROFILE_5] = "profile5",
[AD9910_CHAN_IDX_PROFILE_6] = "profile6",
[AD9910_CHAN_IDX_PROFILE_7] = "profile7",
+ [AD9910_CHAN_IDX_PARALLEL_PORT] = "parallel_port",
};
static int ad9910_read_label(struct iio_dev *indio_dev,
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v5 08/13] iio: frequency: ad9910: add digital ramp generator support
2026-05-17 18:37 [PATCH v5 00/13] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
` (6 preceding siblings ...)
2026-05-17 18:37 ` [PATCH v5 07/13] iio: frequency: ad9910: add basic parallel port support Rodrigo Alencar via B4 Relay
@ 2026-05-17 18:37 ` Rodrigo Alencar via B4 Relay
2026-05-17 18:37 ` [PATCH v5 09/13] iio: frequency: ad9910: add RAM mode support Rodrigo Alencar via B4 Relay
` (4 subsequent siblings)
12 siblings, 0 replies; 28+ messages in thread
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add Digital Ramp Generator channels with destination selection (frequency,
phase, or amplitude) based on attribute writes, dwell mode control,
configurable upper/lower limits, step size controlled with rate of change
config, and step rate controlled as sampling frequency.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
drivers/iio/frequency/ad9910.c | 515 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 513 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
index d2f40927b9be..4ad80475139d 100644
--- a/drivers/iio/frequency/ad9910.c
+++ b/drivers/iio/frequency/ad9910.c
@@ -130,6 +130,18 @@
#define AD9910_MC_SYNC_OUTPUT_DELAY_MSK GENMASK(15, 11)
#define AD9910_MC_SYNC_INPUT_DELAY_MSK GENMASK(7, 3)
+/* Digital Ramp Limit Register */
+#define AD9910_DRG_LIMIT_UPPER_MSK GENMASK_ULL(63, 32)
+#define AD9910_DRG_LIMIT_LOWER_MSK GENMASK_ULL(31, 0)
+
+/* Digital Ramp Step Register */
+#define AD9910_DRG_STEP_DEC_MSK GENMASK_ULL(63, 32)
+#define AD9910_DRG_STEP_INC_MSK GENMASK_ULL(31, 0)
+
+/* Digital Ramp Rate Register */
+#define AD9910_DRG_RATE_DEC_MSK GENMASK(31, 16)
+#define AD9910_DRG_RATE_INC_MSK GENMASK(15, 0)
+
/* Profile Register Format (Single Tone Mode) */
#define AD9910_PROFILE_ST_ASF_MSK GENMASK_ULL(61, 48)
#define AD9910_PROFILE_ST_POW_MSK GENMASK_ULL(47, 32)
@@ -145,6 +157,7 @@
#define AD9910_ASF_PP_LSB_MAX GENMASK(5, 0)
#define AD9910_POW_MAX GENMASK(15, 0)
#define AD9910_POW_PP_LSB_MAX GENMASK(7, 0)
+#define AD9910_STEP_RATE_MAX GENMASK(15, 0)
#define AD9910_NUM_PROFILES 8
/* PLL constants */
@@ -196,6 +209,9 @@
* @AD9910_CHANNEL_PROFILE_6: Profile 6 output channel
* @AD9910_CHANNEL_PROFILE_7: Profile 7 output channel
* @AD9910_CHANNEL_PARALLEL_PORT: Parallel Port output channel
+ * @AD9910_CHANNEL_DRG: Digital Ramp Generator output channel
+ * @AD9910_CHANNEL_DRG_RAMP_UP: DRG ramp up channel
+ * @AD9910_CHANNEL_DRG_RAMP_DOWN: DRG ramp down channel
*/
enum ad9910_channel {
AD9910_CHANNEL_PHY = 100,
@@ -208,6 +224,24 @@ enum ad9910_channel {
AD9910_CHANNEL_PROFILE_6 = 116,
AD9910_CHANNEL_PROFILE_7 = 117,
AD9910_CHANNEL_PARALLEL_PORT = 120,
+ AD9910_CHANNEL_DRG = 130,
+ AD9910_CHANNEL_DRG_RAMP_UP = 131,
+ AD9910_CHANNEL_DRG_RAMP_DOWN = 132,
+};
+
+/**
+ * enum ad9910_destination - AD9910 DDS core parameter destination
+ *
+ * @AD9910_DEST_FREQUENCY: Frequency destination
+ * @AD9910_DEST_PHASE: Phase destination
+ * @AD9910_DEST_AMPLITUDE: Amplitude destination
+ * @AD9910_DEST_POLAR: Polar destination
+ */
+enum ad9910_destination {
+ AD9910_DEST_FREQUENCY,
+ AD9910_DEST_PHASE,
+ AD9910_DEST_AMPLITUDE,
+ AD9910_DEST_POLAR,
};
enum {
@@ -221,6 +255,9 @@ enum {
AD9910_CHAN_IDX_PROFILE_6,
AD9910_CHAN_IDX_PROFILE_7,
AD9910_CHAN_IDX_PARALLEL_PORT,
+ AD9910_CHAN_IDX_DRG,
+ AD9910_CHAN_IDX_DRG_RAMP_UP,
+ AD9910_CHAN_IDX_DRG_RAMP_DOWN,
};
enum {
@@ -229,6 +266,10 @@ enum {
AD9910_PP_FREQ_OFFSET,
AD9910_PP_PHASE_OFFSET,
AD9910_PP_AMP_OFFSET,
+ AD9910_DRG_FREQ_ROC,
+ AD9910_DRG_PHASE_ROC,
+ AD9910_DRG_AMP_ROC,
+ AD9910_DRG_DWELL_EN,
};
struct ad9910_data {
@@ -481,6 +522,26 @@ static int ad9910_sw_powerdown_set(struct ad9910_state *st, bool enable)
true);
}
+static inline int ad9910_drg_destination_set(struct ad9910_state *st,
+ enum ad9910_destination dest,
+ bool update)
+{
+ return ad9910_reg32_update(st, AD9910_REG_CFR2,
+ AD9910_CFR2_DRG_DEST_MSK,
+ FIELD_PREP(AD9910_CFR2_DRG_DEST_MSK, dest),
+ update);
+}
+
+static inline int ad9910_drg_destination_assert(struct ad9910_state *st,
+ enum ad9910_destination dest)
+{
+ enum ad9910_destination drg_dest;
+
+ drg_dest = (enum ad9910_destination)FIELD_GET(AD9910_CFR2_DRG_DEST_MSK,
+ st->reg[AD9910_REG_CFR2].val32);
+ return drg_dest == dest ? 0 : -EBUSY;
+}
+
static ssize_t ad9910_ext_info_read(struct iio_dev *indio_dev,
uintptr_t private,
const struct iio_chan_spec *chan,
@@ -499,6 +560,14 @@ static ssize_t ad9910_ext_info_read(struct iio_dev *indio_dev,
val = BIT(FIELD_GET(AD9910_CFR2_FM_GAIN_MSK,
st->reg[AD9910_REG_CFR2].val32));
break;
+ case AD9910_DRG_DWELL_EN:
+ if (chan->channel == AD9910_CHANNEL_DRG_RAMP_UP)
+ val = FIELD_GET(AD9910_CFR2_DRG_NO_DWELL_HIGH_MSK,
+ st->reg[AD9910_REG_CFR2].val32) ? 0 : 1;
+ else
+ val = FIELD_GET(AD9910_CFR2_DRG_NO_DWELL_LOW_MSK,
+ st->reg[AD9910_REG_CFR2].val32) ? 0 : 1;
+ break;
default:
return -EINVAL;
}
@@ -538,6 +607,23 @@ static ssize_t ad9910_ext_info_write(struct iio_dev *indio_dev,
if (ret)
return ret;
break;
+ case AD9910_DRG_DWELL_EN:
+ if (chan->channel == AD9910_CHANNEL_DRG_RAMP_UP) {
+ val32 = val32 ? 0 : AD9910_CFR2_DRG_NO_DWELL_HIGH_MSK;
+ ret = ad9910_reg32_update(st, AD9910_REG_CFR2,
+ AD9910_CFR2_DRG_NO_DWELL_HIGH_MSK,
+ val32, true);
+ if (ret)
+ return ret;
+ } else {
+ val32 = val32 ? 0 : AD9910_CFR2_DRG_NO_DWELL_LOW_MSK;
+ ret = ad9910_reg32_update(st, AD9910_REG_CFR2,
+ AD9910_CFR2_DRG_NO_DWELL_LOW_MSK,
+ val32, true);
+ if (ret)
+ return ret;
+ }
+ break;
default:
return -EINVAL;
}
@@ -643,6 +729,179 @@ static ssize_t ad9910_pp_attrs_write(struct iio_dev *indio_dev,
return len;
}
+static ssize_t ad9910_drg_attrs_read(struct iio_dev *indio_dev,
+ uintptr_t private,
+ const struct iio_chan_spec *chan,
+ char *buf)
+{
+ struct ad9910_state *st = iio_priv(indio_dev);
+ unsigned int type;
+ int ret, vals[2];
+ u64 roc64;
+ u32 rate;
+
+ guard(mutex)(&st->lock);
+
+ switch (chan->channel) {
+ case AD9910_CHANNEL_DRG_RAMP_UP:
+ roc64 = FIELD_GET(AD9910_DRG_STEP_INC_MSK,
+ st->reg[AD9910_REG_DRG_STEP].val64);
+ rate = FIELD_GET(AD9910_DRG_RATE_INC_MSK,
+ st->reg[AD9910_REG_DRG_RATE].val32);
+ break;
+ case AD9910_CHANNEL_DRG_RAMP_DOWN:
+ roc64 = FIELD_GET(AD9910_DRG_STEP_DEC_MSK,
+ st->reg[AD9910_REG_DRG_STEP].val64);
+ rate = FIELD_GET(AD9910_DRG_RATE_DEC_MSK,
+ st->reg[AD9910_REG_DRG_RATE].val32);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (!rate)
+ return -ERANGE;
+
+ roc64 *= st->data.sysclk_freq_hz;
+ rate *= 4;
+
+ switch (private) {
+ case AD9910_DRG_FREQ_ROC:
+ ret = ad9910_drg_destination_assert(st, AD9910_DEST_FREQUENCY);
+ if (ret)
+ return ret;
+
+ type = IIO_VAL_INT_64;
+ roc64 = ad9910_rational_scale(roc64, st->data.sysclk_freq_hz,
+ BIT_ULL(32) * rate);
+ vals[0] = (u32)roc64;
+ vals[1] = (u32)(roc64 >> 32);
+ break;
+ case AD9910_DRG_PHASE_ROC:
+ ret = ad9910_drg_destination_assert(st, AD9910_DEST_PHASE);
+ if (ret)
+ return ret;
+
+ type = IIO_VAL_INT_PLUS_NANO;
+ roc64 = ad9910_rational_scale(roc64, AD9910_PI_NANORAD,
+ BIT_ULL(31) * rate);
+ vals[0] = div_s64_rem(roc64, NANO, &vals[1]);
+ break;
+ case AD9910_DRG_AMP_ROC:
+ ret = ad9910_drg_destination_assert(st, AD9910_DEST_AMPLITUDE);
+ if (ret)
+ return ret;
+
+ type = IIO_VAL_INT_PLUS_NANO;
+ roc64 = ad9910_rational_scale(roc64, NANO, BIT_ULL(32) * rate);
+ vals[0] = div_s64_rem(roc64, NANO, &vals[1]);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return iio_format_value(buf, type, ARRAY_SIZE(vals), vals);
+}
+
+static ssize_t ad9910_drg_attrs_write(struct iio_dev *indio_dev,
+ uintptr_t private,
+ const struct iio_chan_spec *chan,
+ const char *buf, size_t len)
+{
+ struct ad9910_state *st = iio_priv(indio_dev);
+ enum ad9910_destination dest;
+ int val, val2;
+ u64 tmp64;
+ u32 rate;
+ int ret;
+
+ guard(mutex)(&st->lock);
+
+ switch (chan->channel) {
+ case AD9910_CHANNEL_DRG_RAMP_UP:
+ rate = FIELD_GET(AD9910_DRG_RATE_INC_MSK,
+ st->reg[AD9910_REG_DRG_RATE].val32);
+ break;
+ case AD9910_CHANNEL_DRG_RAMP_DOWN:
+ rate = FIELD_GET(AD9910_DRG_RATE_DEC_MSK,
+ st->reg[AD9910_REG_DRG_RATE].val32);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (!rate)
+ return -ERANGE;
+
+ rate *= 4;
+
+ switch (private) {
+ case AD9910_DRG_FREQ_ROC:
+ ret = kstrtou64(buf, 10, &tmp64);
+ if (ret)
+ return ret;
+
+ tmp64 = ad9910_rational_scale(tmp64, BIT_ULL(32) * rate,
+ (u64)st->data.sysclk_freq_hz *
+ st->data.sysclk_freq_hz);
+ dest = AD9910_DEST_FREQUENCY;
+ break;
+ case AD9910_DRG_PHASE_ROC:
+ ret = iio_str_to_fixpoint(buf, NANO / 10, &val, &val2);
+ if (ret)
+ return ret;
+
+ if (val < 0 || val2 < 0)
+ return -EINVAL;
+
+ tmp64 = (u64)val * NANO + val2;
+ tmp64 = ad9910_rational_scale(tmp64, BIT_ULL(31) * rate,
+ (u64)AD9910_PI_NANORAD *
+ st->data.sysclk_freq_hz);
+ dest = AD9910_DEST_PHASE;
+ break;
+ case AD9910_DRG_AMP_ROC:
+ ret = iio_str_to_fixpoint(buf, NANO / 10, &val, &val2);
+ if (ret)
+ return ret;
+
+ if (val < 0 || val2 < 0)
+ return -EINVAL;
+
+ tmp64 = (u64)val * NANO + val2;
+ tmp64 = ad9910_rational_scale(tmp64, BIT_ULL(32) * rate,
+ (u64)NANO * st->data.sysclk_freq_hz);
+ dest = AD9910_DEST_AMPLITUDE;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ ret = ad9910_drg_destination_set(st, dest, false);
+ if (ret)
+ return ret;
+
+ tmp64 = min(tmp64, U32_MAX);
+
+ if (chan->channel == AD9910_CHANNEL_DRG_RAMP_UP) {
+ ret = ad9910_reg64_update(st, AD9910_REG_DRG_STEP,
+ AD9910_DRG_STEP_INC_MSK,
+ FIELD_PREP(AD9910_DRG_STEP_INC_MSK, tmp64),
+ true);
+ if (ret)
+ return ret;
+ } else {
+ ret = ad9910_reg64_update(st, AD9910_REG_DRG_STEP,
+ AD9910_DRG_STEP_DEC_MSK,
+ FIELD_PREP(AD9910_DRG_STEP_DEC_MSK, tmp64),
+ true);
+ if (ret)
+ return ret;
+ }
+
+ return len;
+}
+
#define AD9910_EXT_INFO_TMPL(_name, _ident, _shared, _fn_desc) { \
.name = _name, \
.read = ad9910_ ## _fn_desc ## _read, \
@@ -657,6 +916,9 @@ static ssize_t ad9910_pp_attrs_write(struct iio_dev *indio_dev,
#define AD9910_PP_EXT_INFO(_name, _ident) \
AD9910_EXT_INFO_TMPL(_name, _ident, IIO_SEPARATE, pp_attrs)
+#define AD9910_DRG_EXT_INFO(_name, _ident) \
+ AD9910_EXT_INFO_TMPL(_name, _ident, IIO_SEPARATE, drg_attrs)
+
static const struct iio_chan_spec_ext_info ad9910_phy_ext_info[] = {
AD9910_EXT_INFO("powerdown", AD9910_POWERDOWN, IIO_SEPARATE),
{ }
@@ -670,6 +932,14 @@ static const struct iio_chan_spec_ext_info ad9910_pp_ext_info[] = {
{ }
};
+static const struct iio_chan_spec_ext_info ad9910_drg_ramp_ext_info[] = {
+ AD9910_EXT_INFO("dwell_en", AD9910_DRG_DWELL_EN, IIO_SEPARATE),
+ AD9910_DRG_EXT_INFO("frequency_roc", AD9910_DRG_FREQ_ROC),
+ AD9910_DRG_EXT_INFO("phase_roc", AD9910_DRG_PHASE_ROC),
+ AD9910_DRG_EXT_INFO("scale_roc", AD9910_DRG_AMP_ROC),
+ { }
+};
+
#define AD9910_PROFILE_CHAN(idx) { \
.type = IIO_ALTVOLTAGE, \
.indexed = 1, \
@@ -710,6 +980,41 @@ static const struct iio_chan_spec ad9910_channels[] = {
.ext_info = ad9910_pp_ext_info,
.parent = &ad9910_channels[AD9910_CHAN_IDX_PHY],
},
+ [AD9910_CHAN_IDX_DRG] = {
+ .type = IIO_ALTVOLTAGE,
+ .indexed = 1,
+ .output = 1,
+ .channel = AD9910_CHANNEL_DRG,
+ .address = AD9910_CHAN_IDX_DRG,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_ENABLE),
+ .parent = &ad9910_channels[AD9910_CHAN_IDX_PHY],
+ },
+ [AD9910_CHAN_IDX_DRG_RAMP_UP] = {
+ .type = IIO_ALTVOLTAGE,
+ .indexed = 1,
+ .output = 1,
+ .channel = AD9910_CHANNEL_DRG_RAMP_UP,
+ .address = AD9910_CHAN_IDX_DRG_RAMP_UP,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_FREQUENCY) |
+ BIT(IIO_CHAN_INFO_PHASE) |
+ BIT(IIO_CHAN_INFO_SCALE) |
+ BIT(IIO_CHAN_INFO_SAMP_FREQ),
+ .ext_info = ad9910_drg_ramp_ext_info,
+ .parent = &ad9910_channels[AD9910_CHAN_IDX_DRG],
+ },
+ [AD9910_CHAN_IDX_DRG_RAMP_DOWN] = {
+ .type = IIO_ALTVOLTAGE,
+ .indexed = 1,
+ .output = 1,
+ .channel = AD9910_CHANNEL_DRG_RAMP_DOWN,
+ .address = AD9910_CHAN_IDX_DRG_RAMP_DOWN,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_FREQUENCY) |
+ BIT(IIO_CHAN_INFO_PHASE) |
+ BIT(IIO_CHAN_INFO_SCALE) |
+ BIT(IIO_CHAN_INFO_SAMP_FREQ),
+ .ext_info = ad9910_drg_ramp_ext_info,
+ .parent = &ad9910_channels[AD9910_CHAN_IDX_DRG],
+ },
};
static int ad9910_read_raw(struct iio_dev *indio_dev,
@@ -719,6 +1024,7 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
struct ad9910_state *st = iio_priv(indio_dev);
u64 tmp64;
u32 tmp32;
+ int ret;
guard(mutex)(&st->lock);
@@ -733,6 +1039,10 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
*val = (tmp32 == st->profile);
}
break;
+ case AD9910_CHANNEL_DRG:
+ *val = FIELD_GET(AD9910_CFR2_DRG_ENABLE_MSK,
+ st->reg[AD9910_REG_CFR2].val32);
+ break;
default:
return -EINVAL;
}
@@ -744,6 +1054,22 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
tmp64 = FIELD_GET(AD9910_PROFILE_ST_FTW_MSK,
st->reg[AD9910_REG_PROFILE(tmp32)].val64);
break;
+ case AD9910_CHANNEL_DRG_RAMP_UP:
+ ret = ad9910_drg_destination_assert(st, AD9910_DEST_FREQUENCY);
+ if (ret)
+ return ret;
+
+ tmp64 = FIELD_GET(AD9910_DRG_LIMIT_UPPER_MSK,
+ st->reg[AD9910_REG_DRG_LIMIT].val64);
+ break;
+ case AD9910_CHANNEL_DRG_RAMP_DOWN:
+ ret = ad9910_drg_destination_assert(st, AD9910_DEST_FREQUENCY);
+ if (ret)
+ return ret;
+
+ tmp64 = FIELD_GET(AD9910_DRG_LIMIT_LOWER_MSK,
+ st->reg[AD9910_REG_DRG_LIMIT].val64);
+ break;
default:
return -EINVAL;
}
@@ -761,6 +1087,26 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
*val = tmp32 / MICRO;
*val2 = tmp32 % MICRO;
return IIO_VAL_INT_PLUS_MICRO;
+ case AD9910_CHANNEL_DRG_RAMP_UP:
+ ret = ad9910_drg_destination_assert(st, AD9910_DEST_PHASE);
+ if (ret)
+ return ret;
+
+ tmp64 = FIELD_GET(AD9910_DRG_LIMIT_UPPER_MSK,
+ st->reg[AD9910_REG_DRG_LIMIT].val64);
+ tmp64 = (tmp64 * AD9910_PI_NANORAD) >> 31;
+ *val = div_s64_rem(tmp64, NANO, val2);
+ return IIO_VAL_INT_PLUS_NANO;
+ case AD9910_CHANNEL_DRG_RAMP_DOWN:
+ ret = ad9910_drg_destination_assert(st, AD9910_DEST_PHASE);
+ if (ret)
+ return ret;
+
+ tmp64 = FIELD_GET(AD9910_DRG_LIMIT_LOWER_MSK,
+ st->reg[AD9910_REG_DRG_LIMIT].val64);
+ tmp64 = (tmp64 * AD9910_PI_NANORAD) >> 31;
+ *val = div_s64_rem(tmp64, NANO, val2);
+ return IIO_VAL_INT_PLUS_NANO;
default:
return -EINVAL;
}
@@ -773,6 +1119,26 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
*val = 0;
*val2 = tmp64 * MICRO >> 14;
return IIO_VAL_INT_PLUS_MICRO;
+ case AD9910_CHANNEL_DRG_RAMP_UP:
+ ret = ad9910_drg_destination_assert(st, AD9910_DEST_AMPLITUDE);
+ if (ret)
+ return ret;
+
+ tmp64 = FIELD_GET(AD9910_DRG_LIMIT_UPPER_MSK,
+ st->reg[AD9910_REG_DRG_LIMIT].val64);
+ *val = 0;
+ *val2 = tmp64 * NANO >> 32;
+ return IIO_VAL_INT_PLUS_NANO;
+ case AD9910_CHANNEL_DRG_RAMP_DOWN:
+ ret = ad9910_drg_destination_assert(st, AD9910_DEST_AMPLITUDE);
+ if (ret)
+ return ret;
+
+ tmp64 = FIELD_GET(AD9910_DRG_LIMIT_LOWER_MSK,
+ st->reg[AD9910_REG_DRG_LIMIT].val64);
+ *val = 0;
+ *val2 = tmp64 * NANO >> 32;
+ return IIO_VAL_INT_PLUS_NANO;
default:
return -EINVAL;
}
@@ -781,9 +1147,23 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
case AD9910_CHANNEL_PHY:
*val = st->data.sysclk_freq_hz;
return IIO_VAL_INT;
+ case AD9910_CHANNEL_DRG_RAMP_UP:
+ tmp32 = FIELD_GET(AD9910_DRG_RATE_INC_MSK,
+ st->reg[AD9910_REG_DRG_RATE].val32);
+ break;
+ case AD9910_CHANNEL_DRG_RAMP_DOWN:
+ tmp32 = FIELD_GET(AD9910_DRG_RATE_DEC_MSK,
+ st->reg[AD9910_REG_DRG_RATE].val32);
+ break;
default:
return -EINVAL;
}
+ if (!tmp32)
+ return -ERANGE;
+ tmp32 *= 4;
+ *val = st->data.sysclk_freq_hz / tmp32;
+ *val2 = div_u64((u64)(st->data.sysclk_freq_hz % tmp32) * MICRO, tmp32);
+ return IIO_VAL_INT_PLUS_MICRO;
default:
return -EINVAL;
}
@@ -817,6 +1197,11 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
return ret;
return ad9910_profile_set(st, tmp32);
+ case AD9910_CHANNEL_DRG:
+ tmp32 = FIELD_PREP(AD9910_CFR2_DRG_ENABLE_MSK, !!val);
+ return ad9910_reg32_update(st, AD9910_REG_CFR2,
+ AD9910_CFR2_DRG_ENABLE_MSK,
+ tmp32, true);
default:
return -EINVAL;
}
@@ -834,6 +1219,28 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
return ad9910_reg64_update(st, AD9910_REG_PROFILE(tmp32),
AD9910_PROFILE_ST_FTW_MSK,
tmp64, true);
+ case AD9910_CHANNEL_DRG_RAMP_UP:
+ ret = ad9910_drg_destination_set(st,
+ AD9910_DEST_FREQUENCY,
+ false);
+ if (ret)
+ return ret;
+
+ tmp64 = FIELD_PREP(AD9910_DRG_LIMIT_UPPER_MSK, tmp64);
+ return ad9910_reg64_update(st, AD9910_REG_DRG_LIMIT,
+ AD9910_DRG_LIMIT_UPPER_MSK,
+ tmp64, true);
+ case AD9910_CHANNEL_DRG_RAMP_DOWN:
+ ret = ad9910_drg_destination_set(st,
+ AD9910_DEST_FREQUENCY,
+ false);
+ if (ret)
+ return ret;
+
+ tmp64 = FIELD_PREP(AD9910_DRG_LIMIT_LOWER_MSK, tmp64);
+ return ad9910_reg64_update(st, AD9910_REG_DRG_LIMIT,
+ AD9910_DRG_LIMIT_LOWER_MSK,
+ tmp64, true);
default:
return -EINVAL;
}
@@ -855,6 +1262,40 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
return ad9910_reg64_update(st, AD9910_REG_PROFILE(tmp32),
AD9910_PROFILE_ST_POW_MSK,
tmp64, true);
+ case AD9910_CHANNEL_DRG_RAMP_UP:
+ tmp64 = (u64)val * NANO + val2;
+ if (tmp64 > 2ULL * AD9910_PI_NANORAD)
+ return -EINVAL;
+
+ ret = ad9910_drg_destination_set(st, AD9910_DEST_PHASE,
+ false);
+ if (ret)
+ return ret;
+
+ tmp64 <<= 31;
+ tmp64 = DIV_U64_ROUND_CLOSEST(tmp64, AD9910_PI_NANORAD);
+ tmp64 = min(tmp64, U32_MAX);
+ tmp64 = FIELD_PREP(AD9910_DRG_LIMIT_UPPER_MSK, tmp64);
+ return ad9910_reg64_update(st, AD9910_REG_DRG_LIMIT,
+ AD9910_DRG_LIMIT_UPPER_MSK,
+ tmp64, true);
+ case AD9910_CHANNEL_DRG_RAMP_DOWN:
+ tmp64 = (u64)val * NANO + val2;
+ if (tmp64 > 2ULL * AD9910_PI_NANORAD)
+ return -EINVAL;
+
+ ret = ad9910_drg_destination_set(st, AD9910_DEST_PHASE,
+ false);
+ if (ret)
+ return ret;
+
+ tmp64 <<= 31;
+ tmp64 = DIV_U64_ROUND_CLOSEST(tmp64, AD9910_PI_NANORAD);
+ tmp64 = min(tmp64, U32_MAX);
+ tmp64 = FIELD_PREP(AD9910_DRG_LIMIT_LOWER_MSK, tmp64);
+ return ad9910_reg64_update(st, AD9910_REG_DRG_LIMIT,
+ AD9910_DRG_LIMIT_LOWER_MSK,
+ tmp64, true);
default:
return -EINVAL;
}
@@ -872,11 +1313,65 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
return ad9910_reg64_update(st, AD9910_REG_PROFILE(tmp32),
AD9910_PROFILE_ST_ASF_MSK,
tmp64, true);
+ case AD9910_CHANNEL_DRG_RAMP_UP:
+ ret = ad9910_drg_destination_set(st,
+ AD9910_DEST_AMPLITUDE,
+ false);
+ if (ret)
+ return ret;
+
+ tmp64 = ((u64)val * NANO + val2) << 32;
+ tmp64 = DIV_U64_ROUND_CLOSEST(tmp64, NANO);
+ tmp64 = min(tmp64, U32_MAX);
+ tmp64 = FIELD_PREP(AD9910_DRG_LIMIT_UPPER_MSK, tmp64);
+ return ad9910_reg64_update(st, AD9910_REG_DRG_LIMIT,
+ AD9910_DRG_LIMIT_UPPER_MSK,
+ tmp64, true);
+ case AD9910_CHANNEL_DRG_RAMP_DOWN:
+ ret = ad9910_drg_destination_set(st,
+ AD9910_DEST_AMPLITUDE,
+ false);
+ if (ret)
+ return ret;
+
+ tmp64 = ((u64)val * NANO + val2) << 32;
+ tmp64 = DIV_U64_ROUND_CLOSEST(tmp64, NANO);
+ tmp64 = min(tmp64, U32_MAX);
+ tmp64 = FIELD_PREP(AD9910_DRG_LIMIT_LOWER_MSK, tmp64);
+ return ad9910_reg64_update(st, AD9910_REG_DRG_LIMIT,
+ AD9910_DRG_LIMIT_LOWER_MSK,
+ tmp64, true);
default:
return -EINVAL;
}
case IIO_CHAN_INFO_SAMP_FREQ:
- return ad9910_set_sysclk_freq(st, val, true);
+ if (chan->channel == AD9910_CHANNEL_PHY)
+ return ad9910_set_sysclk_freq(st, val, true);
+
+ if (val < 0 || val2 < 0 || val > st->data.sysclk_freq_hz / 4)
+ return -EINVAL;
+
+ tmp64 = ((u64)val * MICRO + val2) * 4;
+ if (!tmp64)
+ return -EINVAL;
+
+ tmp64 = DIV64_U64_ROUND_CLOSEST((u64)st->data.sysclk_freq_hz * MICRO, tmp64);
+ tmp32 = clamp(tmp64, 1U, AD9910_STEP_RATE_MAX);
+
+ switch (chan->channel) {
+ case AD9910_CHANNEL_DRG_RAMP_UP:
+ tmp32 = FIELD_PREP(AD9910_DRG_RATE_INC_MSK, tmp32);
+ return ad9910_reg32_update(st, AD9910_REG_DRG_RATE,
+ AD9910_DRG_RATE_INC_MSK,
+ tmp32, true);
+ case AD9910_CHANNEL_DRG_RAMP_DOWN:
+ tmp32 = FIELD_PREP(AD9910_DRG_RATE_DEC_MSK, tmp32);
+ return ad9910_reg32_update(st, AD9910_REG_DRG_RATE,
+ AD9910_DRG_RATE_DEC_MSK,
+ tmp32, true);
+ default:
+ return -EINVAL;
+ }
default:
return -EINVAL;
}
@@ -896,11 +1391,16 @@ static int ad9910_write_raw_get_fmt(struct iio_dev *indio_dev,
switch (chan->channel) {
case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
return IIO_VAL_INT_PLUS_MICRO;
+ case AD9910_CHANNEL_DRG_RAMP_UP:
+ case AD9910_CHANNEL_DRG_RAMP_DOWN:
+ return IIO_VAL_INT_PLUS_NANO;
default:
return -EINVAL;
}
case IIO_CHAN_INFO_SAMP_FREQ:
- return IIO_VAL_INT;
+ if (chan->channel == AD9910_CHANNEL_PHY)
+ return IIO_VAL_INT;
+ return IIO_VAL_INT_PLUS_MICRO;
default:
return -EINVAL;
}
@@ -963,6 +1463,9 @@ static const char * const ad9910_channel_str[] = {
[AD9910_CHAN_IDX_PROFILE_6] = "profile6",
[AD9910_CHAN_IDX_PROFILE_7] = "profile7",
[AD9910_CHAN_IDX_PARALLEL_PORT] = "parallel_port",
+ [AD9910_CHAN_IDX_DRG] = "digital_ramp_generator",
+ [AD9910_CHAN_IDX_DRG_RAMP_UP] = "digital_ramp_up",
+ [AD9910_CHAN_IDX_DRG_RAMP_DOWN] = "digital_ramp_down",
};
static int ad9910_read_label(struct iio_dev *indio_dev,
@@ -1090,6 +1593,14 @@ static int ad9910_setup(struct device *dev, struct ad9910_state *st,
if (ret)
return ret;
+ /* configure step rate with default values */
+ ret = ad9910_reg32_write(st, AD9910_REG_DRG_RATE,
+ FIELD_PREP(AD9910_DRG_RATE_DEC_MSK, 1) |
+ FIELD_PREP(AD9910_DRG_RATE_INC_MSK, 1),
+ false);
+ if (ret)
+ return ret;
+
return ad9910_io_update(st);
}
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v5 09/13] iio: frequency: ad9910: add RAM mode support
2026-05-17 18:37 [PATCH v5 00/13] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
` (7 preceding siblings ...)
2026-05-17 18:37 ` [PATCH v5 08/13] iio: frequency: ad9910: add digital ramp generator support Rodrigo Alencar via B4 Relay
@ 2026-05-17 18:37 ` Rodrigo Alencar via B4 Relay
2026-05-18 13:50 ` Rodrigo Alencar
2026-05-17 18:37 ` [PATCH v5 10/13] iio: frequency: ad9910: add output shift keying support Rodrigo Alencar via B4 Relay
` (3 subsequent siblings)
12 siblings, 1 reply; 28+ messages in thread
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add RAM control channel, which includes:
- RAM data loading via firmware upload interface;
- Per-profile configuration and DDS core parameter destination as firmware
metadata;
- Profile switching relying on profile channels;
- Sampling frequency control of the active profile;
- ram-enable-aware read/write paths that redirect single tone
frequency/phase/amplitude access through reg_profile cache when RAM is
active;
When RAM is enabled, the DDS profile parameters (frequency, phase,
amplitude) for the single tone mode are sourced from a shadow register
cache (reg_profile[]) since the profile registers are repurposed for RAM
control.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
drivers/iio/frequency/Kconfig | 3 +
drivers/iio/frequency/ad9910.c | 356 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 353 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/frequency/Kconfig b/drivers/iio/frequency/Kconfig
index 180e74f62d11..0b058dce2a6f 100644
--- a/drivers/iio/frequency/Kconfig
+++ b/drivers/iio/frequency/Kconfig
@@ -29,6 +29,9 @@ config AD9910
tristate "Analog Devices AD9910 Direct Digital Synthesizer"
depends on SPI
depends on GPIOLIB
+ select CRC32
+ select FW_LOADER
+ select FW_UPLOAD
help
Say yes here to build support for Analog Devices AD9910
1 GSPS, 14-Bit DDS with integrated DAC.
diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
index 4ad80475139d..86ed350011cf 100644
--- a/drivers/iio/frequency/ad9910.c
+++ b/drivers/iio/frequency/ad9910.c
@@ -8,9 +8,12 @@
#include <linux/array_size.h>
#include <linux/bitfield.h>
#include <linux/clk.h>
+#include <linux/crc32.h>
+#include <linux/debugfs.h>
#include <linux/delay.h>
#include <linux/device/devres.h>
#include <linux/err.h>
+#include <linux/firmware.h>
#include <linux/gpio/consumer.h>
#include <linux/log2.h>
#include <linux/math64.h>
@@ -147,6 +150,15 @@
#define AD9910_PROFILE_ST_POW_MSK GENMASK_ULL(47, 32)
#define AD9910_PROFILE_ST_FTW_MSK GENMASK_ULL(31, 0)
+/* Profile Register Format (RAM Mode) */
+#define AD9910_PROFILE_RAM_OPEN_MSK GENMASK_ULL(61, 56)
+#define AD9910_PROFILE_RAM_STEP_RATE_MSK GENMASK_ULL(55, 40)
+#define AD9910_PROFILE_RAM_END_ADDR_MSK GENMASK_ULL(39, 30)
+#define AD9910_PROFILE_RAM_START_ADDR_MSK GENMASK_ULL(23, 14)
+#define AD9910_PROFILE_RAM_NO_DWELL_HIGH_MSK BIT_ULL(5)
+#define AD9910_PROFILE_RAM_ZERO_CROSSING_MSK BIT_ULL(3)
+#define AD9910_PROFILE_RAM_MODE_CONTROL_MSK GENMASK_ULL(2, 0)
+
/* Device constants */
#define AD9910_PI_NANORAD 3141592653UL
@@ -160,6 +172,16 @@
#define AD9910_STEP_RATE_MAX GENMASK(15, 0)
#define AD9910_NUM_PROFILES 8
+#define AD9910_RAM_FW_MAGIC 0x00AD9910
+#define AD9910_RAM_FW_V1 0x0001
+#define AD9910_RAM_SIZE_MAX_WORDS 1024
+#define AD9910_RAM_WORD_SIZE sizeof(u32)
+#define AD9910_RAM_SIZE_MAX_BYTES (AD9910_RAM_SIZE_MAX_WORDS * AD9910_RAM_WORD_SIZE)
+#define AD9910_RAM_ADDR_MAX (AD9910_RAM_SIZE_MAX_WORDS - 1)
+
+#define AD9910_RAM_ENABLED(st) \
+ FIELD_GET(AD9910_CFR1_RAM_ENABLE_MSK, (st)->reg[AD9910_REG_CFR1].val32)
+
/* PLL constants */
#define AD9910_PLL_MIN_N 12
#define AD9910_PLL_MAX_N 127
@@ -191,7 +213,7 @@
#define AD9910_REFDIV2_MAX_FREQ_HZ (1900 * HZ_PER_MHZ)
#define AD9910_SPI_DATA_IDX 1
-#define AD9910_SPI_DATA_LEN_MAX sizeof(__be64)
+#define AD9910_SPI_DATA_LEN_MAX AD9910_RAM_SIZE_MAX_BYTES
#define AD9910_SPI_MESSAGE_LEN_MAX (AD9910_SPI_DATA_IDX + AD9910_SPI_DATA_LEN_MAX)
#define AD9910_SPI_READ_MSK BIT(7)
#define AD9910_SPI_ADDR_MSK GENMASK(4, 0)
@@ -212,6 +234,7 @@
* @AD9910_CHANNEL_DRG: Digital Ramp Generator output channel
* @AD9910_CHANNEL_DRG_RAMP_UP: DRG ramp up channel
* @AD9910_CHANNEL_DRG_RAMP_DOWN: DRG ramp down channel
+ * @AD9910_CHANNEL_RAM: RAM control output channel
*/
enum ad9910_channel {
AD9910_CHANNEL_PHY = 100,
@@ -227,6 +250,7 @@ enum ad9910_channel {
AD9910_CHANNEL_DRG = 130,
AD9910_CHANNEL_DRG_RAMP_UP = 131,
AD9910_CHANNEL_DRG_RAMP_DOWN = 132,
+ AD9910_CHANNEL_RAM = 140,
};
/**
@@ -244,6 +268,29 @@ enum ad9910_destination {
AD9910_DEST_POLAR,
};
+/**
+ * struct ad9910_ram_fw - AD9910 RAM firmware format
+ * @magic: Magic number for RAM firmware validation
+ * @version: Firmware version number
+ * @wcount: Number of RAM words to be written
+ * @crc: CRC32 checksum of the RAM data for integrity verification
+ * @cfr1: Value of CFR1 register to be configured (not all fields are
+ * used, but this is included here for convenience)
+ * @profiles: Array of RAM profile configurations
+ * @words: Array of RAM words to be written. Data pattern should be set in
+ * reverse order and wcount specifies the number of words in this
+ * array
+ */
+struct ad9910_ram_fw {
+ __be32 magic;
+ __be16 version;
+ __be16 wcount;
+ __be32 crc;
+ __be32 cfr1;
+ __be64 profiles[AD9910_NUM_PROFILES];
+ __be32 words[] __counted_by_be(wcount);
+} __packed;
+
enum {
AD9910_CHAN_IDX_PHY,
AD9910_CHAN_IDX_PROFILE_0,
@@ -258,6 +305,7 @@ enum {
AD9910_CHAN_IDX_DRG,
AD9910_CHAN_IDX_DRG_RAMP_UP,
AD9910_CHAN_IDX_DRG_RAMP_DOWN,
+ AD9910_CHAN_IDX_RAM,
};
enum {
@@ -290,6 +338,7 @@ union ad9910_reg {
struct ad9910_state {
struct spi_device *spi;
struct clk *refclk;
+ struct fw_upload *ram_fwu;
struct gpio_desc *gpio_pwdown;
struct gpio_desc *gpio_update;
@@ -298,12 +347,22 @@ struct ad9910_state {
/* cached registers */
union ad9910_reg reg[AD9910_REG_NUM_CACHED];
+ /*
+ * alternate profile registers used to store RAM profile settings when
+ * RAM mode is disabled and Single Tone profile settings when RAM mode
+ * is enabled.
+ */
+ u64 reg_profile[AD9910_NUM_PROFILES];
+
/* Lock for accessing device registers and state variables */
struct mutex lock;
struct ad9910_data data;
u8 profile;
+ bool ram_fwu_cancel;
+ char ram_fwu_name[20];
+
/*
* RAM loading requires a reasonable amount of bytes, at the same time
* DMA capable SPI drivers requires the transfer buffers to live in
@@ -327,6 +386,22 @@ static inline u64 ad9910_rational_scale(u64 input, u64 scale, u64 reference)
return mul_u64_add_u64_div_u64(input, scale, reference >> 1, reference);
}
+static inline u64 ad9910_ram_profile_val(struct ad9910_state *st)
+{
+ if (AD9910_RAM_ENABLED(st))
+ return st->reg[AD9910_REG_PROFILE(st->profile)].val64;
+ else
+ return st->reg_profile[st->profile];
+}
+
+static inline u64 ad9910_st_profile_val(struct ad9910_state *st, u8 profile)
+{
+ if (AD9910_RAM_ENABLED(st))
+ return st->reg_profile[profile];
+ else
+ return st->reg[AD9910_REG_PROFILE(profile)].val64;
+}
+
static int ad9910_io_update(struct ad9910_state *st)
{
if (st->gpio_update) {
@@ -1015,6 +1090,18 @@ static const struct iio_chan_spec ad9910_channels[] = {
.ext_info = ad9910_drg_ramp_ext_info,
.parent = &ad9910_channels[AD9910_CHAN_IDX_DRG],
},
+ [AD9910_CHAN_IDX_RAM] = {
+ .type = IIO_ALTVOLTAGE,
+ .indexed = 1,
+ .output = 1,
+ .channel = AD9910_CHANNEL_RAM,
+ .address = AD9910_CHAN_IDX_RAM,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_ENABLE) |
+ BIT(IIO_CHAN_INFO_FREQUENCY) |
+ BIT(IIO_CHAN_INFO_PHASE) |
+ BIT(IIO_CHAN_INFO_SAMP_FREQ),
+ .parent = &ad9910_channels[AD9910_CHAN_IDX_PHY],
+ },
};
static int ad9910_read_raw(struct iio_dev *indio_dev,
@@ -1043,6 +1130,10 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
*val = FIELD_GET(AD9910_CFR2_DRG_ENABLE_MSK,
st->reg[AD9910_REG_CFR2].val32);
break;
+ case AD9910_CHANNEL_RAM:
+ *val = FIELD_GET(AD9910_CFR1_RAM_ENABLE_MSK,
+ st->reg[AD9910_REG_CFR1].val32);
+ break;
default:
return -EINVAL;
}
@@ -1052,7 +1143,7 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
tmp64 = FIELD_GET(AD9910_PROFILE_ST_FTW_MSK,
- st->reg[AD9910_REG_PROFILE(tmp32)].val64);
+ ad9910_st_profile_val(st, tmp32));
break;
case AD9910_CHANNEL_DRG_RAMP_UP:
ret = ad9910_drg_destination_assert(st, AD9910_DEST_FREQUENCY);
@@ -1070,6 +1161,9 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
tmp64 = FIELD_GET(AD9910_DRG_LIMIT_LOWER_MSK,
st->reg[AD9910_REG_DRG_LIMIT].val64);
break;
+ case AD9910_CHANNEL_RAM:
+ tmp64 = st->reg[AD9910_REG_FTW].val32;
+ break;
default:
return -EINVAL;
}
@@ -1082,7 +1176,7 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
tmp64 = FIELD_GET(AD9910_PROFILE_ST_POW_MSK,
- st->reg[AD9910_REG_PROFILE(tmp32)].val64);
+ ad9910_st_profile_val(st, tmp32));
tmp32 = (tmp64 * AD9910_MAX_PHASE_MICRORAD) >> 16;
*val = tmp32 / MICRO;
*val2 = tmp32 % MICRO;
@@ -1107,6 +1201,12 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
tmp64 = (tmp64 * AD9910_PI_NANORAD) >> 31;
*val = div_s64_rem(tmp64, NANO, val2);
return IIO_VAL_INT_PLUS_NANO;
+ case AD9910_CHANNEL_RAM:
+ tmp64 = st->reg[AD9910_REG_POW].val16;
+ tmp32 = (tmp64 * AD9910_MAX_PHASE_MICRORAD) >> 16;
+ *val = tmp32 / MICRO;
+ *val2 = tmp32 % MICRO;
+ return IIO_VAL_INT_PLUS_MICRO;
default:
return -EINVAL;
}
@@ -1115,7 +1215,7 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
tmp64 = FIELD_GET(AD9910_PROFILE_ST_ASF_MSK,
- st->reg[AD9910_REG_PROFILE(tmp32)].val64);
+ ad9910_st_profile_val(st, tmp32));
*val = 0;
*val2 = tmp64 * MICRO >> 14;
return IIO_VAL_INT_PLUS_MICRO;
@@ -1155,6 +1255,10 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
tmp32 = FIELD_GET(AD9910_DRG_RATE_DEC_MSK,
st->reg[AD9910_REG_DRG_RATE].val32);
break;
+ case AD9910_CHANNEL_RAM:
+ tmp32 = FIELD_GET(AD9910_PROFILE_RAM_STEP_RATE_MSK,
+ ad9910_ram_profile_val(st));
+ break;
default:
return -EINVAL;
}
@@ -1176,7 +1280,7 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
struct ad9910_state *st = iio_priv(indio_dev);
u64 tmp64;
u32 tmp32;
- int ret;
+ int ret, i;
guard(mutex)(&st->lock);
@@ -1202,6 +1306,41 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
return ad9910_reg32_update(st, AD9910_REG_CFR2,
AD9910_CFR2_DRG_ENABLE_MSK,
tmp32, true);
+ case AD9910_CHANNEL_RAM:
+ if (AD9910_RAM_ENABLED(st) == !!val)
+ return 0;
+
+ /* swap profile configs */
+ for (i = 0; i < AD9910_NUM_PROFILES; i++) {
+ tmp64 = st->reg[AD9910_REG_PROFILE(i)].val64;
+ ret = ad9910_reg64_write(st,
+ AD9910_REG_PROFILE(i),
+ st->reg_profile[i],
+ false);
+ if (ret)
+ break;
+ st->reg_profile[i] = tmp64;
+ }
+
+ if (ret) {
+ /*
+ * After the write failure, profiles 0..i-1 were
+ * already swapped in SW, but Hw registers are
+ * still pending an IO update, so swap them back
+ * in SW to keep the state consistent.
+ */
+ while (i--) {
+ tmp64 = st->reg[AD9910_REG_PROFILE(i)].val64;
+ st->reg[AD9910_REG_PROFILE(i)].val64 = st->reg_profile[i];
+ st->reg_profile[i] = tmp64;
+ }
+ return ret;
+ }
+
+ tmp32 = FIELD_PREP(AD9910_CFR1_RAM_ENABLE_MSK, !!val);
+ return ad9910_reg32_update(st, AD9910_REG_CFR1,
+ AD9910_CFR1_RAM_ENABLE_MSK,
+ tmp32, true);
default:
return -EINVAL;
}
@@ -1215,6 +1354,11 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
switch (chan->channel) {
case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
tmp32 = chan->channel - AD9910_CHANNEL_PROFILE_0;
+ if (AD9910_RAM_ENABLED(st)) {
+ FIELD_MODIFY(AD9910_PROFILE_ST_FTW_MSK,
+ &st->reg_profile[tmp32], tmp64);
+ return 0;
+ }
tmp64 = FIELD_PREP(AD9910_PROFILE_ST_FTW_MSK, tmp64);
return ad9910_reg64_update(st, AD9910_REG_PROFILE(tmp32),
AD9910_PROFILE_ST_FTW_MSK,
@@ -1241,6 +1385,8 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
return ad9910_reg64_update(st, AD9910_REG_DRG_LIMIT,
AD9910_DRG_LIMIT_LOWER_MSK,
tmp64, true);
+ case AD9910_CHANNEL_RAM:
+ return ad9910_reg32_write(st, AD9910_REG_FTW, tmp64, true);
default:
return -EINVAL;
}
@@ -1258,6 +1404,13 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
tmp64 <<= 16;
tmp64 = DIV_U64_ROUND_CLOSEST(tmp64, AD9910_MAX_PHASE_MICRORAD);
tmp64 = min(tmp64, AD9910_POW_MAX);
+
+ if (AD9910_RAM_ENABLED(st)) {
+ FIELD_MODIFY(AD9910_PROFILE_ST_POW_MSK,
+ &st->reg_profile[tmp32], tmp64);
+ return 0;
+ }
+
tmp64 = FIELD_PREP(AD9910_PROFILE_ST_POW_MSK, tmp64);
return ad9910_reg64_update(st, AD9910_REG_PROFILE(tmp32),
AD9910_PROFILE_ST_POW_MSK,
@@ -1296,6 +1449,15 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
return ad9910_reg64_update(st, AD9910_REG_DRG_LIMIT,
AD9910_DRG_LIMIT_LOWER_MSK,
tmp64, true);
+ case AD9910_CHANNEL_RAM:
+ tmp64 = (u64)val * MICRO + val2;
+ if (tmp64 >= AD9910_MAX_PHASE_MICRORAD)
+ return -EINVAL;
+
+ tmp64 <<= 16;
+ tmp64 = DIV_U64_ROUND_CLOSEST(tmp64, AD9910_MAX_PHASE_MICRORAD);
+ tmp64 = min(tmp64, AD9910_POW_MAX);
+ return ad9910_reg16_write(st, AD9910_REG_POW, tmp64, true);
default:
return -EINVAL;
}
@@ -1309,6 +1471,13 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
tmp64 = ((u64)val * MICRO + val2) << 14;
tmp64 = DIV_U64_ROUND_CLOSEST(tmp64, MICRO);
tmp64 = min(tmp64, AD9910_ASF_MAX);
+
+ if (AD9910_RAM_ENABLED(st)) {
+ FIELD_MODIFY(AD9910_PROFILE_ST_ASF_MSK,
+ &st->reg_profile[tmp32], tmp64);
+ return 0;
+ }
+
tmp64 = FIELD_PREP(AD9910_PROFILE_ST_ASF_MSK, tmp64);
return ad9910_reg64_update(st, AD9910_REG_PROFILE(tmp32),
AD9910_PROFILE_ST_ASF_MSK,
@@ -1369,6 +1538,17 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
return ad9910_reg32_update(st, AD9910_REG_DRG_RATE,
AD9910_DRG_RATE_DEC_MSK,
tmp32, true);
+ case AD9910_CHANNEL_RAM:
+ if (!AD9910_RAM_ENABLED(st)) {
+ FIELD_MODIFY(AD9910_PROFILE_RAM_STEP_RATE_MSK,
+ &st->reg_profile[st->profile], tmp32);
+ return 0;
+ }
+
+ tmp64 = FIELD_PREP(AD9910_PROFILE_RAM_STEP_RATE_MSK, tmp32);
+ return ad9910_reg64_update(st, AD9910_REG_PROFILE(st->profile),
+ AD9910_PROFILE_RAM_STEP_RATE_MSK,
+ tmp64, true);
default:
return -EINVAL;
}
@@ -1390,6 +1570,7 @@ static int ad9910_write_raw_get_fmt(struct iio_dev *indio_dev,
case IIO_CHAN_INFO_SCALE:
switch (chan->channel) {
case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
+ case AD9910_CHANNEL_RAM:
return IIO_VAL_INT_PLUS_MICRO;
case AD9910_CHANNEL_DRG_RAMP_UP:
case AD9910_CHANNEL_DRG_RAMP_DOWN:
@@ -1466,6 +1647,7 @@ static const char * const ad9910_channel_str[] = {
[AD9910_CHAN_IDX_DRG] = "digital_ramp_generator",
[AD9910_CHAN_IDX_DRG_RAMP_UP] = "digital_ramp_up",
[AD9910_CHAN_IDX_DRG_RAMP_DOWN] = "digital_ramp_down",
+ [AD9910_CHAN_IDX_RAM] = "ram_control",
};
static int ad9910_read_label(struct iio_dev *indio_dev,
@@ -1475,6 +1657,126 @@ static int ad9910_read_label(struct iio_dev *indio_dev,
return sysfs_emit(label, "%s\n", ad9910_channel_str[chan->address]);
}
+static enum fw_upload_err ad9910_ram_fwu_prepare(struct fw_upload *fw_upload,
+ const u8 *data, u32 size)
+{
+ struct ad9910_state *st = fw_upload->dd_handle;
+ const struct ad9910_ram_fw *fw_data = (const struct ad9910_ram_fw *)data;
+ size_t wcount, bcount;
+
+ if (size < sizeof(struct ad9910_ram_fw))
+ return FW_UPLOAD_ERR_INVALID_SIZE;
+
+ if (get_unaligned_be32(&fw_data->magic) != AD9910_RAM_FW_MAGIC)
+ return FW_UPLOAD_ERR_FW_INVALID;
+
+ if (get_unaligned_be16(&fw_data->version) != AD9910_RAM_FW_V1)
+ return FW_UPLOAD_ERR_FW_INVALID;
+
+ wcount = get_unaligned_be16(&fw_data->wcount);
+ bcount = size - sizeof(struct ad9910_ram_fw);
+ if (wcount > AD9910_RAM_SIZE_MAX_WORDS ||
+ bcount != (wcount * AD9910_RAM_WORD_SIZE))
+ return FW_UPLOAD_ERR_INVALID_SIZE;
+
+ bcount += sizeof(fw_data->cfr1) + sizeof(fw_data->profiles);
+ if (crc32(0, &fw_data->cfr1, bcount) != get_unaligned_be32(&fw_data->crc))
+ return FW_UPLOAD_ERR_FW_INVALID;
+
+ guard(mutex)(&st->lock);
+ st->ram_fwu_cancel = false;
+
+ return FW_UPLOAD_ERR_NONE;
+}
+
+static enum fw_upload_err ad9910_ram_fwu_write(struct fw_upload *fw_upload,
+ const u8 *data, u32 offset,
+ u32 size, u32 *written)
+{
+ const struct ad9910_ram_fw *fw_data = (const struct ad9910_ram_fw *)data;
+ struct ad9910_state *st = fw_upload->dd_handle;
+ int ret, ret2, idx, wcount;
+ u64 tmp64, backup;
+
+ if (offset != 0)
+ return FW_UPLOAD_ERR_INVALID_SIZE;
+
+ guard(mutex)(&st->lock);
+
+ if (st->ram_fwu_cancel)
+ return FW_UPLOAD_ERR_CANCELED;
+
+ if (AD9910_RAM_ENABLED(st))
+ return FW_UPLOAD_ERR_HW_ERROR;
+
+ for (idx = 0; idx < AD9910_NUM_PROFILES; idx++)
+ st->reg_profile[idx] = get_unaligned_be64(&fw_data->profiles[idx]) |
+ AD9910_PROFILE_RAM_OPEN_MSK;
+
+ ret = ad9910_reg32_update(st, AD9910_REG_CFR1,
+ AD9910_CFR1_RAM_PLAYBACK_DEST_MSK |
+ AD9910_CFR1_INT_PROFILE_CTL_MSK,
+ get_unaligned_be32(&fw_data->cfr1), true);
+ if (ret)
+ return FW_UPLOAD_ERR_RW_ERROR;
+
+ wcount = get_unaligned_be16(&fw_data->wcount);
+ if (!wcount) {
+ *written = size;
+ return FW_UPLOAD_ERR_NONE; /* nothing else to write */
+ }
+
+ ret = ad9910_profile_set(st, st->profile);
+ if (ret)
+ return FW_UPLOAD_ERR_HW_ERROR;
+
+ /* backup profile register and update it with required address range */
+ backup = st->reg[AD9910_REG_PROFILE(st->profile)].val64;
+ tmp64 = AD9910_PROFILE_RAM_STEP_RATE_MSK |
+ FIELD_PREP(AD9910_PROFILE_RAM_START_ADDR_MSK, 0) |
+ FIELD_PREP(AD9910_PROFILE_RAM_END_ADDR_MSK, wcount - 1);
+ ret = ad9910_reg64_write(st, AD9910_REG_PROFILE(st->profile), tmp64, true);
+ if (ret)
+ return FW_UPLOAD_ERR_RW_ERROR;
+
+ memcpy(&st->tx_buf[1], fw_data->words, wcount * AD9910_RAM_WORD_SIZE);
+
+ /* write ram data and restore profile register */
+ ret = ad9910_spi_write(st, AD9910_REG_RAM,
+ wcount * AD9910_RAM_WORD_SIZE, false);
+ ret2 = ad9910_reg64_write(st, AD9910_REG_PROFILE(st->profile), backup, true);
+ if (ret || ret2)
+ return FW_UPLOAD_ERR_RW_ERROR;
+
+ *written = size;
+ return FW_UPLOAD_ERR_NONE;
+}
+
+static enum fw_upload_err ad9910_ram_fwu_poll_complete(struct fw_upload *fw_upload)
+{
+ return FW_UPLOAD_ERR_NONE;
+}
+
+static void ad9910_ram_fwu_cancel(struct fw_upload *fw_upload)
+{
+ struct ad9910_state *st = fw_upload->dd_handle;
+
+ guard(mutex)(&st->lock);
+ st->ram_fwu_cancel = true;
+}
+
+static void ad9910_ram_fwu_unregister(void *data)
+{
+ firmware_upload_unregister(data);
+}
+
+static const struct fw_upload_ops ad9910_ram_fwu_ops = {
+ .prepare = ad9910_ram_fwu_prepare,
+ .write = ad9910_ram_fwu_write,
+ .poll_complete = ad9910_ram_fwu_poll_complete,
+ .cancel = ad9910_ram_fwu_cancel
+};
+
static const struct iio_info ad9910_info = {
.read_raw = ad9910_read_raw,
.write_raw = ad9910_write_raw,
@@ -1601,9 +1903,33 @@ static int ad9910_setup(struct device *dev, struct ad9910_state *st,
if (ret)
return ret;
+ for (int i = 0; i < AD9910_NUM_PROFILES; i++) {
+ st->reg_profile[i] = AD9910_PROFILE_RAM_OPEN_MSK;
+ st->reg_profile[i] |= FIELD_PREP(AD9910_PROFILE_RAM_STEP_RATE_MSK, 1);
+ st->reg_profile[i] |= FIELD_PREP(AD9910_PROFILE_RAM_END_ADDR_MSK,
+ AD9910_RAM_ADDR_MAX);
+ }
+
return ad9910_io_update(st);
}
+static inline void ad9910_debugfs_init(struct ad9910_state *st,
+ struct iio_dev *indio_dev)
+{
+ struct dentry *d = iio_get_debugfs_dentry(indio_dev);
+ char buf[64];
+
+ /*
+ * symlinks are created here so iio userspace tools can refer to them
+ * as debug attributes.
+ */
+ snprintf(buf, sizeof(buf), "/sys/class/firmware/%s/loading", st->ram_fwu_name);
+ debugfs_create_symlink("ram_loading", d, buf);
+
+ snprintf(buf, sizeof(buf), "/sys/class/firmware/%s/data", st->ram_fwu_name);
+ debugfs_create_symlink("ram_data", d, buf);
+}
+
static int ad9910_probe(struct spi_device *spi)
{
static const char * const supplies[] = {
@@ -1688,7 +2014,25 @@ static int ad9910_probe(struct spi_device *spi)
if (ret)
return dev_err_probe(dev, ret, "device setup failed\n");
- return devm_iio_device_register(dev, indio_dev);
+ snprintf(st->ram_fwu_name, sizeof(st->ram_fwu_name), "%s:ram",
+ dev_name(&indio_dev->dev));
+ st->ram_fwu = firmware_upload_register(THIS_MODULE, dev, st->ram_fwu_name,
+ &ad9910_ram_fwu_ops, st);
+ if (IS_ERR(st->ram_fwu))
+ return dev_err_probe(dev, PTR_ERR(st->ram_fwu),
+ "failed to register ram upload ops\n");
+
+ ret = devm_add_action_or_reset(dev, ad9910_ram_fwu_unregister, st->ram_fwu);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to add ram upload unregister action\n");
+
+ ret = devm_iio_device_register(dev, indio_dev);
+ if (ret)
+ return ret;
+
+ ad9910_debugfs_init(st, indio_dev);
+ return 0;
}
static const struct spi_device_id ad9910_id[] = {
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v5 09/13] iio: frequency: ad9910: add RAM mode support
2026-05-17 18:37 ` [PATCH v5 09/13] iio: frequency: ad9910: add RAM mode support Rodrigo Alencar via B4 Relay
@ 2026-05-18 13:50 ` Rodrigo Alencar
0 siblings, 0 replies; 28+ messages in thread
From: Rodrigo Alencar @ 2026-05-18 13:50 UTC (permalink / raw)
To: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
On 26/05/17 07:19PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> - [High] Incomplete hardware rollback during a profile swap failure leaves AD9910 shadow registers corrupted.
> - [High] Missing software cache and hardware rollback when CFR1 register update fails.
> - [High] Unprotected software profile cache corruption on firmware upload failure.
> - [High] Firmware upload `.write` callback fails on chunked payloads and performs out-of-bounds memory reads.
> - [Medium] The RAM firmware upload sysfs node and debugfs symlinks are registered with a `(null)` name.
> --
>
> commit 3876f09fc86743085e5099fea5762c34dc150ecf
> Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> iio: frequency: ad9910: add RAM mode support
>
> Add RAM control channel, which includes RAM data loading via firmware
> upload interface, per-profile configuration, profile switching,
> sampling frequency control, and ram-enable-aware read/write paths.
>
> > diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
> > index 4ad80475139d7..86ed350011cff 100644
> > --- a/drivers/iio/frequency/ad9910.c
> > +++ b/drivers/iio/frequency/ad9910.c
>
> [ ... ]
>
> > @@ -1202,6 +1306,41 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
> > return ad9910_reg32_update(st, AD9910_REG_CFR2,
> > AD9910_CFR2_DRG_ENABLE_MSK,
> > tmp32, true);
> > + case AD9910_CHANNEL_RAM:
> > + if (AD9910_RAM_ENABLED(st) == !!val)
> > + return 0;
> > +
> > + /* swap profile configs */
> > + for (i = 0; i < AD9910_NUM_PROFILES; i++) {
> > + tmp64 = st->reg[AD9910_REG_PROFILE(i)].val64;
> > + ret = ad9910_reg64_write(st,
> > + AD9910_REG_PROFILE(i),
> > + st->reg_profile[i],
> > + false);
> > + if (ret)
> > + break;
> > + st->reg_profile[i] = tmp64;
> > + }
> > +
> > + if (ret) {
> > + /*
> > + * After the write failure, profiles 0..i-1 were
> > + * already swapped in SW, but Hw registers are
> > + * still pending an IO update, so swap them back
> > + * in SW to keep the state consistent.
> > + */
> > + while (i--) {
> > + tmp64 = st->reg[AD9910_REG_PROFILE(i)].val64;
> > + st->reg[AD9910_REG_PROFILE(i)].val64 = st->reg_profile[i];
> > + st->reg_profile[i] = tmp64;
> > + }
> > + return ret;
>
> If a write fails mid-loop, this rollback block restores the software cache
> but doesn't issue SPI writes to revert the hardware shadow registers.
> Could the next successful SPI write with an IO_UPDATE pulse inadvertently
> latch these corrupted, partially-swapped profiles into the active hardware
> state?
The approach reverts the changes on cached values, so we do not have RAM and single
tone profile values mixed in software. The hardware might be in an invalid state,
but an error is reported to the user.
> > + }
> > +
> > + tmp32 = FIELD_PREP(AD9910_CFR1_RAM_ENABLE_MSK, !!val);
> > + return ad9910_reg32_update(st, AD9910_REG_CFR1,
> > + AD9910_CFR1_RAM_ENABLE_MSK,
> > + tmp32, true);
>
> If ad9910_reg32_update() fails here, the function returns immediately without
> reverting the swapped profiles. Should there be a rollback of the swapped
> profiles in this error path to prevent the device from operating with corrupted
> synthesizer parameters?
Yes, I'd this part can be improved. Writing to CFR1 can be moved up (before the cache
restore).
>
> > default:
> > return -EINVAL;
> > }
>
> [ ... ]
>
> > @@ -1475,6 +1657,126 @@ static int ad9910_read_label(struct iio_dev *indio_dev,
> > +static enum fw_upload_err ad9910_ram_fwu_write(struct fw_upload *fw_upload,
> > + const u8 *data, u32 offset,
> > + u32 size, u32 *written)
> > +{
> > + const struct ad9910_ram_fw *fw_data = (const struct ad9910_ram_fw *)data;
> > + struct ad9910_state *st = fw_upload->dd_handle;
> > + int ret, ret2, idx, wcount;
> > + u64 tmp64, backup;
> > +
> > + if (offset != 0)
> > + return FW_UPLOAD_ERR_INVALID_SIZE;
>
> The sysfs firmware upload framework chunks data into blocks bounded by
> PAGE_SIZE (typically 4096 bytes). Since the maximum AD9910 firmware size
> can be 4176 bytes, this driver will reject any chunks after the first.
> Can this be adjusted to support firmware files larger than PAGE_SIZE?
That does not seem to be the case:
https://elixir.bootlin.com/linux/v7.1-rc3/source/drivers/base/firmware_loader/sysfs_upload.c#L184
Sysfs binary attribute writes from userspace are limited to PAGE_SIZE per
write() syscall (enforced in fs/sysfs/file.c). But the firmware loader
framework accumulates these into an internal buffer (fw->data).
The driver's write callback is called from fw_upload_main() in sysfs_upload.c.
So, the key question is whether that function passes fw->size - offset
(the full remaining size) or min(fw->size - offset, PAGE_SIZE) (PAGE_SIZE-bounded chunks)
to the driver callback.
The referenced code shows that the write callback is not called every
PAGE_SIZE chunks, but the callback implementation that defines the how
much it can handle at each call.
Also, I have already tested this code with a FW file bigger than 4k.
> > +
> > + guard(mutex)(&st->lock);
> > +
> > + if (st->ram_fwu_cancel)
> > + return FW_UPLOAD_ERR_CANCELED;
> > +
> > + if (AD9910_RAM_ENABLED(st))
> > + return FW_UPLOAD_ERR_HW_ERROR;
> > +
> > + for (idx = 0; idx < AD9910_NUM_PROFILES; idx++)
> > + st->reg_profile[idx] = get_unaligned_be64(&fw_data->profiles[idx]) |
> > + AD9910_PROFILE_RAM_OPEN_MSK;
>
> Here the software cache st->reg_profile[] is overwritten before the SPI
> hardware operations. If any subsequent hardware writes fail, the function
> aborts and the cache is left with partially uploaded profiles.
> Could the original cache be backed up and restored on failure?
I'd say that is not an issue. When RAM is disabled (requirement to enter this function),
this cache is exclusive to be managed by the RAM mode. This is meant to be
written here.
>
> > +
> > + ret = ad9910_reg32_update(st, AD9910_REG_CFR1,
> > + AD9910_CFR1_RAM_PLAYBACK_DEST_MSK |
> > + AD9910_CFR1_INT_PROFILE_CTL_MSK,
> > + get_unaligned_be32(&fw_data->cfr1), true);
> > + if (ret)
> > + return FW_UPLOAD_ERR_RW_ERROR;
> > +
> > + wcount = get_unaligned_be16(&fw_data->wcount);
> > + if (!wcount) {
> > + *written = size;
> > + return FW_UPLOAD_ERR_NONE; /* nothing else to write */
> > + }
> > +
> > + ret = ad9910_profile_set(st, st->profile);
> > + if (ret)
> > + return FW_UPLOAD_ERR_HW_ERROR;
> > +
> > + /* backup profile register and update it with required address range */
> > + backup = st->reg[AD9910_REG_PROFILE(st->profile)].val64;
> > + tmp64 = AD9910_PROFILE_RAM_STEP_RATE_MSK |
> > + FIELD_PREP(AD9910_PROFILE_RAM_START_ADDR_MSK, 0) |
> > + FIELD_PREP(AD9910_PROFILE_RAM_END_ADDR_MSK, wcount - 1);
> > + ret = ad9910_reg64_write(st, AD9910_REG_PROFILE(st->profile), tmp64, true);
> > + if (ret)
> > + return FW_UPLOAD_ERR_RW_ERROR;
> > +
> > + memcpy(&st->tx_buf[1], fw_data->words, wcount * AD9910_RAM_WORD_SIZE);
>
> If the firmware is larger than PAGE_SIZE, size will be 4096 on the first
> call, but wcount could request more bytes than are present in the chunk.
> Does this memcpy() risk reading out-of-bounds memory from the data buffer?
this is dicussed above, from drivers/base/firmware_loader/sysfs_upload.c it
does not seem to be true that the write happens in chunks of PAGE_SIZE.
> [ ... ]
>
> > @@ -1688,7 +2014,25 @@ static int ad9910_probe(struct spi_device *spi)
> > if (ret)
> > return dev_err_probe(dev, ret, "device setup failed\n");
> >
> > - return devm_iio_device_register(dev, indio_dev);
> > + snprintf(st->ram_fwu_name, sizeof(st->ram_fwu_name), "%s:ram",
> > + dev_name(&indio_dev->dev));
>
> The IIO core does not assign the device name to indio_dev->dev until
> devm_iio_device_register() is called. Will dev_name() return "(null)" here,
> resulting in sysfs nodes named "/sys/class/firmware/(null):ram"?
> This might also cause probe failures due to sysfs name collisions if multiple
> AD9910 devices are present on the system.
I suppose that is incorrect.
dev_set_name(&indio_dev->dev, "iio:device%d", iio_dev_opaque->id)
happens during iio_device_alloc().
>
> > + st->ram_fwu = firmware_upload_register(THIS_MODULE, dev, st->ram_fwu_name,
> > + &ad9910_ram_fwu_ops, st);
> > + if (IS_ERR(st->ram_fwu))
> > + return dev_err_probe(dev, PTR_ERR(st->ram_fwu),
> > + "failed to register ram upload ops\n");
> > +
> > + ret = devm_add_action_or_reset(dev, ad9910_ram_fwu_unregister, st->ram_fwu);
> > + if (ret)
> > + return dev_err_probe(dev, ret,
> > + "failed to add ram upload unregister action\n");
> > +
> > + ret = devm_iio_device_register(dev, indio_dev);
> > + if (ret)
> > + return ret;
> > +
> > + ad9910_debugfs_init(st, indio_dev);
> > + return 0;
> > }
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260517-ad9910-iio-driver-v5-0-31599c88314a@analog.com?part=9
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v5 10/13] iio: frequency: ad9910: add output shift keying support
2026-05-17 18:37 [PATCH v5 00/13] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
` (8 preceding siblings ...)
2026-05-17 18:37 ` [PATCH v5 09/13] iio: frequency: ad9910: add RAM mode support Rodrigo Alencar via B4 Relay
@ 2026-05-17 18:37 ` Rodrigo Alencar via B4 Relay
2026-05-17 18:37 ` [PATCH v5 11/13] iio: frequency: ad9910: show channel priority in debugfs Rodrigo Alencar via B4 Relay
` (2 subsequent siblings)
12 siblings, 0 replies; 28+ messages in thread
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add OSK channel with amplitude envelope control capabilities:
- OSK enable/disable via IIO_CHAN_INFO_ENABLE;
- Amplitude ramp rate control via IIO_CHAN_INFO_SAMP_FREQ;
- Amplitude scale readback via IIO_CHAN_INFO_SCALE (ASF register);
- Automatic OSK step size configurable through the scale_roc extended
attribute, which allows for selectable step sizes in nano-units:
- 0: no step, means manual mode (NOT pin controlled)
- 61035: 1/2^14 step, automatic mode (pin controlled)
- 122070: 2/2^14 step, automatic mode (pin controlled)
- 244141: 4/2^14 step, automatic mode (pin controlled)
- 488281: 8/2^14 step, automatic mode (pin controlled)
- 1000000000: 1.0 step (max), manual mode (pin controlled)
The ASF register is initialized with a default amplitude ramp rate during
device setup to ensure valid readback.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
drivers/iio/frequency/ad9910.c | 203 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 203 insertions(+)
diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
index 86ed350011cf..91f28c7de68b 100644
--- a/drivers/iio/frequency/ad9910.c
+++ b/drivers/iio/frequency/ad9910.c
@@ -235,6 +235,7 @@
* @AD9910_CHANNEL_DRG_RAMP_UP: DRG ramp up channel
* @AD9910_CHANNEL_DRG_RAMP_DOWN: DRG ramp down channel
* @AD9910_CHANNEL_RAM: RAM control output channel
+ * @AD9910_CHANNEL_OSK: Output Shift Keying output channel
*/
enum ad9910_channel {
AD9910_CHANNEL_PHY = 100,
@@ -251,6 +252,7 @@ enum ad9910_channel {
AD9910_CHANNEL_DRG_RAMP_UP = 131,
AD9910_CHANNEL_DRG_RAMP_DOWN = 132,
AD9910_CHANNEL_RAM = 140,
+ AD9910_CHANNEL_OSK = 150,
};
/**
@@ -306,6 +308,7 @@ enum {
AD9910_CHAN_IDX_DRG_RAMP_UP,
AD9910_CHAN_IDX_DRG_RAMP_DOWN,
AD9910_CHAN_IDX_RAM,
+ AD9910_CHAN_IDX_OSK,
};
enum {
@@ -318,6 +321,8 @@ enum {
AD9910_DRG_PHASE_ROC,
AD9910_DRG_AMP_ROC,
AD9910_DRG_DWELL_EN,
+ AD9910_OSK_AUTO_ROC,
+ AD9910_OSK_AUTO_ROC_AVAIL,
};
struct ad9910_data {
@@ -977,6 +982,135 @@ static ssize_t ad9910_drg_attrs_write(struct iio_dev *indio_dev,
return len;
}
+static const u32 ad9910_osk_nstep[] = {
+ 0, /* no step: manual mode (NOT pin controlled) */
+ 61035, /* 1/2^14 step: automatic mode (pin controlled) */
+ 122070, /* 2/2^14 step: automatic mode (pin controlled) */
+ 244141, /* 4/2^14 step: automatic mode (pin controlled) */
+ 488281, /* 8/2^14 step: automatic mode (pin controlled) */
+ NANO, /* full scale step: manual mode (pin controlled) */
+};
+
+static ssize_t ad9910_osk_attrs_read(struct iio_dev *indio_dev,
+ uintptr_t private,
+ const struct iio_chan_spec *chan,
+ char *buf)
+{
+ struct ad9910_state *st = iio_priv(indio_dev);
+ bool auto_en, pinctrl_en;
+ u32 rate, step;
+ int vals[2];
+ u64 roc64;
+
+ guard(mutex)(&st->lock);
+
+ rate = 4 * FIELD_GET(AD9910_ASF_RAMP_RATE_MSK,
+ st->reg[AD9910_REG_ASF].val32);
+ if (!rate)
+ return -ERANGE;
+
+ switch (private) {
+ case AD9910_OSK_AUTO_ROC:
+ auto_en = FIELD_GET(AD9910_CFR1_SELECT_AUTO_OSK_MSK,
+ st->reg[AD9910_REG_CFR1].val32);
+ pinctrl_en = FIELD_GET(AD9910_CFR1_OSK_MANUAL_EXT_CTL_MSK,
+ st->reg[AD9910_REG_CFR1].val32);
+ if (auto_en) {
+ step = FIELD_GET(AD9910_ASF_STEP_SIZE_MSK,
+ st->reg[AD9910_REG_ASF].val32);
+ step = ad9910_osk_nstep[step + 1];
+ } else if (pinctrl_en) {
+ step = ad9910_osk_nstep[ARRAY_SIZE(ad9910_osk_nstep) - 1];
+ } else {
+ step = ad9910_osk_nstep[0];
+ }
+
+ roc64 = div_u64((u64)step * st->data.sysclk_freq_hz, rate);
+ vals[0] = div_s64_rem(roc64, NANO, &vals[1]);
+ return iio_format_value(buf, IIO_VAL_INT_PLUS_NANO,
+ ARRAY_SIZE(vals), vals);
+ case AD9910_OSK_AUTO_ROC_AVAIL: {
+ ssize_t len = 0;
+
+ for (unsigned int i = 0; i < ARRAY_SIZE(ad9910_osk_nstep); i++) {
+ roc64 = div_u64((u64)ad9910_osk_nstep[i] *
+ st->data.sysclk_freq_hz, rate);
+ vals[0] = div_s64_rem(roc64, NANO, &vals[1]);
+ if (!vals[1])
+ len += sysfs_emit_at(buf, len, "%d ", vals[0]);
+ else
+ len += sysfs_emit_at(buf, len, "%d.%09d ",
+ vals[0], vals[1]);
+ }
+
+ buf[len - 1] = '\n'; /* replace last space with a newline */
+ return len;
+ }
+ default:
+ return -EINVAL;
+ }
+}
+
+static ssize_t ad9910_osk_attrs_write(struct iio_dev *indio_dev,
+ uintptr_t private,
+ const struct iio_chan_spec *chan,
+ const char *buf, size_t len)
+{
+ struct ad9910_state *st = iio_priv(indio_dev);
+ int val, val2, ret;
+ u32 idx, cfg, rate;
+ u64 nstep;
+
+ ret = iio_str_to_fixpoint(buf, NANO / 10, &val, &val2);
+ if (ret)
+ return ret;
+
+ if (val < 0 || val2 < 0)
+ return -EINVAL;
+
+ guard(mutex)(&st->lock);
+
+ rate = 4 * FIELD_GET(AD9910_ASF_RAMP_RATE_MSK,
+ st->reg[AD9910_REG_ASF].val32);
+ if (!rate)
+ return -ERANGE;
+
+ switch (private) {
+ case AD9910_OSK_AUTO_ROC:
+ nstep = ad9910_rational_scale((u64)val * NANO + val2, rate,
+ st->data.sysclk_freq_hz);
+ nstep = min(nstep, NANO);
+ idx = find_closest(nstep, ad9910_osk_nstep,
+ ARRAY_SIZE(ad9910_osk_nstep));
+ if (idx == ARRAY_SIZE(ad9910_osk_nstep) - 1) {
+ cfg = AD9910_CFR1_OSK_MANUAL_EXT_CTL_MSK;
+ } else if (idx == 0) {
+ cfg = 0;
+ } else {
+ cfg = FIELD_PREP(AD9910_ASF_STEP_SIZE_MSK, idx - 1);
+ ret = ad9910_reg32_update(st, AD9910_REG_ASF,
+ AD9910_ASF_STEP_SIZE_MSK,
+ cfg, false);
+ if (ret)
+ return ret;
+
+ cfg = AD9910_CFR1_SELECT_AUTO_OSK_MSK;
+ }
+
+ ret = ad9910_reg32_update(st, AD9910_REG_CFR1,
+ AD9910_CFR1_SELECT_AUTO_OSK_MSK |
+ AD9910_CFR1_OSK_MANUAL_EXT_CTL_MSK,
+ cfg, true);
+ if (ret)
+ return ret;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return len;
+}
+
#define AD9910_EXT_INFO_TMPL(_name, _ident, _shared, _fn_desc) { \
.name = _name, \
.read = ad9910_ ## _fn_desc ## _read, \
@@ -1015,6 +1149,23 @@ static const struct iio_chan_spec_ext_info ad9910_drg_ramp_ext_info[] = {
{ }
};
+static const struct iio_chan_spec_ext_info ad9910_osk_ext_info[] = {
+ {
+ .name = "scale_roc",
+ .read = ad9910_osk_attrs_read,
+ .write = ad9910_osk_attrs_write,
+ .private = AD9910_OSK_AUTO_ROC,
+ .shared = IIO_SEPARATE,
+ },
+ {
+ .name = "scale_roc_available",
+ .read = ad9910_osk_attrs_read,
+ .private = AD9910_OSK_AUTO_ROC_AVAIL,
+ .shared = IIO_SEPARATE,
+ },
+ { }
+};
+
#define AD9910_PROFILE_CHAN(idx) { \
.type = IIO_ALTVOLTAGE, \
.indexed = 1, \
@@ -1102,6 +1253,18 @@ static const struct iio_chan_spec ad9910_channels[] = {
BIT(IIO_CHAN_INFO_SAMP_FREQ),
.parent = &ad9910_channels[AD9910_CHAN_IDX_PHY],
},
+ [AD9910_CHAN_IDX_OSK] = {
+ .type = IIO_ALTVOLTAGE,
+ .indexed = 1,
+ .output = 1,
+ .channel = AD9910_CHANNEL_OSK,
+ .address = AD9910_CHAN_IDX_OSK,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_ENABLE) |
+ BIT(IIO_CHAN_INFO_SCALE) |
+ BIT(IIO_CHAN_INFO_SAMP_FREQ),
+ .ext_info = ad9910_osk_ext_info,
+ .parent = &ad9910_channels[AD9910_CHAN_IDX_PHY],
+ },
};
static int ad9910_read_raw(struct iio_dev *indio_dev,
@@ -1134,6 +1297,10 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
*val = FIELD_GET(AD9910_CFR1_RAM_ENABLE_MSK,
st->reg[AD9910_REG_CFR1].val32);
break;
+ case AD9910_CHANNEL_OSK:
+ *val = FIELD_GET(AD9910_CFR1_OSK_ENABLE_MSK,
+ st->reg[AD9910_REG_CFR1].val32);
+ break;
default:
return -EINVAL;
}
@@ -1239,6 +1406,12 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
*val = 0;
*val2 = tmp64 * NANO >> 32;
return IIO_VAL_INT_PLUS_NANO;
+ case AD9910_CHANNEL_OSK:
+ tmp64 = FIELD_GET(AD9910_ASF_SCALE_FACTOR_MSK,
+ st->reg[AD9910_REG_ASF].val32);
+ *val = 0;
+ *val2 = tmp64 * MICRO >> 14;
+ return IIO_VAL_INT_PLUS_MICRO;
default:
return -EINVAL;
}
@@ -1259,6 +1432,10 @@ static int ad9910_read_raw(struct iio_dev *indio_dev,
tmp32 = FIELD_GET(AD9910_PROFILE_RAM_STEP_RATE_MSK,
ad9910_ram_profile_val(st));
break;
+ case AD9910_CHANNEL_OSK:
+ tmp32 = FIELD_GET(AD9910_ASF_RAMP_RATE_MSK,
+ st->reg[AD9910_REG_ASF].val32);
+ break;
default:
return -EINVAL;
}
@@ -1341,6 +1518,11 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
return ad9910_reg32_update(st, AD9910_REG_CFR1,
AD9910_CFR1_RAM_ENABLE_MSK,
tmp32, true);
+ case AD9910_CHANNEL_OSK:
+ tmp32 = FIELD_PREP(AD9910_CFR1_OSK_ENABLE_MSK, !!val);
+ return ad9910_reg32_update(st, AD9910_REG_CFR1,
+ AD9910_CFR1_OSK_ENABLE_MSK,
+ tmp32, true);
default:
return -EINVAL;
}
@@ -1510,6 +1692,14 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
return ad9910_reg64_update(st, AD9910_REG_DRG_LIMIT,
AD9910_DRG_LIMIT_LOWER_MSK,
tmp64, true);
+ case AD9910_CHANNEL_OSK:
+ tmp64 = ((u64)val * MICRO + val2) << 14;
+ tmp64 = DIV_U64_ROUND_CLOSEST(tmp64, MICRO);
+ tmp32 = min(tmp64, AD9910_ASF_MAX);
+ tmp32 = FIELD_PREP(AD9910_ASF_SCALE_FACTOR_MSK, tmp32);
+ return ad9910_reg32_update(st, AD9910_REG_ASF,
+ AD9910_ASF_SCALE_FACTOR_MSK,
+ tmp32, true);
default:
return -EINVAL;
}
@@ -1549,6 +1739,11 @@ static int ad9910_write_raw(struct iio_dev *indio_dev,
return ad9910_reg64_update(st, AD9910_REG_PROFILE(st->profile),
AD9910_PROFILE_RAM_STEP_RATE_MSK,
tmp64, true);
+ case AD9910_CHANNEL_OSK:
+ return ad9910_reg32_update(st, AD9910_REG_ASF,
+ AD9910_ASF_RAMP_RATE_MSK,
+ FIELD_PREP(AD9910_ASF_RAMP_RATE_MSK, tmp32),
+ true);
default:
return -EINVAL;
}
@@ -1571,6 +1766,7 @@ static int ad9910_write_raw_get_fmt(struct iio_dev *indio_dev,
switch (chan->channel) {
case AD9910_CHANNEL_PROFILE_0 ... AD9910_CHANNEL_PROFILE_7:
case AD9910_CHANNEL_RAM:
+ case AD9910_CHANNEL_OSK:
return IIO_VAL_INT_PLUS_MICRO;
case AD9910_CHANNEL_DRG_RAMP_UP:
case AD9910_CHANNEL_DRG_RAMP_DOWN:
@@ -1648,6 +1844,7 @@ static const char * const ad9910_channel_str[] = {
[AD9910_CHAN_IDX_DRG_RAMP_UP] = "digital_ramp_up",
[AD9910_CHAN_IDX_DRG_RAMP_DOWN] = "digital_ramp_down",
[AD9910_CHAN_IDX_RAM] = "ram_control",
+ [AD9910_CHAN_IDX_OSK] = "output_shift_keying",
};
static int ad9910_read_label(struct iio_dev *indio_dev,
@@ -1896,6 +2093,12 @@ static int ad9910_setup(struct device *dev, struct ad9910_state *st,
return ret;
/* configure step rate with default values */
+ ret = ad9910_reg32_write(st, AD9910_REG_ASF,
+ FIELD_PREP(AD9910_ASF_RAMP_RATE_MSK, 1),
+ false);
+ if (ret)
+ return ret;
+
ret = ad9910_reg32_write(st, AD9910_REG_DRG_RATE,
FIELD_PREP(AD9910_DRG_RATE_DEC_MSK, 1) |
FIELD_PREP(AD9910_DRG_RATE_INC_MSK, 1),
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* [PATCH v5 11/13] iio: frequency: ad9910: show channel priority in debugfs
2026-05-17 18:37 [PATCH v5 00/13] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
` (9 preceding siblings ...)
2026-05-17 18:37 ` [PATCH v5 10/13] iio: frequency: ad9910: add output shift keying support Rodrigo Alencar via B4 Relay
@ 2026-05-17 18:37 ` Rodrigo Alencar via B4 Relay
2026-05-22 18:07 ` Jonathan Cameron
2026-05-17 18:37 ` [PATCH v5 12/13] Documentation: ABI: testing: add docs for ad9910 sysfs entries Rodrigo Alencar via B4 Relay
2026-05-17 18:37 ` [PATCH v5 13/13] docs: iio: add documentation for ad9910 driver Rodrigo Alencar via B4 Relay
12 siblings, 1 reply; 28+ messages in thread
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Expose frequency_source, phase_source and amplitude_source attributes in
debugfs. Those indicate from which channel the specific DDS parameter is
being sourced by returning its label. The implementation follows the
priority table found in the datasheet.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
drivers/iio/frequency/ad9910.c | 148 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 148 insertions(+)
diff --git a/drivers/iio/frequency/ad9910.c b/drivers/iio/frequency/ad9910.c
index 91f28c7de68b..8c8e73f340f8 100644
--- a/drivers/iio/frequency/ad9910.c
+++ b/drivers/iio/frequency/ad9910.c
@@ -22,6 +22,7 @@
#include <linux/property.h>
#include <linux/regulator/consumer.h>
#include <linux/reset.h>
+#include <linux/seq_file.h>
#include <linux/spi/spi.h>
#include <linux/sysfs.h>
#include <linux/types.h>
@@ -2116,6 +2117,146 @@ static int ad9910_setup(struct device *dev, struct ad9910_state *st,
return ad9910_io_update(st);
}
+static inline const char *ad9910_frequency_source_get(struct ad9910_state *st)
+{
+ bool ram_en, mode_en;
+
+ guard(mutex)(&st->lock);
+
+ /* RAM enabled and data destination is frequency */
+ ram_en = AD9910_RAM_ENABLED(st);
+ if (ram_en && AD9910_DEST_FREQUENCY ==
+ FIELD_GET(AD9910_CFR1_RAM_PLAYBACK_DEST_MSK,
+ st->reg[AD9910_REG_CFR1].val32))
+ return ad9910_channel_str[AD9910_CHAN_IDX_RAM];
+
+ /* DRG enabled and data destination is frequency */
+ mode_en = FIELD_GET(AD9910_CFR2_DRG_ENABLE_MSK,
+ st->reg[AD9910_REG_CFR2].val32);
+ if (mode_en && AD9910_DEST_FREQUENCY ==
+ FIELD_GET(AD9910_CFR2_DRG_DEST_MSK,
+ st->reg[AD9910_REG_CFR2].val32))
+ return ad9910_channel_str[AD9910_CHAN_IDX_DRG];
+
+ /* Parallel data port enabled and data destination is frequency */
+ mode_en = FIELD_GET(AD9910_CFR2_PARALLEL_DATA_PORT_EN_MSK,
+ st->reg[AD9910_REG_CFR2].val32);
+ if (mode_en) /* TODO: get destination from backend once it is supported */
+ return ad9910_channel_str[AD9910_CHAN_IDX_PARALLEL_PORT];
+
+ /* FTW: RAM enabled and data destination is phase, amplitude, or polar */
+ if (ram_en)
+ return ad9910_channel_str[AD9910_CHAN_IDX_RAM];
+
+ /* single tone profiles */
+ return ad9910_channel_str[AD9910_CHAN_IDX_PROFILE_0 + st->profile];
+}
+
+static int ad9910_frequency_source_show(struct seq_file *s, void *ignored)
+{
+ seq_printf(s, "%s\n", ad9910_frequency_source_get(s->private));
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(ad9910_frequency_source);
+
+static inline const char *ad9910_phase_source_get(struct ad9910_state *st)
+{
+ bool ram_en, mode_en;
+ u32 destination;
+
+ guard(mutex)(&st->lock);
+
+ /* RAM enabled and data destination is phase or polar */
+ ram_en = AD9910_RAM_ENABLED(st);
+ if (ram_en) {
+ destination = FIELD_GET(AD9910_CFR1_RAM_PLAYBACK_DEST_MSK,
+ st->reg[AD9910_REG_CFR1].val32);
+ if (destination == AD9910_DEST_PHASE ||
+ destination == AD9910_DEST_POLAR)
+ return ad9910_channel_str[AD9910_CHAN_IDX_RAM];
+ }
+
+ /* DRG enabled and data destination is phase */
+ mode_en = FIELD_GET(AD9910_CFR2_DRG_ENABLE_MSK,
+ st->reg[AD9910_REG_CFR2].val32);
+ if (mode_en && AD9910_DEST_PHASE ==
+ FIELD_GET(AD9910_CFR2_DRG_DEST_MSK,
+ st->reg[AD9910_REG_CFR2].val32))
+ return ad9910_channel_str[AD9910_CHAN_IDX_DRG];
+
+ /* Parallel data port enabled and data destination is phase */
+ mode_en = FIELD_GET(AD9910_CFR2_PARALLEL_DATA_PORT_EN_MSK,
+ st->reg[AD9910_REG_CFR2].val32);
+ if (mode_en) /* TODO: get destination from backend once it is supported */
+ return ad9910_channel_str[AD9910_CHAN_IDX_PARALLEL_PORT];
+
+ /* POW: RAM enabled and data destination is frequency, amplitude, or polar */
+ if (ram_en)
+ return ad9910_channel_str[AD9910_CHAN_IDX_RAM];
+
+ /* single tone profiles */
+ return ad9910_channel_str[AD9910_CHAN_IDX_PROFILE_0 + st->profile];
+}
+
+static int ad9910_phase_source_show(struct seq_file *s, void *ignored)
+{
+ seq_printf(s, "%s\n", ad9910_phase_source_get(s->private));
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(ad9910_phase_source);
+
+static inline const char *ad9910_amplitude_source_get(struct ad9910_state *st)
+{
+ bool ram_en, mode_en;
+ u32 destination;
+
+ guard(mutex)(&st->lock);
+
+ /* OSK enabled */
+ mode_en = FIELD_GET(AD9910_CFR1_OSK_ENABLE_MSK,
+ st->reg[AD9910_REG_CFR1].val32);
+ if (mode_en)
+ return ad9910_channel_str[AD9910_CHAN_IDX_OSK];
+
+ /* RAM enabled and data destination is amplitude or polar */
+ ram_en = AD9910_RAM_ENABLED(st);
+ if (ram_en) {
+ destination = FIELD_GET(AD9910_CFR1_RAM_PLAYBACK_DEST_MSK,
+ st->reg[AD9910_REG_CFR1].val32);
+ if (destination == AD9910_DEST_AMPLITUDE ||
+ destination == AD9910_DEST_POLAR)
+ return ad9910_channel_str[AD9910_CHAN_IDX_RAM];
+ }
+
+ /* DRG enabled and data destination is amplitude */
+ mode_en = FIELD_GET(AD9910_CFR2_DRG_ENABLE_MSK,
+ st->reg[AD9910_REG_CFR2].val32);
+ if (mode_en && AD9910_DEST_AMPLITUDE ==
+ FIELD_GET(AD9910_CFR2_DRG_DEST_MSK,
+ st->reg[AD9910_REG_CFR2].val32))
+ return ad9910_channel_str[AD9910_CHAN_IDX_DRG];
+
+ /* Parallel data port enabled and data destination is amplitude */
+ mode_en = FIELD_GET(AD9910_CFR2_PARALLEL_DATA_PORT_EN_MSK,
+ st->reg[AD9910_REG_CFR2].val32);
+ if (mode_en) /* TODO: get destination from backend once it is supported */
+ return ad9910_channel_str[AD9910_CHAN_IDX_PARALLEL_PORT];
+
+ /* only way to control amplitude at this point is through OSK */
+ if (ram_en)
+ return ad9910_channel_str[AD9910_CHAN_IDX_OSK];
+
+ /* single tone profiles */
+ return ad9910_channel_str[AD9910_CHAN_IDX_PROFILE_0 + st->profile];
+}
+
+static int ad9910_amplitude_source_show(struct seq_file *s, void *ignored)
+{
+ seq_printf(s, "%s\n", ad9910_amplitude_source_get(s->private));
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(ad9910_amplitude_source);
+
static inline void ad9910_debugfs_init(struct ad9910_state *st,
struct iio_dev *indio_dev)
{
@@ -2131,6 +2272,13 @@ static inline void ad9910_debugfs_init(struct ad9910_state *st,
snprintf(buf, sizeof(buf), "/sys/class/firmware/%s/data", st->ram_fwu_name);
debugfs_create_symlink("ram_data", d, buf);
+
+ debugfs_create_file("frequency_source", 0400, d, st,
+ &ad9910_frequency_source_fops);
+ debugfs_create_file("phase_source", 0400, d, st,
+ &ad9910_phase_source_fops);
+ debugfs_create_file("amplitude_source", 0400, d, st,
+ &ad9910_amplitude_source_fops);
}
static int ad9910_probe(struct spi_device *spi)
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v5 11/13] iio: frequency: ad9910: show channel priority in debugfs
2026-05-17 18:37 ` [PATCH v5 11/13] iio: frequency: ad9910: show channel priority in debugfs Rodrigo Alencar via B4 Relay
@ 2026-05-22 18:07 ` Jonathan Cameron
0 siblings, 0 replies; 28+ messages in thread
From: Jonathan Cameron @ 2026-05-22 18:07 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
On Sun, 17 May 2026 19:37:55 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Expose frequency_source, phase_source and amplitude_source attributes in
> debugfs. Those indicate from which channel the specific DDS parameter is
> being sourced by returning its label. The implementation follows the
> priority table found in the datasheet.
>
Examples here would be good.
I guess maybe this suffers the same label problem as the parent stuff.
Same solution?
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v5 12/13] Documentation: ABI: testing: add docs for ad9910 sysfs entries
2026-05-17 18:37 [PATCH v5 00/13] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
` (10 preceding siblings ...)
2026-05-17 18:37 ` [PATCH v5 11/13] iio: frequency: ad9910: show channel priority in debugfs Rodrigo Alencar via B4 Relay
@ 2026-05-17 18:37 ` Rodrigo Alencar via B4 Relay
2026-05-20 18:47 ` Rodrigo Alencar
2026-05-17 18:37 ` [PATCH v5 13/13] docs: iio: add documentation for ad9910 driver Rodrigo Alencar via B4 Relay
12 siblings, 1 reply; 28+ messages in thread
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add custom ABI documentation file for the DDS AD9910 with sysfs entries to
control Parallel Port, Digital Ramp Generator and OSK parameters.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
.../ABI/testing/sysfs-bus-iio-frequency-ad9910 | 76 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 77 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9910 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9910
new file mode 100644
index 000000000000..934e6e8f0595
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9910
@@ -0,0 +1,76 @@
+What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_offset
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ For a channel that allows frequency control through buffers, this
+ represents the base frequency value in Hz. The actual output frequency
+ is derived from this offset combined with the processed buffer sample
+ value.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_scale
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ For a channel that allows frequency control through buffers, this
+ represents the frequency modulation gain. This value multiplies the
+ buffer input sample value before it is added to a frequency offset.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_phase_offset
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ For a channel that allows phase control through buffers, this
+ represents the base phase value in radians. The actual output phase is
+ derived from this offset combined with the processed buffer sample
+ value.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale_offset
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ For a channel that allows amplitude control through buffers, this
+ represents the value for a base amplitude scale. The actual output
+ amplitude scale is derived from this offset combined with the processed
+ buffer sample value.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_dwell_en
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ For a channel that produces parametric sweeps, this attribute controls
+ the sweep behavior at the configured limits. It enables dwell mode at a
+ sweep limit when set to 1. Otherwise, the sweep may stop at the initial
+ position or restart from that initial position or continue by reversing
+ its direction.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_roc
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ Frequency rate of change in Hz/s for channels that produce linear
+ frequency sweeps. This value may be influenced by the channel's
+ sampling_frequency setting.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_phase_roc
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ Phase rate of change in rad/s for channels that produce linear
+ phase sweeps. This value may be influenced by the channel's
+ sampling_frequency setting.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale_roc
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ Amplitude scale rate of change in 1/s for channels that ramp
+ amplitude. This value may be influenced by the channel's
+ sampling_frequency setting.
+
+What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale_roc_available
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ Lists the available scale_roc values for the channel based on
+ the current sampling_frequency. Values are space-separated in
+ ascending order.
diff --git a/MAINTAINERS b/MAINTAINERS
index b2b7f54f5a24..c39affe4157a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1643,6 +1643,7 @@ M: Rodrigo Alencar <rodrigo.alencar@analog.com>
L: linux-iio@vger.kernel.org
S: Supported
W: https://ez.analog.com/linux-software-drivers
+F: Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9910
F: Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml
F: drivers/iio/frequency/ad9910.c
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread* Re: [PATCH v5 12/13] Documentation: ABI: testing: add docs for ad9910 sysfs entries
2026-05-17 18:37 ` [PATCH v5 12/13] Documentation: ABI: testing: add docs for ad9910 sysfs entries Rodrigo Alencar via B4 Relay
@ 2026-05-20 18:47 ` Rodrigo Alencar
2026-05-22 18:20 ` Jonathan Cameron
0 siblings, 1 reply; 28+ messages in thread
From: Rodrigo Alencar @ 2026-05-20 18:47 UTC (permalink / raw)
To: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
On 26/05/17 07:37PM, Rodrigo Alencar via B4 Relay wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Add custom ABI documentation file for the DDS AD9910 with sysfs entries to
> control Parallel Port, Digital Ramp Generator and OSK parameters.
...
> +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_offset
> +KernelVersion:
> +Contact: linux-iio@vger.kernel.org
> +Description:
> + For a channel that allows frequency control through buffers, this
> + represents the base frequency value in Hz. The actual output frequency
> + is derived from this offset combined with the processed buffer sample
> + value.
> +
> +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_scale
> +KernelVersion:
> +Contact: linux-iio@vger.kernel.org
> +Description:
> + For a channel that allows frequency control through buffers, this
> + represents the frequency modulation gain. This value multiplies the
> + buffer input sample value before it is added to a frequency offset.
> +
> +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_phase_offset
> +KernelVersion:
> +Contact: linux-iio@vger.kernel.org
> +Description:
> + For a channel that allows phase control through buffers, this
> + represents the base phase value in radians. The actual output phase is
> + derived from this offset combined with the processed buffer sample
> + value.
> +
> +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale_offset
> +KernelVersion:
> +Contact: linux-iio@vger.kernel.org
> +Description:
> + For a channel that allows amplitude control through buffers, this
> + represents the value for a base amplitude scale. The actual output
> + amplitude scale is derived from this offset combined with the processed
> + buffer sample value.
> +
This will become just offset with altcurrent channels. I noticed we have a IIO_PHASE
iio_chan_type, could we have a IIO_FREQUENCY too? Parallel port needs actual raw
frequency values in that case to be written to the dma buffer.
Then we may have buffer capable channels for the parallel port:
out_altcurrent120
offset
out_phase120
offset
out_frequency120
scale
offset
Problem is that the math for the actual frequency output is:
f_OUT = f_FTW + (f_RAW * FM)
where f_FTW is a base frequency (already scaled), FM is a
modulation gain and f_RAW is the contribution from the parallel
port, which is the already scaled:
f_RAW = RAW * f_SYSCLK / 2^32
f_FTW = FTW * f_SYSCLK / 2^32
so the above becomes:
f_OUT = (FTW * f_SYSCLK / 2^32) + (RAW * f_SYSCLK / 2^32) * FM
f_OUT = (FTW/FM + RAW) * f_SYSCLK * FM / 2^32
if I make:
SCALE = f_SYSCLK * FM / 2^32
OFFSET = FTW/FM
f_OUT = (OFFSET + RAW) * SCALE
That would work for a IIO_FREQUENCY channel type, problem is that both
scale and offset would depend on the modulation gain (FM)... I suppose
scale should be setting that and offset assumes it is constant to act
only on FTW.
I suppose we can keep altcurrent for other modes as phase and frequency
can be attributes (knobs) for them. However, in parallel mode we are effectively
pushing frequency, phase or amplitude values into the buffer.
The polar destination is a corner case, but can be solved when both
phase and altcurrent channels are enabled. When that happens we can
change the scan_type with has_ext_scan_type = 1, so the 16-bit data
bus is split between the two.
With the above, all of those *_offset and *_scale custom ABI can be dropped.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v5 12/13] Documentation: ABI: testing: add docs for ad9910 sysfs entries
2026-05-20 18:47 ` Rodrigo Alencar
@ 2026-05-22 18:20 ` Jonathan Cameron
0 siblings, 0 replies; 28+ messages in thread
From: Jonathan Cameron @ 2026-05-22 18:20 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
On Wed, 20 May 2026 19:47:25 +0100
Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> On 26/05/17 07:37PM, Rodrigo Alencar via B4 Relay wrote:
> > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > Add custom ABI documentation file for the DDS AD9910 with sysfs entries to
> > control Parallel Port, Digital Ramp Generator and OSK parameters.
>
> ...
>
> > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_offset
> > +KernelVersion:
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + For a channel that allows frequency control through buffers, this
> > + represents the base frequency value in Hz. The actual output frequency
> > + is derived from this offset combined with the processed buffer sample
> > + value.
> > +
> > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_scale
> > +KernelVersion:
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + For a channel that allows frequency control through buffers, this
> > + represents the frequency modulation gain. This value multiplies the
> > + buffer input sample value before it is added to a frequency offset.
> > +
> > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_phase_offset
> > +KernelVersion:
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + For a channel that allows phase control through buffers, this
> > + represents the base phase value in radians. The actual output phase is
> > + derived from this offset combined with the processed buffer sample
> > + value.
> > +
> > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale_offset
> > +KernelVersion:
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + For a channel that allows amplitude control through buffers, this
> > + represents the value for a base amplitude scale. The actual output
> > + amplitude scale is derived from this offset combined with the processed
> > + buffer sample value.
> > +
>
> This will become just offset with altcurrent channels. I noticed we have a IIO_PHASE
> iio_chan_type, could we have a IIO_FREQUENCY too? Parallel port needs actual raw
> frequency values in that case to be written to the dma buffer.
>
Sure to IIO_FREQUENCY. I thought we already did but seems not!
The Phase one is a bit special given it's use in resolvers and distance sensors
but perhaps it is the right solution here.
> Then we may have buffer capable channels for the parallel port:
>
> out_altcurrent120
> offset
So that's the amplitude envelope control.
> out_phase120
> offset
So this is the phase adjustment being controlled.
> out_frequency120
And this is the frequency being controlled.
> scale
> offset
>
> Problem is that the math for the actual frequency output is:
>
> f_OUT = f_FTW + (f_RAW * FM)
>
> where f_FTW is a base frequency (already scaled), FM is a
> modulation gain and f_RAW is the contribution from the parallel
> port, which is the already scaled:
>
> f_RAW = RAW * f_SYSCLK / 2^32
> f_FTW = FTW * f_SYSCLK / 2^32
>
> so the above becomes:
>
> f_OUT = (FTW * f_SYSCLK / 2^32) + (RAW * f_SYSCLK / 2^32) * FM
> f_OUT = (FTW/FM + RAW) * f_SYSCLK * FM / 2^32
>
> if I make:
>
> SCALE = f_SYSCLK * FM / 2^32
> OFFSET = FTW/FM
> f_OUT = (OFFSET + RAW) * SCALE
>
> That would work for a IIO_FREQUENCY channel type, problem is that both
> scale and offset would depend on the modulation gain (FM)... I suppose
> scale should be setting that and offset assumes it is constant to act
> only on FTW.
I'm not that concerned about the coupling - it's a bit of a useability
issue I guess as not obvious which should be the fixed one. Can we do
cache written values and try and compensate to get a pair that is nearest
to whatever we try to drive (in either order of setting them?)
>
> I suppose we can keep altcurrent for other modes as phase and frequency
> can be attributes (knobs) for them. However, in parallel mode we are effectively
> pushing frequency, phase or amplitude values into the buffer.
Given that's the thing we are controlling. My Friday evening tired brain agrees
that it makes sense to use channel types rather than adjustments on something else.
I'll think some more on this. We've never had continuous (well digital
so near continous) control of either phase or frequency before - it's just
be symbol stuff with a couple of points to set.
>
> The polar destination is a corner case, but can be solved when both
> phase and altcurrent channels are enabled. When that happens we can
> change the scan_type with has_ext_scan_type = 1, so the 16-bit data
> bus is split between the two.
>
For now I'll just nod at that!
> With the above, all of those *_offset and *_scale custom ABI can be dropped.
That is definitely attractive :)
Jonathan
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v5 13/13] docs: iio: add documentation for ad9910 driver
2026-05-17 18:37 [PATCH v5 00/13] AD9910 Direct Digital Synthesizer Rodrigo Alencar via B4 Relay
` (11 preceding siblings ...)
2026-05-17 18:37 ` [PATCH v5 12/13] Documentation: ABI: testing: add docs for ad9910 sysfs entries Rodrigo Alencar via B4 Relay
@ 2026-05-17 18:37 ` Rodrigo Alencar via B4 Relay
12 siblings, 0 replies; 28+ messages in thread
From: Rodrigo Alencar via B4 Relay @ 2026-05-17 18:37 UTC (permalink / raw)
To: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva, Rodrigo Alencar
From: Rodrigo Alencar <rodrigo.alencar@analog.com>
Add documentation for the AD9910 DDS IIO driver, which describes channels,
DDS modes, attributes and ABI usage examples.
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
---
Documentation/iio/ad9910.rst | 666 +++++++++++++++++++++++++++++++++++++++++++
Documentation/iio/index.rst | 1 +
MAINTAINERS | 1 +
3 files changed, 668 insertions(+)
diff --git a/Documentation/iio/ad9910.rst b/Documentation/iio/ad9910.rst
new file mode 100644
index 000000000000..dbcf8f8a1dda
--- /dev/null
+++ b/Documentation/iio/ad9910.rst
@@ -0,0 +1,666 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=============
+AD9910 driver
+=============
+
+Direct Digital Synthesizer (DDS) driver for the Analog Devices Inc. AD9910.
+The module name is ``ad9910``.
+
+* `AD9910 <https://www.analog.com/en/products/ad9910.html>`_
+
+The AD9910 is a 1 GSPS DDS with a 14-bit DAC, controlled over SPI. The driver
+exposes the device through the IIO ``altvoltage`` channel type and supports
+five DDS operating modes: single tone, parallel port modulation, digital ramp
+generation (DRG), RAM playback and output shift keying (OSK). The device has
+8 hardware profiles, each capable of storing independent single tone and RAM
+playback parameters.
+
+
+Channel hierarchy
+=================
+
+The driver exposes the following IIO output channels, each identified by a
+unique channel number and a human-readable label. The ``phy`` channel is the
+root of the hierarchy. Changing its ``sampling_frequency`` reconfigures the
+system clock (SYSCLK) which affects all other channels. Most of the
+mode-specific channels have an ``enable`` attribute that turns the mode on/off.
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Channel
+ - Label
+ - Parent
+ - Description
+
+ * - ``out_altvoltage100``
+ - ``phy``
+ -
+ - Physical output: system clock and profile control.
+ See `Physical channel`_.
+
+ * - ``out_altvoltage110`` ... ``out_altvoltage117``
+ - ``profile0`` ... ``profile7``
+ - ``phy``
+ - Single tone control: frequency, phase, amplitude.
+ See `Single Tone mode`_.
+
+ * - ``out_altvoltage120``
+ - ``parallel_port``
+ - ``phy``
+ - Parallel port modulation channel.
+ See `Parallel Port mode`_.
+
+ * - ``out_altvoltage130``
+ - ``digital_ramp_generator``
+ - ``phy``
+ - Digital ramp generator (DRG) control: enable.
+ See `Digital ramp generator (DRG)`_.
+
+ * - ``out_altvoltage131``
+ - ``digital_ramp_up``
+ - ``digital_ramp_generator``
+ - DRG ramp-up parameters: dwell enable, limits, rate of change, ramp rate.
+
+ * - ``out_altvoltage132``
+ - ``digital_ramp_down``
+ - ``digital_ramp_generator``
+ - DRG ramp-down parameters: dwell enable, limits, rate of change, ramp rate.
+
+ * - ``out_altvoltage140``
+ - ``ram_control``
+ - ``phy``
+ - RAM playback: enable, frequency, phase and sampling frequency for active
+ profile. See `RAM mode`_.
+
+ * - ``out_altvoltage150``
+ - ``output_shift_keying``
+ - ``phy``
+ - Output shift keying (OSK): enable, amplitude scale, ramp rate,
+ rate of change control. See `Output Shift Keying (OSK)`_.
+
+DDS modes
+=========
+
+The AD9910 supports multiple modes of operation that can be configured
+independently or in combination. Such modes and their corresponding IIO channels
+are described in this section. Each DDS core parameter (frequency, phase and
+amplitude) value can come from different sources, but only one is active at a
+time. This activation depends on a priority list, which is based on the enable
+and destination configurations for such modes. The following tables are
+extracted from the AD9910 datasheet and summarizes the control parameters for
+each mode and their priority when multiple sources are enabled simultaneously:
+
+.. flat-table:: DDS Frequency Control
+ :header-rows: 1
+
+ * - Priority
+ - Data Source
+ - Conditions
+
+ * - Highest Priority
+ - RAM
+ - RAM enabled and data destination is frequency
+
+ * -
+ - DRG
+ - DRG enabled and data destination is frequency
+
+ * -
+ - Parallel data and Frequency Tuning Word, FTW (frequency_offset)
+ - Parallel data port enabled and data destination is frequency
+
+ * -
+ - FTW register (frequency)
+ - RAM enabled and data destination is not frequency
+
+ * - Lowest Priority
+ - FTW (frequency) in single tone channel for the active profile
+ - All other cases
+
+.. flat-table:: DDS Phase Control
+ :header-rows: 1
+
+ * - Priority
+ - Data Source
+ - Conditions
+
+ * - Highest Priority
+ - RAM
+ - RAM enabled and data destination is phase or polar
+
+ * -
+ - DRG
+ - DRG enabled and data destination is phase
+
+ * -
+ - Parallel data port
+ - Parallel data port enabled and data destination is phase
+
+ * -
+ - Parallel data port and Phase Offset Word, POW register LSBs (phase_offset)
+ - Parallel data port enabled and data destination is polar
+
+ * -
+ - POW register (phase)
+ - RAM enabled and destination is not phase nor polar
+
+ * - Lowest Priority
+ - POW (phase) in single tone channel for the active profile
+ - All other cases
+
+.. flat-table:: DDS Amplitude Control
+ :header-rows: 1
+
+ * - Priority
+ - Data Source
+ - Conditions
+
+ * - Highest Priority
+ - Amplitude Scale Factor, ASF register and OSK generator
+ - OSK enabled
+
+ * -
+ - RAM
+ - RAM enabled and data destination is amplitude or polar
+
+ * -
+ - DRG
+ - DRG enabled and data destination is amplitude
+
+ * -
+ - Parallel data port
+ - Parallel data port enabled and data destination is amplitude
+
+ * -
+ - Parallel data port and ASF register LSBs (scale_offset)
+ - Parallel data port enabled and data destination is polar
+
+ * - Lowest Priority
+ - ASF (scale) in single tone channel for the active profile
+ - (Amplitude scale is already enabled by default)
+
+While debugging or testing, the debug attributes ``frequency_source``,
+``phase_source`` and ``amplitude_source`` can be used to read the label of
+the channel that is actively controlling the correspondent DDS parameter,
+which reflects the priority list described above.
+
+Single Tone mode
+----------------
+
+Single tone is the baseline operating mode. The ``profileY`` channels
+provide enable, frequency, phase and amplitude control:
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Attribute
+ - Unit
+ - Description
+
+ * - ``en``
+ - boolean (0 or 1)
+ - Enable/disable profile Y. Only one profile can be active at a
+ time. Then enabling a profile disables the current active profile.
+ Disabling an active profile brings the device to a powered down state.
+
+ * - ``frequency``
+ - Hz
+ - Output frequency. Range :math:`[0, f_{SYSCLK}/2)`. Stored in the
+ profile's frequency tuning word (FTW).
+
+ * - ``phase``
+ - rad
+ - Phase offset. Range :math:`[0, 2\pi)`. Stored in the profile's phase
+ offset word (POW).
+
+ * - ``scale``
+ - fractional
+ - Amplitude scale factor. Range :math:`[0, 1]`. Stored in the profile's
+ amplitude scale factor (ASF).
+
+Profile switching is allowed while RAM mode is enabled. In that case single tone
+parameters are stored in a shadow register and are not written to hardware until
+RAM mode is disabled.
+
+Usage examples
+^^^^^^^^^^^^^^
+
+Configure a 100 MHz tone in profile to 2 and set it as the active profile:
+
+.. code-block:: bash
+
+ echo 100000000 > /sys/bus/iio/devices/iio:device0/out_altvoltage112_frequency
+ echo 0.5 > /sys/bus/iio/devices/iio:device0/out_altvoltage112_scale
+ echo 0 > /sys/bus/iio/devices/iio:device0/out_altvoltage112_phase
+
+ # Activate profile 2
+ echo 1 > /sys/bus/iio/devices/iio:device0/out_altvoltage112_en
+
+Read back the current single tone frequency:
+
+.. code-block:: bash
+
+ cat /sys/bus/iio/devices/iio:device0/out_altvoltage112_frequency
+
+Parallel Port mode
+------------------
+
+The parallel port allows real-time modulation of DDS parameters through a
+16-bit external data bus.
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Attribute
+ - Unit
+ - Description
+
+ * - ``frequency_scale``
+ - power-of-2
+ - Frequency modulation (FM) gain multiplier applied to 16-bit parallel
+ input. Range :math:`[1, 32768]`, must be a power of 2.
+
+ * - ``frequency_offset``
+ - Hz
+ - Base FTW to which scaled parallel data is added. Range :math:`[0, f_{SYSCLK}/2)`.
+
+ * - ``phase_offset``
+ - rad
+ - Base phase for polar modulation. Lower 8 bits of POW register.
+ Range :math:`[0, 2\pi/256)`.
+
+ * - ``scale_offset``
+ - fractional
+ - Base amplitude for polar modulation. Lower 6 bits of ASF register.
+ Range :math:`[0, 1/256)`.
+
+Usage examples
+^^^^^^^^^^^^^^
+
+Set parallel port frequency modulation with a scale of 16 and a 50 MHz
+offset:
+
+.. code-block:: bash
+
+ echo 16 > /sys/bus/iio/devices/iio:device0/out_altvoltage120_frequency_scale
+ echo 50000000 > /sys/bus/iio/devices/iio:device0/out_altvoltage120_frequency_offset
+
+Digital ramp generator (DRG)
+----------------------------
+
+The DRG produces linear frequency, phase or amplitude sweeps using dedicated
+hardware. It is controlled through three channels: a parent control channel
+(``digital_ramp_generator``) and two child ramp channels
+(``digital_ramp_up``, ``digital_ramp_down``).
+
+The DRG can target only one destination at a time (frequency, phase or
+amplitude). Destination selection follows a "last write wins" policy: writing
+any value (including zero) to a destination-specific attribute (e.g.
+``frequency``, ``frequency_roc``, ``phase``, ``phase_roc``, ``scale`` or
+``scale_roc``) switches the DRG destination accordingly. Reading an attribute
+whose destination is not currently active returns ``-EBUSY``.
+
+Control channel attributes
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Attribute
+ - Unit
+ - Description
+
+ * - ``en``
+ - boolean
+ - Enable/disable the DRG.
+
+Ramp channel attributes
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``digital_ramp_up`` and ``digital_ramp_down`` channels share the same
+attribute set but configure ascending and descending ramp parameters
+independently:
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Attribute
+ - Unit
+ - Description
+
+ * - ``dwell_en``
+ - boolean
+ - Enable dwell at the ramp limit. When disabled, the ramp auto-transitions
+ at this limit without waiting for the DRCTL pin. Disabling both creates a
+ bidirectional continuous ramp (Triangular pattern). Other configurations
+ create a single-shot ramp at the transition of the DRCTL pin: ramp-up
+ only, ramp-down only or bidirectional with dwell at the limits.
+
+ * - ``frequency``
+ - Hz
+ - Frequency ramp limit. Range: :math:`[0, f_{SYSCLK}/2)`. Writing a value
+ sets the ramp destination to frequency. Reading back returns the
+ currently active frequency limit or -EBUSY if other destination is
+ active (phase or amplitude).
+
+ * - ``phase``
+ - rad
+ - Phase ramp limit. Range: :math:`[0, 2\pi)`. Writing a value sets the
+ ramp destination to phase. Reading back returns the currently active
+ phase limit or -EBUSY if other destination is active (frequency or
+ amplitude).
+
+ * - ``scale``
+ - fractional
+ - Amplitude scale ramp limit. Range: :math:`[0, 1)`. Writing a value sets
+ the ramp destination to amplitude. Reading back returns the currently
+ active scale limit or -EBUSY if other destination is active (frequency
+ or phase).
+
+ * - ``sampling_frequency``
+ - Hz
+ - Ramp clock rate. It is controlled by an integer divider so the requested
+ value will adjust to nearest supported value.
+
+ * - ``frequency_roc``
+ - Hz/s
+ - Frequency rate of change. Sets the per-tick frequency increment/decrement
+ based on the current ramp clock rate.
+
+ * - ``phase_roc``
+ - rad/s
+ - Phase rate of change. Sets the per-tick phase increment/decrement based
+ on the current ramp clock rate.
+
+ * - ``scale_roc``
+ - 1/s
+ - Amplitude scale rate of change. Sets the per-tick amplitude scale
+ increment/decrement based on the current ramp clock rate.
+
+Usage examples
+^^^^^^^^^^^^^^
+
+Configure a frequency sweep from 40 MHz to 60 MHz with a rate of change of
+25 GHz/s:
+
+.. code-block:: bash
+
+ # Disable dwell on both limits for a bidirectional continuous ramp
+ echo 0 > /sys/bus/iio/devices/iio:device0/out_altvoltage131_dwell_en
+ echo 0 > /sys/bus/iio/devices/iio:device0/out_altvoltage132_dwell_en
+
+ # Set ramp limits
+ echo 60000000 > /sys/bus/iio/devices/iio:device0/out_altvoltage131_frequency
+ echo 40000000 > /sys/bus/iio/devices/iio:device0/out_altvoltage132_frequency
+
+ # Set ramp rate
+ echo 25000000 > /sys/bus/iio/devices/iio:device0/out_altvoltage131_sampling_frequency
+ echo 25000000 > /sys/bus/iio/devices/iio:device0/out_altvoltage132_sampling_frequency
+
+ # Set frequency rate of change (Hz/s)
+ echo 25000000000 > /sys/bus/iio/devices/iio:device0/out_altvoltage131_frequency_roc
+ echo 25000000000 > /sys/bus/iio/devices/iio:device0/out_altvoltage132_frequency_roc
+
+ # Enable the DRG
+ echo 1 > /sys/bus/iio/devices/iio:device0/out_altvoltage130_en
+
+RAM mode
+--------
+
+The AD9910 contains a 1024 x 32-bit RAM that can be loaded with waveform data
+and played back to modulate frequency, phase, amplitude, or polar (phase +
+amplitude) parameters.
+
+RAM control channel attributes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Attribute
+ - Unit
+ - Description
+
+ * - ``en``
+ - boolean
+ - Enable/disable RAM playback. Toggling swaps profile registers between
+ single tone and RAM configurations across all 8 profiles.
+
+ * - ``frequency``
+ - Hz
+ - Frequency tuning word used as the single tone frequency when
+ RAM destination is not ``frequency``. Range: :math:`[0, f_{SYSCLK}/2)`.
+
+ * - ``phase``
+ - rad
+ - Phase offset word used as the single tone phase when RAM destination
+ is not ``phase``. Range: :math:`[0, 2\pi)`.
+
+ * - ``sampling_frequency``
+ - Hz
+ - RAM playback step rate of the active profile, which controls how fast the
+ address counter advances. It is controlled by an integer divider so the
+ requested value will adjust to nearest supported value.
+
+Loading RAM data
+^^^^^^^^^^^^^^^^
+
+RAM data is loaded through the firmware upload framework. The driver registers
+a firmware upload sysfs entry named ``iio_deviceX:ram``. The firmware data
+follows a binary format (version 1) with an 80-byte header followed by data
+words. All fields are big-endian.
+
+.. flat-table:: RAM firmware header (80 bytes)
+ :header-rows: 1
+
+ * - Offset
+ - Size
+ - Field
+ - Description
+
+ * - 0
+ - 4
+ - ``magic``
+ - Magic number: ``0x00AD9910``
+
+ * - 4
+ - 2
+ - ``version``
+ - Format version: ``0x0001``
+
+ * - 6
+ - 2
+ - ``wcount``
+ - Number of 32-bit RAM data words (0--1024)
+
+ * - 8
+ - 4
+ - ``crc``
+ - CRC32 checksum over ``cfr1``, ``profiles`` and ``words``
+
+ * - 12
+ - 4
+ - ``cfr1``
+ - CFR1 register value. Only RAM-relevant bits are used:
+ bits [30:29] set data destination (00: frequency, 01: phase,
+ 10: amplitude, 11: polar); bits [20:17] set internal profile
+ control (see datasheet Table 14)
+
+ * - 16
+ - 64
+ - ``profiles[0..7]``
+ - 8 sets of 8-byte RAM profile configurations (see below)
+
+ * - 80
+ - 4 x wcount
+ - ``words[]``
+ - RAM data words in reverse order
+
+Each 8-byte profile entry contains:
+
+.. flat-table:: RAM profile entry (8 bytes)
+ :header-rows: 1
+
+ * - Bits
+ - Field
+ - Description
+
+ * - [55:40]
+ - Address step rate
+ - Controls playback speed for this profile
+
+ * - [39:30]
+ - End address
+ - Last RAM address for this profile
+
+ * - [23:14]
+ - Start address
+ - First RAM address for this profile
+
+ * - [5]
+ - No-dwell high
+ - No-dwell at high limit (ramp-up mode)
+
+ * - [3]
+ - Zero-crossing
+ - Zero-crossing enable (direct-switch mode)
+
+ * - [2:0]
+ - Operating mode
+ - 000: direct switch, 001: ramp-up, 010: bidirectional,
+ 011: bidirectional continuous, 100: ramp-up continuous
+
+Usage examples
+^^^^^^^^^^^^^^
+
+Configure RAM mode with firmware data and enable it:
+
+.. code-block:: bash
+
+ # Load RAM data via firmware upload
+ echo 1 > /sys/class/firmware/iio\:device0\:ram/loading
+ cat ad9910-ram.bin > /sys/class/firmware/iio\:device0\:ram/data
+ echo 0 > /sys/class/firmware/iio\:device0\:ram/loading
+
+ # Enable RAM mode
+ echo 1 > /sys/bus/iio/devices/iio:device0/out_altvoltage140_en
+
+Output Shift Keying (OSK)
+-------------------------
+
+OSK controls the output amplitude envelope, allowing the output to be ramped
+on/off rather than switched abruptly.
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Attribute
+ - Unit
+ - Description
+
+ * - ``en``
+ - boolean (0 or 1)
+ - Enable/disable OSK.
+
+ * - ``scale``
+ - fractional
+ - Target amplitude for the OSK ramp. 14-bit ASF field. Range: :math:`[0, 1)`.
+
+ * - ``scale_roc``
+ - 1/s
+ - Amplitude scale rate of change. Writing a non-zero value enables
+ automatic OSK and selects the closest hardware step size. Writing ``0``
+ disables automatic ramping (manual control of the ASF register using
+ ``scale``). Writing the maximum available value enables pin-controlled
+ immediate transition with no ramping.
+
+ * - ``scale_roc_available``
+ - 1/s
+ - Lists the available ``scale_roc`` values based on the current
+ ``sampling_frequency``. The first value is always ``0`` (disabled) and
+ the last value corresponds to pin-controlled immediate mode.
+
+ * - ``sampling_frequency``
+ - Hz
+ - OSK ramp rate. It is controlled by an integer divider so the requested
+ value will adjust to nearest supported value.
+
+Usage examples
+^^^^^^^^^^^^^^
+
+Enable OSK with automatic ramping:
+
+.. code-block:: bash
+
+ # Set ramp rate
+ echo 1000000 > /sys/bus/iio/devices/iio:device0/out_altvoltage150_sampling_frequency
+
+ # Check available rate of change values
+ cat /sys/bus/iio/devices/iio:device0/out_altvoltage150_scale_roc_available
+
+ # Enable automatic OSK with a rate of change
+ echo 61.035000000 > /sys/bus/iio/devices/iio:device0/out_altvoltage150_scale_roc
+
+ # Enable OSK
+ echo 1 > /sys/bus/iio/devices/iio:device0/out_altvoltage150_en
+
+Enable pin-controlled immediate OSK:
+
+.. code-block:: bash
+
+ # Read the last (highest) available value for pin-controlled mode
+ cat /sys/bus/iio/devices/iio:device0/out_altvoltage150_scale_roc_available
+
+ # Enable OSK in manual mode (no rate of change)
+ echo 0 > /sys/bus/iio/devices/iio:device0/out_altvoltage150_scale_roc
+ echo 1 > /sys/bus/iio/devices/iio:device0/out_altvoltage150_en
+
+ # Set target amplitude to full scale
+ echo 1.0 > /sys/bus/iio/devices/iio:device0/out_altvoltage150_scale
+
+Physical channel
+================
+
+The ``phy`` channel provides device-level control:
+
+.. flat-table::
+ :header-rows: 1
+
+ * - Attribute
+ - Unit
+ - Description
+
+ * - ``sampling_frequency``
+ - Hz
+ - System clock (SYSCLK) frequency. When the internal PLL is enabled
+ (via the ``adi,pll-enable`` devicetree property), configures the PLL
+ multiplier (range 420--1000 MHz). Without PLL, the reference clock can
+ only be divided by 2.
+
+ * - ``powerdown``
+ - boolean (0 or 1)
+ - Software power-down. Writing 1 powers down the digital core, DAC,
+ reference clock input and auxiliary DAC simultaneously.
+
+Usage examples
+--------------
+
+Set the system clock to 1 GHz:
+
+.. code-block:: bash
+
+ echo 1000000000 > /sys/bus/iio/devices/iio:device0/out_altvoltage100_sampling_frequency
+
+Read current system clock frequency:
+
+.. code-block:: bash
+
+ cat /sys/bus/iio/devices/iio:device0/out_altvoltage100_sampling_frequency
+
+Power down the device:
+
+.. code-block:: bash
+
+ echo 1 > /sys/bus/iio/devices/iio:device0/out_altvoltage100_powerdown
diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst
index 007e0a1fcc5a..1ada7b460066 100644
--- a/Documentation/iio/index.rst
+++ b/Documentation/iio/index.rst
@@ -30,6 +30,7 @@ Industrial I/O Kernel Drivers
ad7606
ad7625
ad7944
+ ad9910
ade9000
adis16475
adis16480
diff --git a/MAINTAINERS b/MAINTAINERS
index c39affe4157a..363b7af827c3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1645,6 +1645,7 @@ S: Supported
W: https://ez.analog.com/linux-software-drivers
F: Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9910
F: Documentation/devicetree/bindings/iio/frequency/adi,ad9910.yaml
+F: Documentation/iio/ad9910.rst
F: drivers/iio/frequency/ad9910.c
ANALOG DEVICES INC MAX22007 DRIVER
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread