[PATCH 0/5] iio: adc: xilinx-xadc: Add I2C interface support for System Management Wizard

[PATCH 0/5] iio: adc: xilinx-xadc: Add I2C interface support for System Management Wizard

[Sai Krishna Potthuri]

The existing driver only supported AXI memory-mapped access to the System
Management Wizard IP. This series extends the driver to support I2C-based
access, which is particularly useful for System Controller usecases.

Key Changes:
- Extract common probe logic into xadc_device_setup() and
xadc_device_configure().
- Add setup_channels function pointer to ops structure to support
different ways to configure the channels.
- Replace module_platform_driver() macro with custom init and exit
functions to support multiple bus interfaces.
- I2C interface support.
- Convert binding file to YAML format.

Note: We are working on x86 platform support where fixed channel
configuration is used(no DT support). The setup_channels function
pointer introduced in patch 2/3 enables different channel configuration
approaches for various platforms.

Sai Krishna Potthuri (5):
  iio: adc: xilinx-xadc: Add helper functions for the device setup
  iio: adc: xilinx-xadc: Add setup_channels function pointer to ops
    structure
  iio: adc: xilinx-xadc: Replace module macro with custom init/exit
    functions
  iio: adc: xilinx-xadc: Add I2C interface support
  dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

 .../bindings/iio/adc/xilinx-xadc.txt          | 141 ---------
 .../bindings/iio/adc/xilinx-xadc.yaml         | 194 ++++++++++++
 drivers/iio/adc/Kconfig                       |  11 +
 drivers/iio/adc/xilinx-xadc-core.c            | 283 ++++++++++++++++--
 drivers/iio/adc/xilinx-xadc.h                 |   8 +
 5 files changed, 475 insertions(+), 162 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
 create mode 100644 Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml

-- 
2.25.1

[PATCH 1/5] iio: adc: xilinx-xadc: Add helper functions for the device setup

[Sai Krishna Potthuri]

Refactor the platform driver probe function by extracting device
setup and configuration logic into reusable helper functions:
xadc_device_setup(): handles IIO device allocation and basic setup
xadc_device_configure(): handles device tree parsing and bipolar mask
configuration

This refactoring reduces code duplication and prepares for sharing the
common setup logic between platform and I2C drivers.

Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
---
 drivers/iio/adc/xilinx-xadc-core.c | 60 +++++++++++++++++++++---------
 1 file changed, 42 insertions(+), 18 deletions(-)

diff --git a/drivers/iio/adc/xilinx-xadc-core.c b/drivers/iio/adc/xilinx-xadc-core.c
index e257c1b94a5f..52b51821007d 100644
--- a/drivers/iio/adc/xilinx-xadc-core.c
+++ b/drivers/iio/adc/xilinx-xadc-core.c
@@ -1310,6 +1310,44 @@ static void xadc_cancel_delayed_work(void *data)
 	cancel_delayed_work_sync(work);
 }
 
+static struct iio_dev *xadc_device_setup(struct device *dev, int size,
+					 const struct xadc_ops **ops)
+{
+	struct iio_dev *indio_dev;
+
+	*ops = device_get_match_data(dev);
+	if (!*ops)
+		return ERR_PTR(-ENODEV);
+
+	indio_dev = devm_iio_device_alloc(dev, size);
+	if (!indio_dev)
+		return ERR_PTR(-ENOMEM);
+
+	indio_dev->name = xadc_type_names[(*ops)->type];
+	indio_dev->info = &xadc_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+
+	return indio_dev;
+}
+
+static int xadc_device_configure(struct device *dev, struct iio_dev *indio_dev,
+				 int irq, unsigned int *conf0, unsigned int *bipolar_mask)
+{
+	int ret, i;
+
+	ret = xadc_parse_dt(indio_dev, conf0, irq);
+	if (ret)
+		return ret;
+
+	*bipolar_mask = 0;
+	for (i = 0; i < indio_dev->num_channels; i++) {
+		if (indio_dev->channels[i].scan_type.sign == 's')
+			*bipolar_mask |= BIT(indio_dev->channels[i].scan_index);
+	}
+
+	return 0;
+}
+
 static int xadc_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1322,19 +1360,15 @@ static int xadc_probe(struct platform_device *pdev)
 	int irq;
 	int i;
 
-	ops = device_get_match_data(dev);
-	if (!ops)
-		return -EINVAL;
+	indio_dev = xadc_device_setup(dev, sizeof(*xadc), &ops);
+	if (IS_ERR(indio_dev))
+		return PTR_ERR(indio_dev);
 
 	irq = platform_get_irq_optional(pdev, 0);
 	if (irq < 0 &&
 	    (irq != -ENXIO || !(ops->flags & XADC_FLAGS_IRQ_OPTIONAL)))
 		return irq;
 
-	indio_dev = devm_iio_device_alloc(dev, sizeof(*xadc));
-	if (!indio_dev)
-		return -ENOMEM;
-
 	xadc = iio_priv(indio_dev);
 	xadc->ops = ops;
 	init_completion(&xadc->completion);
@@ -1346,11 +1380,7 @@ static int xadc_probe(struct platform_device *pdev)
 	if (IS_ERR(xadc->base))
 		return PTR_ERR(xadc->base);
 
-	indio_dev->name = xadc_type_names[xadc->ops->type];
-	indio_dev->modes = INDIO_DIRECT_MODE;
-	indio_dev->info = &xadc_info;
-
-	ret = xadc_parse_dt(indio_dev, &conf0, irq);
+	ret = xadc_device_configure(dev, indio_dev, irq, &conf0, &bipolar_mask);
 	if (ret)
 		return ret;
 
@@ -1418,12 +1448,6 @@ static int xadc_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	bipolar_mask = 0;
-	for (i = 0; i < indio_dev->num_channels; i++) {
-		if (indio_dev->channels[i].scan_type.sign == 's')
-			bipolar_mask |= BIT(indio_dev->channels[i].scan_index);
-	}
-
 	ret = xadc_write_adc_reg(xadc, XADC_REG_INPUT_MODE(0), bipolar_mask);
 	if (ret)
 		return ret;
-- 
2.25.1

Re: [PATCH 1/5] iio: adc: xilinx-xadc: Add helper functions for the device setup

[Andy Shevchenko]

On Fri, Feb 20, 2026 at 11:09:37AM +0530, Sai Krishna Potthuri wrote:
> Refactor the platform driver probe function by extracting device
> setup and configuration logic into reusable helper functions:
> xadc_device_setup(): handles IIO device allocation and basic setup
> xadc_device_configure(): handles device tree parsing and bipolar mask
> configuration

Reformat text like:

- xadc_device_setup():
  handles IIO device allocation and basic setup

- xadc_device_configure():
  handles device tree parsing and bipolar mask configuration

> This refactoring reduces code duplication and prepares for sharing the
> common setup logic between platform and I2C drivers.

TBH without seeing the rest, this patch looks like an unneeded churn.

...

> +static struct iio_dev *xadc_device_setup(struct device *dev, int size,
> +					 const struct xadc_ops **ops)
> +{
> +	struct iio_dev *indio_dev;
> +
> +	*ops = device_get_match_data(dev);

> +	if (!*ops)
> +		return ERR_PTR(-ENODEV);

This is a dead code as it seems that ops is mandatory. So in case if it's
missed it will mean that the contribution was never ever being tested.
If it's tested, the check above is a dead code and hence no need to put
it here.

> +	indio_dev = devm_iio_device_alloc(dev, size);
> +	if (!indio_dev)
> +		return ERR_PTR(-ENOMEM);
> +
> +	indio_dev->name = xadc_type_names[(*ops)->type];
> +	indio_dev->info = &xadc_info;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +
> +	return indio_dev;
> +}
> +
> +static int xadc_device_configure(struct device *dev, struct iio_dev *indio_dev,
> +				 int irq, unsigned int *conf0, unsigned int *bipolar_mask)
> +{
> +	int ret, i;

Why is 'i' signed? Also see below.

> +
> +	ret = xadc_parse_dt(indio_dev, conf0, irq);
> +	if (ret)
> +		return ret;
> +
> +	*bipolar_mask = 0;
> +	for (i = 0; i < indio_dev->num_channels; i++) {

The iterator is not used outside the loop, hence

	for (unsigned int i = 0; i < indio_dev->num_channels; i++) {

will be good choice.

> +		if (indio_dev->channels[i].scan_type.sign == 's')
> +			*bipolar_mask |= BIT(indio_dev->channels[i].scan_index);
> +	}
> +
> +	return 0;
> +}

-- 
With Best Regards,
Andy Shevchenko

[PATCH 2/5] iio: adc: xilinx-xadc: Add setup_channels function pointer to ops structure

[Sai Krishna Potthuri]

Add setup_channels function pointer to xadc_ops structure to enable
different interfaces to have custom channel setup logic.

Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
---
 drivers/iio/adc/xilinx-xadc-core.c | 8 +++++++-
 drivers/iio/adc/xilinx-xadc.h      | 1 +
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/adc/xilinx-xadc-core.c b/drivers/iio/adc/xilinx-xadc-core.c
index 52b51821007d..ee58b4a80f34 100644
--- a/drivers/iio/adc/xilinx-xadc-core.c
+++ b/drivers/iio/adc/xilinx-xadc-core.c
@@ -35,6 +35,8 @@
 
 #include "xilinx-xadc.h"
 
+static int xadc_parse_dt(struct iio_dev *indio_dev, unsigned int *conf, int irq);
+
 static const unsigned int XADC_ZYNQ_UNMASK_TIMEOUT = 500;
 
 /* ZYNQ register definitions */
@@ -455,6 +457,7 @@ static const struct xadc_ops xadc_zynq_ops = {
 	.get_dclk_rate = xadc_zynq_get_dclk_rate,
 	.interrupt_handler = xadc_zynq_interrupt_handler,
 	.update_alarm = xadc_zynq_update_alarm,
+	.setup_channels = xadc_parse_dt,
 	.type = XADC_TYPE_S7,
 	/* Temp in C = (val * 503.975) / 2**bits - 273.15 */
 	.temp_scale = 503975,
@@ -567,6 +570,7 @@ static const struct xadc_ops xadc_7s_axi_ops = {
 	.get_dclk_rate = xadc_axi_get_dclk,
 	.update_alarm = xadc_axi_update_alarm,
 	.interrupt_handler = xadc_axi_interrupt_handler,
+	.setup_channels = xadc_parse_dt,
 	.flags = XADC_FLAGS_BUFFERED | XADC_FLAGS_IRQ_OPTIONAL,
 	.type = XADC_TYPE_S7,
 	/* Temp in C = (val * 503.975) / 2**bits - 273.15 */
@@ -581,6 +585,7 @@ static const struct xadc_ops xadc_us_axi_ops = {
 	.get_dclk_rate = xadc_axi_get_dclk,
 	.update_alarm = xadc_axi_update_alarm,
 	.interrupt_handler = xadc_axi_interrupt_handler,
+	.setup_channels = xadc_parse_dt,
 	.flags = XADC_FLAGS_BUFFERED | XADC_FLAGS_IRQ_OPTIONAL,
 	.type = XADC_TYPE_US,
 	/**
@@ -1333,9 +1338,10 @@ static struct iio_dev *xadc_device_setup(struct device *dev, int size,
 static int xadc_device_configure(struct device *dev, struct iio_dev *indio_dev,
 				 int irq, unsigned int *conf0, unsigned int *bipolar_mask)
 {
+	struct xadc *xadc = iio_priv(indio_dev);
 	int ret, i;
 
-	ret = xadc_parse_dt(indio_dev, conf0, irq);
+	ret = xadc->ops->setup_channels(indio_dev, conf0, irq);
 	if (ret)
 		return ret;
 
diff --git a/drivers/iio/adc/xilinx-xadc.h b/drivers/iio/adc/xilinx-xadc.h
index b4d9d4683117..26cd65153176 100644
--- a/drivers/iio/adc/xilinx-xadc.h
+++ b/drivers/iio/adc/xilinx-xadc.h
@@ -82,6 +82,7 @@ struct xadc_ops {
 	void (*update_alarm)(struct xadc *xadc, unsigned int alarm);
 	unsigned long (*get_dclk_rate)(struct xadc *xadc);
 	irqreturn_t (*interrupt_handler)(int irq, void *devid);
+	int (*setup_channels)(struct iio_dev *indio_dev, unsigned int *conf, int irq);
 
 	unsigned int flags;
 	enum xadc_type type;
-- 
2.25.1

Re: [PATCH 2/5] iio: adc: xilinx-xadc: Add setup_channels function pointer to ops structure

[Andy Shevchenko]

On Fri, Feb 20, 2026 at 11:09:38AM +0530, Sai Krishna Potthuri wrote:
> Add setup_channels function pointer to xadc_ops structure to enable

Add .setup_channels()...

...to struct xadc_ops to enable...

> different interfaces to have custom channel setup logic.

...

> +static int xadc_parse_dt(struct iio_dev *indio_dev, unsigned int *conf, int irq);

This is a red flag. Why do we need a forward declaration? Bad architecture /
design of the function calls?

-- 
With Best Regards,
Andy Shevchenko

[PATCH 3/5] iio: adc: xilinx-xadc: Replace module macro with custom init/exit functions

[Sai Krishna Potthuri]

Replace module_platform_driver() macro with custom init and exit functions
to prepare for supporting multiple bus interfaces (platform + I2C).

Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
---
 drivers/iio/adc/xilinx-xadc-core.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/adc/xilinx-xadc-core.c b/drivers/iio/adc/xilinx-xadc-core.c
index ee58b4a80f34..4ddc962e4926 100644
--- a/drivers/iio/adc/xilinx-xadc-core.c
+++ b/drivers/iio/adc/xilinx-xadc-core.c
@@ -1476,7 +1476,18 @@ static struct platform_driver xadc_driver = {
 		.of_match_table = xadc_of_match_table,
 	},
 };
-module_platform_driver(xadc_driver);
+
+static int __init xadc_init(void)
+{
+	return platform_driver_register(&xadc_driver);
+}
+module_init(xadc_init);
+
+static void __exit xadc_exit(void)
+{
+	platform_driver_unregister(&xadc_driver);
+}
+module_exit(xadc_exit);
 
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Lars-Peter Clausen <lars@metafoo.de>");
-- 
2.25.1

Re: [PATCH 3/5] iio: adc: xilinx-xadc: Replace module macro with custom init/exit functions

[Andy Shevchenko]

On Fri, Feb 20, 2026 at 11:09:39AM +0530, Sai Krishna Potthuri wrote:
> Replace module_platform_driver() macro with custom init and exit functions
> to prepare for supporting multiple bus interfaces (platform + I2C).

No, this is not how it should be done.
NAK.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/5] iio: adc: xilinx-xadc: Replace module macro with custom init/exit functions

[Michal Simek]

On 2/20/26 08:52, Andy Shevchenko wrote:
> On Fri, Feb 20, 2026 at 11:09:39AM +0530, Sai Krishna Potthuri wrote:
>> Replace module_platform_driver() macro with custom init and exit functions
>> to prepare for supporting multiple bus interfaces (platform + I2C).
> 
> No, this is not how it should be done.

And how should it be done? separate file?
M

Re: [PATCH 3/5] iio: adc: xilinx-xadc: Replace module macro with custom init/exit functions

[Andy Shevchenko]

On Fri, Feb 20, 2026 at 08:54:26AM +0100, Michal Simek wrote:
> On 2/20/26 08:52, Andy Shevchenko wrote:
> > On Fri, Feb 20, 2026 at 11:09:39AM +0530, Sai Krishna Potthuri wrote:
> > > Replace module_platform_driver() macro with custom init and exit functions
> > > to prepare for supporting multiple bus interfaces (platform + I2C).
> > 
> > No, this is not how it should be done.
> 
> And how should it be done? separate file?

I answered somewhere else, but I can elaborate here as well.

The idea, yes, to have the driver in the parts:
 _core.c
 _platform.c
 _i2c.c

To achieve that, it needs first to split the driver followed by likely
conversion to regmap. With that done it may be used in i2c with a little
code added into _i2c.c.

We have examples in kernel for that.

0daede80f870 ("i2c: designware: Convert driver to using regmap API")
fcb82a939df8 ("i2c: designware: Add Baikal-T1 System I2C support")



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/5] iio: adc: xilinx-xadc: Replace module macro with custom init/exit functions

[Sai Krishna Potthuri]

Hi Andy Shevchenko,

On 2/20/2026 1:39 PM, Andy Shevchenko wrote:
> On Fri, Feb 20, 2026 at 08:54:26AM +0100, Michal Simek wrote:
>> On 2/20/26 08:52, Andy Shevchenko wrote:
>>> On Fri, Feb 20, 2026 at 11:09:39AM +0530, Sai Krishna Potthuri wrote:
>>>> Replace module_platform_driver() macro with custom init and exit functions
>>>> to prepare for supporting multiple bus interfaces (platform + I2C).
>>>
>>> No, this is not how it should be done.
>>
>> And how should it be done? separate file?
> 
> I answered somewhere else, but I can elaborate here as well.
> 
> The idea, yes, to have the driver in the parts:
>   _core.c
>   _platform.c
>   _i2c.c
> 
> To achieve that, it needs first to split the driver followed by likely
> conversion to regmap. With that done it may be used in i2c with a little
> code added into _i2c.c.
> 
> We have examples in kernel for that.
> 
> 0daede80f870 ("i2c: designware: Convert driver to using regmap API")
> fcb82a939df8 ("i2c: designware: Add Baikal-T1 System I2C support")

Sorry for the delayed response. I have gone through regmap 
implementation to understand the approach and started converting the 
XADC driver accordingly. During the implementation, I see few challenges 
with using the standard regmap MMIO and I2C interfaces, which requires 
defining custom regmap read/write hooks for both MMIO and I2C.

For the platform/MMIO case,
Zynq platform has its own FIFO-based mechanism for hardware reads and 
writes, whereas the AXI variants require additional offset manipulation 
before accessing the registers. These platform-specific requirements 
force us to use custom read/write implementations rather than the 
standard regmap MMIO helpers.

For the I2C case,
32-bit DRP packet needs to be framed before issuing any I2C 
transactions. Since this packet framing logic is specific to the XADC 
DRP interface, it again requires a custom read/write implementations.

Considering all these, regmap may end up as a wrapper on top of these 
custom xadc_ops read/write functions, which may not add any additional 
value. Since the XADC driver already has the xadc_ops to support custom 
read/write implementations, can we continue using the existing xadc_ops 
read/write paths and skip the regmap conversion?
Please let me know if I am missing anything in my understanding.

I will still proceed with splitting the driver into three files (core,
platform, and I2C), as you suggested.

Regards
Sai Krishna

Re: [PATCH 3/5] iio: adc: xilinx-xadc: Replace module macro with custom init/exit functions

[Andy Shevchenko]

On Wed, Mar 18, 2026 at 02:43:41PM +0530, Sai Krishna Potthuri wrote:
> On 2/20/2026 1:39 PM, Andy Shevchenko wrote:
> > On Fri, Feb 20, 2026 at 08:54:26AM +0100, Michal Simek wrote:
> > > On 2/20/26 08:52, Andy Shevchenko wrote:
> > > > On Fri, Feb 20, 2026 at 11:09:39AM +0530, Sai Krishna Potthuri wrote:
> > > > > Replace module_platform_driver() macro with custom init and exit functions
> > > > > to prepare for supporting multiple bus interfaces (platform + I2C).
> > > > 
> > > > No, this is not how it should be done.
> > > 
> > > And how should it be done? separate file?
> > 
> > I answered somewhere else, but I can elaborate here as well.
> > 
> > The idea, yes, to have the driver in the parts:
> >   _core.c
> >   _platform.c
> >   _i2c.c
> > 
> > To achieve that, it needs first to split the driver followed by likely
> > conversion to regmap. With that done it may be used in i2c with a little
> > code added into _i2c.c.
> > 
> > We have examples in kernel for that.
> > 
> > 0daede80f870 ("i2c: designware: Convert driver to using regmap API")
> > fcb82a939df8 ("i2c: designware: Add Baikal-T1 System I2C support")
> 
> Sorry for the delayed response. I have gone through regmap implementation to
> understand the approach and started converting the XADC driver accordingly.
> During the implementation, I see few challenges with using the standard
> regmap MMIO and I2C interfaces, which requires defining custom regmap
> read/write hooks for both MMIO and I2C.
> 
> For the platform/MMIO case,
> Zynq platform has its own FIFO-based mechanism for hardware reads and
> writes, whereas the AXI variants require additional offset manipulation
> before accessing the registers. These platform-specific requirements force
> us to use custom read/write implementations rather than the standard regmap
> MMIO helpers.
> 
> For the I2C case,
> 32-bit DRP packet needs to be framed before issuing any I2C transactions.
> Since this packet framing logic is specific to the XADC DRP interface, it
> again requires a custom read/write implementations.
> 
> Considering all these, regmap may end up as a wrapper on top of these custom
> xadc_ops read/write functions, which may not add any additional value. Since
> the XADC driver already has the xadc_ops to support custom read/write
> implementations, can we continue using the existing xadc_ops read/write
> paths and skip the regmap conversion?

Thanks for elaboration. Indeed, the regmap approach in this situation gives
not much of benefit (there still is, nevertheless).

So, the compromise may be done in a way that you define custom IO accessors
and respecting callbacks in the private data structure first, then split
the driver to _core and existing _platform driver. Add _i2c on top of this
refactoring.

> Please let me know if I am missing anything in my understanding.

> I will still proceed with splitting the driver into three files (core,
> platform, and I2C), as you suggested.

Sure, this needs to be done independently on regmap.

-- 
With Best Regards,
Andy Shevchenko

[PATCH 4/5] iio: adc: xilinx-xadc: Add I2C interface support

[Sai Krishna Potthuri]

Add I2C interface support for Xilinx System Management Wizard IP along
with the existing AXI memory-mapped interface. This support enables
monitoring the voltage and temperature on UltraScale+ devices where the
System Management Wizard is connected via I2C.

Key changes:
- Implement 32-bit DRP(Dynamic Reconfiguration Port) packet format as per
  Xilinx PG185 specification.
- Add separate I2C probe with xadc_i2c_of_match_table to handle same
  compatible string("xlnx,system-management-wiz-1.3") on I2C bus.
- Implement delayed version of hardware initialization for I2C interface
  to handle the case where System Management Wizard IP is not ready during
  the I2C probe.
- Add xadc_i2c_transaction() function to handle I2C read/write operations
- Add XADC_TYPE_US_I2C type to distinguish I2C interface from AXI.

Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
---
 drivers/iio/adc/Kconfig            |  11 ++
 drivers/iio/adc/xilinx-xadc-core.c | 206 ++++++++++++++++++++++++++++-
 drivers/iio/adc/xilinx-xadc.h      |   7 +
 3 files changed, 221 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 60038ae8dfc4..0c0adac151e4 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -1951,6 +1951,17 @@ config XILINX_XADC
 	  The driver can also be build as a module. If so, the module will be called
 	  xilinx-xadc.
 
+config XILINX_XADC_I2C
+	bool "Xilinx System Management Wizard I2C Interface support"
+	depends on XILINX_XADC && I2C
+	help
+	  Say yes here to allow accessing the System Management
+	  Wizard on UltraScale+ devices via I2C.
+
+	  This provides voltage and temperature monitoring capabilities
+	  through the same IIO sysfs interface, but using I2C communication
+	  protocol.
+
 config XILINX_AMS
 	tristate "Xilinx AMS driver"
 	depends on ARCH_ZYNQMP || COMPILE_TEST
diff --git a/drivers/iio/adc/xilinx-xadc-core.c b/drivers/iio/adc/xilinx-xadc-core.c
index 4ddc962e4926..7644267092ef 100644
--- a/drivers/iio/adc/xilinx-xadc-core.c
+++ b/drivers/iio/adc/xilinx-xadc-core.c
@@ -11,9 +11,12 @@
  *  - AXI XADC interface: Xilinx PG019
  */
 
+#include <linux/bits.h>
+#include <linux/bitfield.h>
 #include <linux/clk.h>
 #include <linux/device.h>
 #include <linux/err.h>
+#include <linux/i2c.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/kernel.h>
@@ -35,6 +38,22 @@
 
 #include "xilinx-xadc.h"
 
+#ifdef CONFIG_XILINX_XADC_I2C
+#define XADC_I2C_READ_DATA_SIZE		2
+#define XADC_I2C_WRITE_DATA_SIZE	4	/* 32-bit DRP packet */
+#define XADC_I2C_INSTR_READ		BIT(2)
+#define XADC_I2C_INSTR_WRITE		BIT(3)
+
+#define XADC_I2C_DRP_DATA0_MASK		GENMASK(7, 0)
+#define XADC_I2C_DRP_DATA1_MASK		GENMASK(15, 8)
+#define XADC_I2C_DRP_ADDR_MASK		GENMASK(7, 0)
+
+struct xadc_i2c {
+	struct xadc xadc;
+	struct i2c_client *client;
+};
+#endif /* CONFIG_XILINX_XADC_I2C */
+
 static int xadc_parse_dt(struct iio_dev *indio_dev, unsigned int *conf, int irq);
 
 static const unsigned int XADC_ZYNQ_UNMASK_TIMEOUT = 500;
@@ -596,6 +615,108 @@ static const struct xadc_ops xadc_us_axi_ops = {
 	.temp_offset = 280231,
 };
 
+#ifdef CONFIG_XILINX_XADC_I2C
+static int xadc_i2c_transaction(struct xadc *xadc, unsigned int reg, uint16_t write_data,
+				bool is_write, uint16_t *read_data)
+{
+	struct xadc_i2c *xadc_i2c = container_of(xadc, struct xadc_i2c, xadc);
+	struct i2c_client *client = xadc_i2c->client;
+	char read_buffer[XADC_I2C_READ_DATA_SIZE];
+	char write_buffer[XADC_I2C_WRITE_DATA_SIZE] = { 0 };
+	int ret;
+
+	if (is_write) {
+		write_buffer[0] = FIELD_GET(XADC_I2C_DRP_DATA0_MASK, write_data);
+		write_buffer[1] = FIELD_GET(XADC_I2C_DRP_DATA1_MASK, write_data);
+		write_buffer[2] = FIELD_GET(XADC_I2C_DRP_ADDR_MASK, reg);
+		write_buffer[3] = XADC_I2C_INSTR_WRITE;
+	} else {
+		write_buffer[2] = FIELD_GET(XADC_I2C_DRP_ADDR_MASK, reg);
+		write_buffer[3] = XADC_I2C_INSTR_READ;
+	}
+
+	ret = i2c_master_send(client, write_buffer, XADC_I2C_WRITE_DATA_SIZE);
+	if (ret < 0)
+		return ret;
+
+	/* Read response for read operations */
+	if (!is_write) {
+		ret = i2c_master_recv(client, read_buffer, XADC_I2C_READ_DATA_SIZE);
+		if (ret < 0)
+			return ret;
+
+		*read_data = FIELD_PREP(XADC_I2C_DRP_DATA0_MASK, read_buffer[0]) |
+				FIELD_PREP(XADC_I2C_DRP_DATA1_MASK, read_buffer[1]);
+	}
+
+	return 0;
+}
+
+static int xadc_hardware_init(struct xadc *xadc)
+{
+	int ret, i;
+
+	for (i = 0; i < 16; i++) {
+		ret = xadc_i2c_transaction(xadc, XADC_REG_THRESHOLD(i), 0, false,
+					   &xadc->threshold[i]);
+		if (ret)
+			return ret;
+	}
+
+	ret = xadc_i2c_transaction(xadc, XADC_REG_CONF0, xadc->conf0, true, NULL);
+	if (ret)
+		return ret;
+
+	ret = xadc_i2c_transaction(xadc, XADC_REG_INPUT_MODE(0), xadc->bipolar_mask, true, NULL);
+	if (ret)
+		return ret;
+
+	ret = xadc_i2c_transaction(xadc, XADC_REG_INPUT_MODE(1), xadc->bipolar_mask >> 16, true,
+				   NULL);
+	if (ret)
+		return ret;
+
+	xadc->hw_initialized = true;
+
+	return 0;
+}
+
+static int xadc_i2c_read_reg(struct xadc *xadc, unsigned int reg, uint16_t *val)
+{
+	if (!xadc->hw_initialized) {
+		int ret;
+
+		ret = xadc_hardware_init(xadc);
+		if (ret)
+			return ret;
+	}
+
+	return xadc_i2c_transaction(xadc, reg, 0, false, val);
+}
+
+static int xadc_i2c_write_reg(struct xadc *xadc, unsigned int reg, uint16_t val)
+{
+	if (!xadc->hw_initialized) {
+		int ret;
+
+		ret = xadc_hardware_init(xadc);
+		if (ret)
+			return ret;
+	}
+
+	return xadc_i2c_transaction(xadc, reg, val, true, NULL);
+}
+
+static const struct xadc_ops xadc_system_mgmt_wiz_i2c_ops = {
+	.read = xadc_i2c_read_reg,
+	.write = xadc_i2c_write_reg,
+	.setup_channels = xadc_parse_dt,
+	.type = XADC_TYPE_US_I2C,
+	.temp_scale = 509314,
+	.temp_offset = 280231,
+};
+#endif /* CONFIG_XILINX_XADC_I2C */
+
 static int _xadc_update_adc_reg(struct xadc *xadc, unsigned int reg,
 	uint16_t mask, uint16_t val)
 {
@@ -782,7 +903,8 @@ static int xadc_power_adc_b(struct xadc *xadc, unsigned int seq_mode)
 	 * non-existing ADC-B powers down the main ADC, so just return and don't
 	 * do anything.
 	 */
-	if (xadc->ops->type == XADC_TYPE_US)
+	if (xadc->ops->type == XADC_TYPE_US ||
+	    xadc->ops->type == XADC_TYPE_US_I2C)
 		return 0;
 
 	/* Powerdown the ADC-B when it is not needed. */
@@ -805,7 +927,8 @@ static int xadc_get_seq_mode(struct xadc *xadc, unsigned long scan_mode)
 	unsigned int aux_scan_mode = scan_mode >> 16;
 
 	/* UltraScale has only one ADC and supports only continuous mode */
-	if (xadc->ops->type == XADC_TYPE_US)
+	if (xadc->ops->type == XADC_TYPE_US ||
+	    xadc->ops->type == XADC_TYPE_US_I2C)
 		return XADC_CONF1_SEQ_CONTINUOUS;
 
 	if (xadc->external_mux_mode == XADC_EXTERNAL_MUX_DUAL)
@@ -1306,6 +1429,7 @@ static int xadc_parse_dt(struct iio_dev *indio_dev, unsigned int *conf, int irq)
 static const char * const xadc_type_names[] = {
 	[XADC_TYPE_S7] = "xadc",
 	[XADC_TYPE_US] = "xilinx-system-monitor",
+	[XADC_TYPE_US_I2C] = "xilinx-system-monitor",
 };
 
 static void xadc_cancel_delayed_work(void *data)
@@ -1469,6 +1593,65 @@ static int xadc_probe(struct platform_device *pdev)
 	return devm_iio_device_register(dev, indio_dev);
 }
 
+#ifdef CONFIG_XILINX_XADC_I2C
+static int xadc_i2c_probe(struct i2c_client *client)
+{
+	struct device *dev = &client->dev;
+	unsigned int conf0, bipolar_mask;
+	const struct xadc_ops *ops;
+	struct iio_dev *indio_dev;
+	struct xadc_i2c *xadc_i2c;
+	struct xadc *xadc;
+	int ret;
+
+	indio_dev = xadc_device_setup(dev, sizeof(*xadc_i2c), &ops);
+	if (IS_ERR(indio_dev))
+		return PTR_ERR(indio_dev);
+
+	xadc_i2c = iio_priv(indio_dev);
+	xadc_i2c->client = client;
+	xadc = &xadc_i2c->xadc;
+	xadc->clk = NULL;
+	xadc->ops = ops;
+	mutex_init(&xadc->mutex);
+	spin_lock_init(&xadc->lock);
+
+	indio_dev->name = xadc_type_names[xadc->ops->type];
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->info = &xadc_info;
+
+	ret = xadc_device_configure(dev, indio_dev, 0, &conf0, &bipolar_mask);
+	if (ret) {
+		dev_err(dev, "Failed to setup the device: %d\n", ret);
+		return ret;
+	}
+
+	i2c_set_clientdata(client, indio_dev);
+	xadc->conf0 = conf0;
+	xadc->bipolar_mask = bipolar_mask;
+	xadc->hw_initialized = false;
+
+	return devm_iio_device_register(dev, indio_dev);
+}
+
+static const struct of_device_id xadc_i2c_of_match_table[] = {
+	{
+		.compatible = "xlnx,system-management-wiz-1.3",
+		.data = &xadc_system_mgmt_wiz_i2c_ops
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, xadc_i2c_of_match_table);
+
+static struct i2c_driver xadc_i2c_driver = {
+	.probe = xadc_i2c_probe,
+	.driver = {
+		.name = "xadc-i2c",
+		.of_match_table = xadc_i2c_of_match_table,
+	},
+};
+#endif /* CONFIG_XILINX_XADC_I2C */
+
 static struct platform_driver xadc_driver = {
 	.probe = xadc_probe,
 	.driver = {
@@ -1479,12 +1662,29 @@ static struct platform_driver xadc_driver = {
 
 static int __init xadc_init(void)
 {
-	return platform_driver_register(&xadc_driver);
+	int ret;
+
+	ret = platform_driver_register(&xadc_driver);
+	if (ret)
+		return ret;
+
+#ifdef CONFIG_XILINX_XADC_I2C
+	ret = i2c_add_driver(&xadc_i2c_driver);
+	if (ret) {
+		platform_driver_unregister(&xadc_driver);
+		return ret;
+	}
+#endif
+
+	return 0;
 }
 module_init(xadc_init);
 
 static void __exit xadc_exit(void)
 {
+#ifdef CONFIG_XILINX_XADC_I2C
+	i2c_del_driver(&xadc_i2c_driver);
+#endif
 	platform_driver_unregister(&xadc_driver);
 }
 module_exit(xadc_exit);
diff --git a/drivers/iio/adc/xilinx-xadc.h b/drivers/iio/adc/xilinx-xadc.h
index 26cd65153176..4bcafd419df2 100644
--- a/drivers/iio/adc/xilinx-xadc.h
+++ b/drivers/iio/adc/xilinx-xadc.h
@@ -63,6 +63,12 @@ struct xadc {
 	unsigned int zynq_intmask;
 	struct delayed_work zynq_unmask_work;
 
+#ifdef CONFIG_XILINX_XADC_I2C
+	bool hw_initialized;
+	unsigned int conf0;
+	unsigned int bipolar_mask;
+#endif
+
 	struct mutex mutex;
 	spinlock_t lock;
 
@@ -72,6 +78,7 @@ struct xadc {
 enum xadc_type {
 	XADC_TYPE_S7, /* Series 7 */
 	XADC_TYPE_US, /* UltraScale and UltraScale+ */
+	XADC_TYPE_US_I2C, /* UltraScale+ I2C interface */
 };
 
 struct xadc_ops {
-- 
2.25.1

Re: [PATCH 4/5] iio: adc: xilinx-xadc: Add I2C interface support

[Andy Shevchenko]

On Fri, Feb 20, 2026 at 11:09:40AM +0530, Sai Krishna Potthuri wrote:
> Add I2C interface support for Xilinx System Management Wizard IP along
> with the existing AXI memory-mapped interface. This support enables
> monitoring the voltage and temperature on UltraScale+ devices where the
> System Management Wizard is connected via I2C.
> 
> Key changes:
> - Implement 32-bit DRP(Dynamic Reconfiguration Port) packet format as per
>   Xilinx PG185 specification.
> - Add separate I2C probe with xadc_i2c_of_match_table to handle same
>   compatible string("xlnx,system-management-wiz-1.3") on I2C bus.
> - Implement delayed version of hardware initialization for I2C interface
>   to handle the case where System Management Wizard IP is not ready during
>   the I2C probe.
> - Add xadc_i2c_transaction() function to handle I2C read/write operations
> - Add XADC_TYPE_US_I2C type to distinguish I2C interface from AXI.

...

>  #include <linux/device.h>
>  #include <linux/err.h>
> +#include <linux/i2c.h>

No, split driver to a few files:
_core.c
_platform.c
_i2c.c

The last two will be just a glue code.

...

> +#ifdef CONFIG_XILINX_XADC_I2C

No way for ugly ifdeffery!

...

> +static int xadc_i2c_transaction(struct xadc *xadc, unsigned int reg, uint16_t write_data,
> +				bool is_write, uint16_t *read_data)

Should be simply u16.

...

> +	char write_buffer[XADC_I2C_WRITE_DATA_SIZE] = { 0 };

No '0' is needed.

...

> +	if (is_write) {

Bad design. Instead make two functions, one for read, one for write and drop
the boolean parameter.

> +	} else {
> +	}

> +	/* Read response for read operations */
> +	if (!is_write) {

> +	}

...

> +static int xadc_hardware_init(struct xadc *xadc)
> +{
> +	int ret, i;

Use unsigned iterator inside the loop.

> +	for (i = 0; i < 16; i++) {

Magic 16.

> +		ret = xadc_i2c_transaction(xadc, XADC_REG_THRESHOLD(i), 0, false,
> +					   &xadc->threshold[i]);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	ret = xadc_i2c_transaction(xadc, XADC_REG_CONF0, xadc->conf0, true, NULL);
> +	if (ret)
> +		return ret;
> +
> +	ret = xadc_i2c_transaction(xadc, XADC_REG_INPUT_MODE(0), xadc->bipolar_mask, true, NULL);
> +	if (ret)
> +		return ret;
> +
> +	ret = xadc_i2c_transaction(xadc, XADC_REG_INPUT_MODE(1), xadc->bipolar_mask >> 16, true,
> +				   NULL);
> +	if (ret)
> +		return ret;
> +
> +	xadc->hw_initialized = true;
> +
> +	return 0;
> +}

...

> +static const struct of_device_id xadc_i2c_of_match_table[] = {
> +	{
> +		.compatible = "xlnx,system-management-wiz-1.3",
> +		.data = &xadc_system_mgmt_wiz_i2c_ops

Leave trailing comma as it's not a sentinel.

> +	},
> +	{ },

The opposite. IIO has established way besides the fact that sentinel by
definition must be the last, trailing comma is confusing for a bare minimum.

> +};

-- 
With Best Regards,
Andy Shevchenko

[PATCH 5/5] dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

[Sai Krishna Potthuri]

Convert the xilinx-xadc.txt Devicetree binding to a YAML schema format
and remove the old text binding.

Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
---
 .../bindings/iio/adc/xilinx-xadc.txt          | 141 -------------
 .../bindings/iio/adc/xilinx-xadc.yaml         | 194 ++++++++++++++++++
 2 files changed, 194 insertions(+), 141 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
 create mode 100644 Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml

diff --git a/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
deleted file mode 100644
index f42e18078376..000000000000
--- a/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
+++ /dev/null
@@ -1,141 +0,0 @@
-Xilinx XADC device driver
-
-This binding document describes the bindings for the Xilinx 7 Series XADC as well
-as the UltraScale/UltraScale+ System Monitor.
-
-The Xilinx XADC is an ADC that can be found in the Series 7 FPGAs from Xilinx.
-The XADC has a DRP interface for communication. Currently two different
-frontends for the DRP interface exist. One that is only available on the ZYNQ
-family as a hardmacro in the SoC portion of the ZYNQ. The other one is available
-on all series 7 platforms and is a softmacro with a AXI interface. This binding
-document describes the bindings for both of them since the bindings are very
-similar.
-
-The Xilinx System Monitor is an ADC that is found in the UltraScale and
-UltraScale+ FPGAs from Xilinx. The System Monitor provides a DRP interface for
-communication. Xilinx provides a standard IP core that can be used to access the
-System Monitor through an AXI interface in the FPGA fabric. This IP core is
-called the Xilinx System Management Wizard. This document describes the bindings
-for this IP.
-
-Required properties:
-	- compatible: Should be one of
-		* "xlnx,zynq-xadc-1.00.a": When using the ZYNQ device
-		  configuration interface to interface to the XADC hardmacro.
-		* "xlnx,axi-xadc-1.00.a": When using the axi-xadc pcore to
-		  interface to the XADC hardmacro.
-		* "xlnx,system-management-wiz-1.3": When using the
-		  Xilinx System Management Wizard fabric IP core to access the
-		  UltraScale and UltraScale+ System Monitor.
-	- reg: Address and length of the register set for the device
-	- interrupts: Interrupt for the XADC control interface.
-	- clocks: When using the ZYNQ this must be the ZYNQ PCAP clock,
-	  when using the axi-xadc or the axi-system-management-wizard this must be
-	  the clock that provides the clock to the AXI bus interface of the core.
-
-Optional properties:
-	- xlnx,external-mux:
-		* "none": No external multiplexer is used, this is the default
-		  if the property is omitted.
-		* "single": External multiplexer mode is used with one
-		   multiplexer.
-		* "dual": External multiplexer mode is used with two
-		  multiplexers for simultaneous sampling.
-	- xlnx,external-mux-channel: Configures which pair of pins is used to
-	  sample data in external mux mode.
-	  Valid values for single external multiplexer mode are:
-		0: VP/VN
-		1: VAUXP[0]/VAUXN[0]
-		2: VAUXP[1]/VAUXN[1]
-		...
-		16: VAUXP[15]/VAUXN[15]
-	  Valid values for dual external multiplexer mode are:
-		1: VAUXP[0]/VAUXN[0] - VAUXP[8]/VAUXN[8]
-		2: VAUXP[1]/VAUXN[1] - VAUXP[9]/VAUXN[9]
-		...
-		8: VAUXP[7]/VAUXN[7] - VAUXP[15]/VAUXN[15]
-
-	  This property needs to be present if the device is configured for
-	  external multiplexer mode (either single or dual). If the device is
-	  not using external multiplexer mode the property is ignored.
-	- xnlx,channels: List of external channels that are connected to the ADC
-	  Required properties:
-		* #address-cells: Should be 1.
-		* #size-cells: Should be 0.
-
-	  The child nodes of this node represent the external channels which are
-	  connected to the ADC. If the property is no present no external
-	  channels will be assumed to be connected.
-
-	  Each child node represents one channel and has the following
-	  properties:
-		Required properties:
-			* reg: Pair of pins the channel is connected to.
-				0: VP/VN
-				1: VAUXP[0]/VAUXN[0]
-				2: VAUXP[1]/VAUXN[1]
-				...
-				16: VAUXP[15]/VAUXN[15]
-			  Note each channel number should only be used at most
-			  once.
-		Optional properties:
-			* xlnx,bipolar: If set the channel is used in bipolar
-			  mode.
-
-
-Examples:
-	xadc@f8007100 {
-		compatible = "xlnx,zynq-xadc-1.00.a";
-		reg = <0xf8007100 0x20>;
-		interrupts = <0 7 4>;
-		interrupt-parent = <&gic>;
-		clocks = <&pcap_clk>;
-
-		xlnx,channels {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			channel@0 {
-				reg = <0>;
-			};
-			channel@1 {
-				reg = <1>;
-			};
-			channel@8 {
-				reg = <8>;
-			};
-		};
-	};
-
-	xadc@43200000 {
-		compatible = "xlnx,axi-xadc-1.00.a";
-		reg = <0x43200000 0x1000>;
-		interrupts = <0 53 4>;
-		interrupt-parent = <&gic>;
-		clocks = <&fpga1_clk>;
-
-		xlnx,channels {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			channel@0 {
-				reg = <0>;
-				xlnx,bipolar;
-			};
-		};
-	};
-
-	adc@80000000 {
-		compatible = "xlnx,system-management-wiz-1.3";
-		reg = <0x80000000 0x1000>;
-		interrupts = <0 81 4>;
-		interrupt-parent = <&gic>;
-		clocks = <&fpga1_clk>;
-
-		xlnx,channels {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			channel@0 {
-				reg = <0>;
-				xlnx,bipolar;
-			};
-		};
-	};
diff --git a/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml
new file mode 100644
index 000000000000..17508fef1f43
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml
@@ -0,0 +1,194 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/xilinx-xadc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx XADC and System Monitor ADC
+
+description:
+  The Xilinx XADC is an ADC that can be found in the Series 7 FPGAs from Xilinx.
+  The XADC has a DRP interface for communication. Currently two different
+  frontends for the DRP interface exist. One that is only available on the ZYNQ
+  family as a hardmacro in the SoC portion of the ZYNQ. The other one is available
+  on all series 7 platforms and is a softmacro with an AXI interface.
+
+  The Xilinx System Monitor is an ADC that is found in the UltraScale and
+  UltraScale+ FPGAs from Xilinx. The System Monitor provides a DRP interface for
+  communication. Xilinx provides a standard IP core that can be used to access the
+  System Monitor through an AXI interface in the FPGA fabric. This IP core is
+  called the Xilinx System Management Wizard.
+
+  The System Management Wizard can also be accessed via I2C interface for remote
+  monitoring scenarios where the system Management Wizard is located on a different chip.
+
+maintainers:
+  - Lars-Peter Clausen <lars@metafoo.de>
+  - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
+
+properties:
+  compatible:
+    enum:
+      - xlnx,zynq-xadc-1.00.a
+      - xlnx,axi-xadc-1.00.a
+      - xlnx,system-management-wiz-1.3
+      - xlnx,system-management-wiz-1.3-remote
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+    description:
+      When using the ZYNQ this must be the ZYNQ PCAP clock,
+      when using the axi-xadc or the axi-system-management-wizard this must be
+      the clock that provides the clock to the AXI bus interface of the core.
+
+  xlnx,external-mux:
+    $ref: /schemas/types.yaml#/definitions/string
+    enum:
+      - none
+      - single
+      - dual
+    default: none
+    description: |
+      External multiplexer configuration:
+      - "none": No external multiplexer is used (default)
+      - "single": External multiplexer mode is used with one multiplexer
+      - "dual": External multiplexer mode is used with two multiplexers
+        for simultaneous sampling
+
+  xlnx,external-mux-channel:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 0
+    maximum: 16
+    description: |
+      Configures which pair of pins is used to sample data in external mux mode.
+      Valid values for single external multiplexer mode are 0-16:
+      0: VP/VN
+      1-16: VAUXP[0-15]/VAUXN[0-15]
+      Valid values for dual external multiplexer mode are 1-8:
+      1-8: VAUXP[0-7]/VAUXN[0-7] - VAUXP[8-15]/VAUXN[8-15]
+      This property needs to be present if the device is configured for
+      external multiplexer mode (either single or dual).
+
+  xlnx,channels:
+    $ref: '#/$defs/channels'
+
+allOf:
+  - if:
+      required:
+        - xlnx,external-mux
+      properties:
+        xlnx,external-mux:
+          enum:
+            - single
+            - dual
+    then:
+      required:
+        - xlnx,external-mux-channel
+
+required:
+  - compatible
+  - reg
+
+unevaluatedProperties: false
+
+$defs:
+  channels:
+    type: object
+    description: List of external channels that are connected to the ADC
+    properties:
+      '#address-cells':
+        const: 1
+      '#size-cells':
+        const: 0
+
+    patternProperties:
+      "^channel@([0-9]|1[0-6])$":
+        type: object
+        properties:
+          reg:
+            minimum: 0
+            maximum: 16
+            description: |
+              Pair of pins the channel is connected to:
+                0: VP/VN
+                1-16: VAUXP[0-15]/VAUXN[0-15]
+              Note each channel number should only be used at most once.
+
+          xlnx,bipolar:
+            type: boolean
+            description: If set, the channel is used in bipolar mode
+
+        required:
+          - reg
+
+        unevaluatedProperties: false
+
+    required:
+      - '#address-cells'
+      - '#size-cells'
+
+    unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    xadc@f8007100 {
+        compatible = "xlnx,zynq-xadc-1.00.a";
+        reg = <0xf8007100 0x20>;
+        interrupts = <0 7 4>;
+        clocks = <&pcap_clk>;
+
+        xlnx,channels {
+            #address-cells = <1>;
+            #size-cells = <0>;
+            channel@0 {
+                reg = <0>;
+            };
+            channel@1 {
+                reg = <1>;
+            };
+            channel@8 {
+                reg = <8>;
+            };
+        };
+    };
+
+  - |
+    xadc@43200000 {
+        compatible = "xlnx,axi-xadc-1.00.a";
+        reg = <0x43200000 0x1000>;
+        interrupts = <0 53 4>;
+        clocks = <&fpga1_clk>;
+
+        xlnx,channels {
+            #address-cells = <1>;
+            #size-cells = <0>;
+            channel@0 {
+                reg = <0>;
+                xlnx,bipolar;
+            };
+        };
+    };
+
+  - |
+    adc@80000000 {
+        compatible = "xlnx,system-management-wiz-1.3";
+        reg = <0x80000000 0x1000>;
+        interrupts = <0 81 4>;
+        clocks = <&fpga1_clk>;
+
+        xlnx,channels {
+            #address-cells = <1>;
+            #size-cells = <0>;
+            channel@0 {
+                reg = <0>;
+                xlnx,bipolar;
+            };
+        };
+    };
-- 
2.25.1

Re: [PATCH 5/5] dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

[Krzysztof Kozlowski]

On Fri, Feb 20, 2026 at 11:09:41AM +0530, Sai Krishna Potthuri wrote:
> Convert the xilinx-xadc.txt Devicetree binding to a YAML schema format
> and remove the old text binding.
> 
> Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
> ---
>  .../bindings/iio/adc/xilinx-xadc.txt          | 141 -------------
>  .../bindings/iio/adc/xilinx-xadc.yaml         | 194 ++++++++++++++++++
>  2 files changed, 194 insertions(+), 141 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
> deleted file mode 100644
> index f42e18078376..000000000000
> --- a/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
> +++ /dev/null
> @@ -1,141 +0,0 @@
> -Xilinx XADC device driver
> -
> -This binding document describes the bindings for the Xilinx 7 Series XADC as well
> -as the UltraScale/UltraScale+ System Monitor.
> -
> -The Xilinx XADC is an ADC that can be found in the Series 7 FPGAs from Xilinx.
> -The XADC has a DRP interface for communication. Currently two different
> -frontends for the DRP interface exist. One that is only available on the ZYNQ
> -family as a hardmacro in the SoC portion of the ZYNQ. The other one is available
> -on all series 7 platforms and is a softmacro with a AXI interface. This binding
> -document describes the bindings for both of them since the bindings are very
> -similar.
> -
> -The Xilinx System Monitor is an ADC that is found in the UltraScale and
> -UltraScale+ FPGAs from Xilinx. The System Monitor provides a DRP interface for
> -communication. Xilinx provides a standard IP core that can be used to access the
> -System Monitor through an AXI interface in the FPGA fabric. This IP core is
> -called the Xilinx System Management Wizard. This document describes the bindings
> -for this IP.
> -
> -Required properties:
> -	- compatible: Should be one of
> -		* "xlnx,zynq-xadc-1.00.a": When using the ZYNQ device
> -		  configuration interface to interface to the XADC hardmacro.
> -		* "xlnx,axi-xadc-1.00.a": When using the axi-xadc pcore to
> -		  interface to the XADC hardmacro.
> -		* "xlnx,system-management-wiz-1.3": When using the
> -		  Xilinx System Management Wizard fabric IP core to access the
> -		  UltraScale and UltraScale+ System Monitor.
> -	- reg: Address and length of the register set for the device
> -	- interrupts: Interrupt for the XADC control interface.
> -	- clocks: When using the ZYNQ this must be the ZYNQ PCAP clock,
> -	  when using the axi-xadc or the axi-system-management-wizard this must be
> -	  the clock that provides the clock to the AXI bus interface of the core.
> -
> -Optional properties:
> -	- xlnx,external-mux:
> -		* "none": No external multiplexer is used, this is the default
> -		  if the property is omitted.
> -		* "single": External multiplexer mode is used with one
> -		   multiplexer.
> -		* "dual": External multiplexer mode is used with two
> -		  multiplexers for simultaneous sampling.
> -	- xlnx,external-mux-channel: Configures which pair of pins is used to
> -	  sample data in external mux mode.
> -	  Valid values for single external multiplexer mode are:
> -		0: VP/VN
> -		1: VAUXP[0]/VAUXN[0]
> -		2: VAUXP[1]/VAUXN[1]
> -		...
> -		16: VAUXP[15]/VAUXN[15]
> -	  Valid values for dual external multiplexer mode are:
> -		1: VAUXP[0]/VAUXN[0] - VAUXP[8]/VAUXN[8]
> -		2: VAUXP[1]/VAUXN[1] - VAUXP[9]/VAUXN[9]
> -		...
> -		8: VAUXP[7]/VAUXN[7] - VAUXP[15]/VAUXN[15]
> -
> -	  This property needs to be present if the device is configured for
> -	  external multiplexer mode (either single or dual). If the device is
> -	  not using external multiplexer mode the property is ignored.
> -	- xnlx,channels: List of external channels that are connected to the ADC
> -	  Required properties:
> -		* #address-cells: Should be 1.
> -		* #size-cells: Should be 0.
> -
> -	  The child nodes of this node represent the external channels which are
> -	  connected to the ADC. If the property is no present no external
> -	  channels will be assumed to be connected.
> -
> -	  Each child node represents one channel and has the following
> -	  properties:
> -		Required properties:
> -			* reg: Pair of pins the channel is connected to.
> -				0: VP/VN
> -				1: VAUXP[0]/VAUXN[0]
> -				2: VAUXP[1]/VAUXN[1]
> -				...
> -				16: VAUXP[15]/VAUXN[15]
> -			  Note each channel number should only be used at most
> -			  once.
> -		Optional properties:
> -			* xlnx,bipolar: If set the channel is used in bipolar
> -			  mode.
> -
> -
> -Examples:
> -	xadc@f8007100 {
> -		compatible = "xlnx,zynq-xadc-1.00.a";
> -		reg = <0xf8007100 0x20>;
> -		interrupts = <0 7 4>;
> -		interrupt-parent = <&gic>;
> -		clocks = <&pcap_clk>;
> -
> -		xlnx,channels {
> -			#address-cells = <1>;
> -			#size-cells = <0>;
> -			channel@0 {
> -				reg = <0>;
> -			};
> -			channel@1 {
> -				reg = <1>;
> -			};
> -			channel@8 {
> -				reg = <8>;
> -			};
> -		};
> -	};
> -
> -	xadc@43200000 {
> -		compatible = "xlnx,axi-xadc-1.00.a";
> -		reg = <0x43200000 0x1000>;
> -		interrupts = <0 53 4>;
> -		interrupt-parent = <&gic>;
> -		clocks = <&fpga1_clk>;
> -
> -		xlnx,channels {
> -			#address-cells = <1>;
> -			#size-cells = <0>;
> -			channel@0 {
> -				reg = <0>;
> -				xlnx,bipolar;
> -			};
> -		};
> -	};
> -
> -	adc@80000000 {
> -		compatible = "xlnx,system-management-wiz-1.3";
> -		reg = <0x80000000 0x1000>;
> -		interrupts = <0 81 4>;
> -		interrupt-parent = <&gic>;
> -		clocks = <&fpga1_clk>;
> -
> -		xlnx,channels {
> -			#address-cells = <1>;
> -			#size-cells = <0>;
> -			channel@0 {
> -				reg = <0>;
> -				xlnx,bipolar;
> -			};
> -		};
> -	};
> diff --git a/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml
> new file mode 100644
> index 000000000000..17508fef1f43
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml

Filename matching compatible, e.g. xlnx,axi-xadc.yaml


> @@ -0,0 +1,194 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/xilinx-xadc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xilinx XADC and System Monitor ADC
> +
> +description:
> +  The Xilinx XADC is an ADC that can be found in the Series 7 FPGAs from Xilinx.
> +  The XADC has a DRP interface for communication. Currently two different
> +  frontends for the DRP interface exist. One that is only available on the ZYNQ
> +  family as a hardmacro in the SoC portion of the ZYNQ. The other one is available
> +  on all series 7 platforms and is a softmacro with an AXI interface.
> +
> +  The Xilinx System Monitor is an ADC that is found in the UltraScale and
> +  UltraScale+ FPGAs from Xilinx. The System Monitor provides a DRP interface for
> +  communication. Xilinx provides a standard IP core that can be used to access the
> +  System Monitor through an AXI interface in the FPGA fabric. This IP core is
> +  called the Xilinx System Management Wizard.
> +
> +  The System Management Wizard can also be accessed via I2C interface for remote
> +  monitoring scenarios where the system Management Wizard is located on a different chip.

Not wrapped correctly. Please read coding style.

> +
> +maintainers:
> +  - Lars-Peter Clausen <lars@metafoo.de>
> +  - Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - xlnx,zynq-xadc-1.00.a
> +      - xlnx,axi-xadc-1.00.a
> +      - xlnx,system-management-wiz-1.3
> +      - xlnx,system-management-wiz-1.3-remote

There was no such compatible and nothing explains why it appeared. You
cannot just add new ABI and claim it is just a conversion.

> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +    description:
> +      When using the ZYNQ this must be the ZYNQ PCAP clock,
> +      when using the axi-xadc or the axi-system-management-wizard this must be
> +      the clock that provides the clock to the AXI bus interface of the core.
> +
> +  xlnx,external-mux:
> +    $ref: /schemas/types.yaml#/definitions/string
> +    enum:
> +      - none
> +      - single
> +      - dual
> +    default: none
> +    description: |
> +      External multiplexer configuration:
> +      - "none": No external multiplexer is used (default)

Drop "default", don't repeat constraints in free form text.

> +      - "single": External multiplexer mode is used with one multiplexer
> +      - "dual": External multiplexer mode is used with two multiplexers
> +        for simultaneous sampling
> +
> +  xlnx,external-mux-channel:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0
> +    maximum: 16
> +    description: |
> +      Configures which pair of pins is used to sample data in external mux mode.
> +      Valid values for single external multiplexer mode are 0-16:
> +      0: VP/VN
> +      1-16: VAUXP[0-15]/VAUXN[0-15]
> +      Valid values for dual external multiplexer mode are 1-8:
> +      1-8: VAUXP[0-7]/VAUXN[0-7] - VAUXP[8-15]/VAUXN[8-15]
> +      This property needs to be present if the device is configured for
> +      external multiplexer mode (either single or dual).
> +
> +  xlnx,channels:
> +    $ref: '#/$defs/channels'
> +
> +allOf:

Missing ref since you use unevaluatedProperties...

> +  - if:
> +      required:
> +        - xlnx,external-mux
> +      properties:
> +        xlnx,external-mux:
> +          enum:
> +            - single
> +            - dual
> +    then:
> +      required:
> +        - xlnx,external-mux-channel
> +
> +required:
> +  - compatible
> +  - reg
> +
> +unevaluatedProperties: false

or you meant additionalProperties?

> +
> +$defs:

Why this is a def, not used directly? I see only one usage of this def.

> +  channels:
> +    type: object
> +    description: List of external channels that are connected to the ADC
> +    properties:
> +      '#address-cells':
> +        const: 1
> +      '#size-cells':
> +        const: 0
> +
> +    patternProperties:
> +      "^channel@([0-9]|1[0-6])$":
> +        type: object
> +        properties:
> +          reg:
> +            minimum: 0
> +            maximum: 16
> +            description: |
> +              Pair of pins the channel is connected to:
> +                0: VP/VN
> +                1-16: VAUXP[0-15]/VAUXN[0-15]
> +              Note each channel number should only be used at most once.
> +
> +          xlnx,bipolar:
> +            type: boolean
> +            description: If set, the channel is used in bipolar mode
> +
> +        required:
> +          - reg
> +
> +        unevaluatedProperties: false

Again, where is any $ref?

> +
> +    required:
> +      - '#address-cells'
> +      - '#size-cells'
> +
> +    unevaluatedProperties: false

And here, please read writing schema and writing bindings docs.

> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    xadc@f8007100 {

adc

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
If you cannot find a name matching your device, please check in kernel
sources for similar cases or you can grow the spec (via pull request to
DT spec repo).

> +        compatible = "xlnx,zynq-xadc-1.00.a";
> +        reg = <0xf8007100 0x20>;
> +        interrupts = <0 7 4>;

Use proper defines.

> +        clocks = <&pcap_clk>;
> +
> +        xlnx,channels {
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +            channel@0 {
> +                reg = <0>;
> +            };
> +            channel@1 {
> +                reg = <1>;
> +            };
> +            channel@8 {
> +                reg = <8>;
> +            };
> +        };
> +    };
> +
> +  - |
> +    xadc@43200000 {

One example is enough, I don't see differences here.

> +        compatible = "xlnx,axi-xadc-1.00.a";
> +        reg = <0x43200000 0x1000>;
> +        interrupts = <0 53 4>;
> +        clocks = <&fpga1_clk>;
> +
> +        xlnx,channels {
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +            channel@0 {
> +                reg = <0>;
> +                xlnx,bipolar;
> +            };
> +        };
> +    };
> +
> +  - |
> +    adc@80000000 {

Again, one example is enough, unless you have multiple differences in
properties.

Best regards,
Krzysztof

Re: [PATCH 5/5] dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

[Sai Krishna Potthuri]

Hi Krzysztof,

On 2/21/2026 4:08 PM, Krzysztof Kozlowski wrote:
> On Fri, Feb 20, 2026 at 11:09:41AM +0530, Sai Krishna Potthuri wrote:
>> Convert the xilinx-xadc.txt Devicetree binding to a YAML schema format
>> and remove the old text binding.
>>
>> +
>> +  xlnx,channels:
>> +    $ref: '#/$defs/channels'
>> +
>> +allOf:
> 
> Missing ref since you use unevaluatedProperties...
> 
>> +  - if:
>> +      required:
>> +        - xlnx,external-mux
>> +      properties:
>> +        xlnx,external-mux:
>> +          enum:
>> +            - single
>> +            - dual
>> +    then:
>> +      required:
>> +        - xlnx,external-mux-channel
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +unevaluatedProperties: false
> 
> or you meant additionalProperties?
> 
>> +
>> +$defs:
> 
> Why this is a def, not used directly? I see only one usage of this def.

I am getting the below error if i define the patternProperties directly.
Seems like complex vendor peroperties should be referenced via $ref.
Please suggest if there is any better way to deal this.

linux-xlnx/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml: 
properties:xlnx,channels:type: 'boolean' was expected
	hint: A vendor boolean property can use "type: boolean"
	from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
   LINT    ../Documentation/devicetree/bindings
   DTEX    Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dts
   DTC [C] Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dtb


Regards
Sai Krishna

> 
>> +  channels:
>> +    type: object
>> +    description: List of external channels that are connected to the ADC
>> +    properties:
>> +      '#address-cells':
>> +        const: 1
>> +      '#size-cells':
>> +        const: 0
>> +
>> +    patternProperties:
>> +      "^channel@([0-9]|1[0-6])$":
>> +        type: object
>> +        properties:
>> +          reg:
>> +            minimum: 0
>> +            maximum: 16
>> +            description: |
>> +              Pair of pins the channel is connected to:
>> +                0: VP/VN
>> +                1-16: VAUXP[0-15]/VAUXN[0-15]
>> +              Note each channel number should only be used at most once.
>> +
>> +          xlnx,bipolar:
>> +            type: boolean
>> +            description: If set, the channel is used in bipolar mode
>> +
>> +        required:
>> +          - reg
>> +
>> +        unevaluatedProperties: false
> 
> Again, where is any $ref?
> 
>> +
>> +    required:
>> +      - '#address-cells'
>> +      - '#size-cells'
>> +
>> +    unevaluatedProperties: false
> 
> And here, please read writing schema and writing bindings docs.
> 
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +    xadc@f8007100 {
> 
> adc
> 
> Node names should be generic. See also an explanation and list of
> examples (not exhaustive) in DT specification:
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> If you cannot find a name matching your device, please check in kernel
> sources for similar cases or you can grow the spec (via pull request to
> DT spec repo).
> 
>> +        compatible = "xlnx,zynq-xadc-1.00.a";
>> +        reg = <0xf8007100 0x20>;
>> +        interrupts = <0 7 4>;
> 
> Use proper defines.
> 
>> +        clocks = <&pcap_clk>;
>> +
>> +        xlnx,channels {
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +            channel@0 {
>> +                reg = <0>;
>> +            };
>> +            channel@1 {
>> +                reg = <1>;
>> +            };
>> +            channel@8 {
>> +                reg = <8>;
>> +            };
>> +        };
>> +    };
>> +
>> +  - |
>> +    xadc@43200000 {
> 
> One example is enough, I don't see differences here.
> 
>> +        compatible = "xlnx,axi-xadc-1.00.a";
>> +        reg = <0x43200000 0x1000>;
>> +        interrupts = <0 53 4>;
>> +        clocks = <&fpga1_clk>;
>> +
>> +        xlnx,channels {
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +            channel@0 {
>> +                reg = <0>;
>> +                xlnx,bipolar;
>> +            };
>> +        };
>> +    };
>> +
>> +  - |
>> +    adc@80000000 {
> 
> Again, one example is enough, unless you have multiple differences in
> properties.
> 
> Best regards,
> Krzysztof
> 

Re: [PATCH 5/5] dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

[David Lechner]

On 3/19/26 8:52 AM, Sai Krishna Potthuri wrote:
> Hi Krzysztof,
> 
> On 2/21/2026 4:08 PM, Krzysztof Kozlowski wrote:
>> On Fri, Feb 20, 2026 at 11:09:41AM +0530, Sai Krishna Potthuri wrote:
>>> Convert the xilinx-xadc.txt Devicetree binding to a YAML schema format
>>> and remove the old text binding.
>>>
>>> +
>>> +  xlnx,channels:
>>> +    $ref: '#/$defs/channels'
>>> +
>>> +allOf:
>>
>> Missing ref since you use unevaluatedProperties...
>>
>>> +  - if:
>>> +      required:
>>> +        - xlnx,external-mux
>>> +      properties:
>>> +        xlnx,external-mux:
>>> +          enum:
>>> +            - single
>>> +            - dual
>>> +    then:
>>> +      required:
>>> +        - xlnx,external-mux-channel
>>> +
>>> +required:
>>> +  - compatible
>>> +  - reg
>>> +
>>> +unevaluatedProperties: false
>>
>> or you meant additionalProperties?
>>
>>> +
>>> +$defs:
>>
>> Why this is a def, not used directly? I see only one usage of this def.
> 
> I am getting the below error if i define the patternProperties directly.
> Seems like complex vendor peroperties should be referenced via $ref.
> Please suggest if there is any better way to deal this.

It is hard to say without seeing the new version of what you wrote.



> 
> linux-xlnx/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml: properties:xlnx,channels:type: 'boolean' was expected
>     hint: A vendor boolean property can use "type: boolean"
>     from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
>   LINT    ../Documentation/devicetree/bindings
>   DTEX    Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dts
>   DTC [C] Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dtb
> 
> 
> Regards
> Sai Krishna
> 
>>
>>> +  channels:
>>> +    type: object
>>> +    description: List of external channels that are connected to the ADC
>>> +    properties:
>>> +      '#address-cells':
>>> +        const: 1
>>> +      '#size-cells':
>>> +        const: 0
>>> +
>>> +    patternProperties:
>>> +      "^channel@([0-9]|1[0-6])$":
>>> +        type: object
>>> +        properties:
>>> +          reg:
>>> +            minimum: 0
>>> +            maximum: 16
>>> +            description: |
>>> +              Pair of pins the channel is connected to:
>>> +                0: VP/VN
>>> +                1-16: VAUXP[0-15]/VAUXN[0-15]
>>> +              Note each channel number should only be used at most once.
>>> +
>>> +          xlnx,bipolar:
>>> +            type: boolean
>>> +            description: If set, the channel is used in bipolar mode
>>> +
>>> +        required:
>>> +          - reg
>>> +
>>> +        unevaluatedProperties: false
>>

Re: [PATCH 5/5] dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

[Sai Krishna Potthuri]

Hi David Lechner,

On 3/19/2026 7:53 PM, David Lechner wrote:
> On 3/19/26 8:52 AM, Sai Krishna Potthuri wrote:
>> Hi Krzysztof,
>>
>> On 2/21/2026 4:08 PM, Krzysztof Kozlowski wrote:
>>> On Fri, Feb 20, 2026 at 11:09:41AM +0530, Sai Krishna Potthuri wrote:
>>>> Convert the xilinx-xadc.txt Devicetree binding to a YAML schema format
>>>> and remove the old text binding.
>>>>
>>>> +
>>>> +  xlnx,channels:
>>>> +    $ref: '#/$defs/channels'
>>>> +
>>>> +allOf:
>>>
>>> Missing ref since you use unevaluatedProperties...
>>>
>>>> +  - if:
>>>> +      required:
>>>> +        - xlnx,external-mux
>>>> +      properties:
>>>> +        xlnx,external-mux:
>>>> +          enum:
>>>> +            - single
>>>> +            - dual
>>>> +    then:
>>>> +      required:
>>>> +        - xlnx,external-mux-channel
>>>> +
>>>> +required:
>>>> +  - compatible
>>>> +  - reg
>>>> +
>>>> +unevaluatedProperties: false
>>>
>>> or you meant additionalProperties?
>>>
>>>> +
>>>> +$defs:
>>>
>>> Why this is a def, not used directly? I see only one usage of this def.
>>
>> I am getting the below error if i define the patternProperties directly.
>> Seems like complex vendor peroperties should be referenced via $ref.
>> Please suggest if there is any better way to deal this.
> 
> It is hard to say without seeing the new version of what you wrote.

In v1 series, i created $def and referenced this in xlnx,channels to 
avoid the error that i mentioned.

v1 code:
   xlnx,channels:
     $ref: '#/$defs/channels'

   $defs:
   channels:
     type: object
     description: List of external channels that are connected to the ADC
     properties:
       '#address-cells':
         const: 1
       '#size-cells':
         const: 0

     patternProperties:
       "^channel@([0-9]|1[0-6])$":
         type: object
         properties:
           reg:
             minimum: 0
             maximum: 16
             description: |
               Pair of pins the channel is connected to:
                 0: VP/VN
                 1-16: VAUXP[0-15]/VAUXN[0-15]
               Note each channel number should only be used at most once.

           xlnx,bipolar:
             type: boolean
             description: If set, the channel is used in bipolar mode

         required:
           - reg

         unevaluatedProperties: false

     required:
       - '#address-cells'
       - '#size-cells'

     unevaluatedProperties: false


Regards
Sai krishna


> 
> 
> 
>>
>> linux-xlnx/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml: properties:xlnx,channels:type: 'boolean' was expected
>>      hint: A vendor boolean property can use "type: boolean"
>>      from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
>>    LINT    ../Documentation/devicetree/bindings
>>    DTEX    Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dts
>>    DTC [C] Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dtb
>>
>>
>> Regards
>> Sai Krishna
>>
>>>
>>>> +  channels:
>>>> +    type: object
>>>> +    description: List of external channels that are connected to the ADC
>>>> +    properties:
>>>> +      '#address-cells':
>>>> +        const: 1
>>>> +      '#size-cells':
>>>> +        const: 0
>>>> +
>>>> +    patternProperties:
>>>> +      "^channel@([0-9]|1[0-6])$":
>>>> +        type: object
>>>> +        properties:
>>>> +          reg:
>>>> +            minimum: 0
>>>> +            maximum: 16
>>>> +            description: |
>>>> +              Pair of pins the channel is connected to:
>>>> +                0: VP/VN
>>>> +                1-16: VAUXP[0-15]/VAUXN[0-15]
>>>> +              Note each channel number should only be used at most once.
>>>> +
>>>> +          xlnx,bipolar:
>>>> +            type: boolean
>>>> +            description: If set, the channel is used in bipolar mode
>>>> +
>>>> +        required:
>>>> +          - reg
>>>> +
>>>> +        unevaluatedProperties: false
>>>

Re: [PATCH 5/5] dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

[David Lechner]

On 3/19/26 9:49 AM, Sai Krishna Potthuri wrote:
> Hi David Lechner,
> 
> On 3/19/2026 7:53 PM, David Lechner wrote:
>> On 3/19/26 8:52 AM, Sai Krishna Potthuri wrote:
>>> Hi Krzysztof,
>>>
>>> On 2/21/2026 4:08 PM, Krzysztof Kozlowski wrote:
>>>> On Fri, Feb 20, 2026 at 11:09:41AM +0530, Sai Krishna Potthuri wrote:
>>>>> Convert the xilinx-xadc.txt Devicetree binding to a YAML schema format
>>>>> and remove the old text binding.
>>>>>
>>>>> +
>>>>> +  xlnx,channels:
>>>>> +    $ref: '#/$defs/channels'
>>>>> +
>>>>> +allOf:
>>>>
>>>> Missing ref since you use unevaluatedProperties...
>>>>
>>>>> +  - if:
>>>>> +      required:
>>>>> +        - xlnx,external-mux
>>>>> +      properties:
>>>>> +        xlnx,external-mux:
>>>>> +          enum:
>>>>> +            - single
>>>>> +            - dual
>>>>> +    then:
>>>>> +      required:
>>>>> +        - xlnx,external-mux-channel
>>>>> +
>>>>> +required:
>>>>> +  - compatible
>>>>> +  - reg
>>>>> +
>>>>> +unevaluatedProperties: false
>>>>
>>>> or you meant additionalProperties?
>>>>
>>>>> +
>>>>> +$defs:
>>>>
>>>> Why this is a def, not used directly? I see only one usage of this def.
>>>
>>> I am getting the below error if i define the patternProperties directly.
>>> Seems like complex vendor peroperties should be referenced via $ref.
>>> Please suggest if there is any better way to deal this.
>>
>> It is hard to say without seeing the new version of what you wrote.
> 
> In v1 series, i created $def and referenced this in xlnx,channels to avoid the error that i mentioned.

Is the code below the code that causes the error?

> 
> v1 code:
>   xlnx,channels:
>     $ref: '#/$defs/channels'
> 
>   $defs:
>   channels:

Is this indent bug just from copying to email or does it exist in
the source that is causing the error?

>     type: object
>     description: List of external channels that are connected to the ADC
>     properties:
>       '#address-cells':
>         const: 1
>       '#size-cells':
>         const: 0
> 
>     patternProperties:
>       "^channel@([0-9]|1[0-6])$":
>         type: object
>         properties:
>           reg:
>             minimum: 0
>             maximum: 16
>             description: |
>               Pair of pins the channel is connected to:
>                 0: VP/VN
>                 1-16: VAUXP[0-15]/VAUXN[0-15]
>               Note each channel number should only be used at most once.
> 
>           xlnx,bipolar:
>             type: boolean
>             description: If set, the channel is used in bipolar mode
> 
>         required:
>           - reg
> 
>         unevaluatedProperties: false
> 
>     required:
>       - '#address-cells'
>       - '#size-cells'
> 
>     unevaluatedProperties: false
> 
> 
> Regards
> Sai krishna
> 
> 
>>
>>
>>
>>>
>>> linux-xlnx/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml: properties:xlnx,channels:type: 'boolean' was expected
>>>      hint: A vendor boolean property can use "type: boolean"
>>>      from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
>>>    LINT    ../Documentation/devicetree/bindings
>>>    DTEX    Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dts
>>>    DTC [C] Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dtb
>>>
>>>
>>> Regards
>>> Sai Krishna
>>>
>>>>
>>>>> +  channels:
>>>>> +    type: object
>>>>> +    description: List of external channels that are connected to the ADC
>>>>> +    properties:
>>>>> +      '#address-cells':
>>>>> +        const: 1
>>>>> +      '#size-cells':
>>>>> +        const: 0
>>>>> +
>>>>> +    patternProperties:
>>>>> +      "^channel@([0-9]|1[0-6])$":
>>>>> +        type: object
>>>>> +        properties:
>>>>> +          reg:
>>>>> +            minimum: 0
>>>>> +            maximum: 16
>>>>> +            description: |
>>>>> +              Pair of pins the channel is connected to:
>>>>> +                0: VP/VN
>>>>> +                1-16: VAUXP[0-15]/VAUXN[0-15]
>>>>> +              Note each channel number should only be used at most once.
>>>>> +
>>>>> +          xlnx,bipolar:
>>>>> +            type: boolean
>>>>> +            description: If set, the channel is used in bipolar mode
>>>>> +
>>>>> +        required:
>>>>> +          - reg
>>>>> +
>>>>> +        unevaluatedProperties: false
>>>>
> 

Re: [PATCH 5/5] dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

[Sai Krishna Potthuri]

Hi David Lechner,

On 3/19/2026 8:28 PM, David Lechner wrote:
> On 3/19/26 9:49 AM, Sai Krishna Potthuri wrote:
>> Hi David Lechner,
>>
>> On 3/19/2026 7:53 PM, David Lechner wrote:
>>> On 3/19/26 8:52 AM, Sai Krishna Potthuri wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On 2/21/2026 4:08 PM, Krzysztof Kozlowski wrote:
>>>>> On Fri, Feb 20, 2026 at 11:09:41AM +0530, Sai Krishna Potthuri wrote:
>>>>>> Convert the xilinx-xadc.txt Devicetree binding to a YAML schema format
>>>>>> and remove the old text binding.
>>>>>>
>>>>>> +
>>>>>> +  xlnx,channels:
>>>>>> +    $ref: '#/$defs/channels'
>>>>>> +
>>>>>> +allOf:
>>>>>
>>>>> Missing ref since you use unevaluatedProperties...
>>>>>
>>>>>> +  - if:
>>>>>> +      required:
>>>>>> +        - xlnx,external-mux
>>>>>> +      properties:
>>>>>> +        xlnx,external-mux:
>>>>>> +          enum:
>>>>>> +            - single
>>>>>> +            - dual
>>>>>> +    then:
>>>>>> +      required:
>>>>>> +        - xlnx,external-mux-channel
>>>>>> +
>>>>>> +required:
>>>>>> +  - compatible
>>>>>> +  - reg
>>>>>> +
>>>>>> +unevaluatedProperties: false
>>>>>
>>>>> or you meant additionalProperties?
>>>>>
>>>>>> +
>>>>>> +$defs:
>>>>>
>>>>> Why this is a def, not used directly? I see only one usage of this def.
>>>>
>>>> I am getting the below error if i define the patternProperties directly.
>>>> Seems like complex vendor peroperties should be referenced via $ref.
>>>> Please suggest if there is any better way to deal this.
>>>
>>> It is hard to say without seeing the new version of what you wrote.
>>
>> In v1 series, i created $def and referenced this in xlnx,channels to avoid the error that i mentioned.
> 
> Is the code below the code that causes the error?

No, the below code is not creating the error but Krzysztof asked the 
question on this code,
"Why this is a def, not used directly? I see only one usage of this def."

I am saying if i don't use the def and use it directly i am seeing the 
error that i mentioned. So, asking is there any better way to handle 
this case other than using def.

Regards
Sai Krishna

> 
>>
>> v1 code:
>>    xlnx,channels:
>>      $ref: '#/$defs/channels'
>>
>>    $defs:
>>    channels:
> 
> Is this indent bug just from copying to email or does it exist in
> the source that is causing the error?
> 
>>      type: object
>>      description: List of external channels that are connected to the ADC
>>      properties:
>>        '#address-cells':
>>          const: 1
>>        '#size-cells':
>>          const: 0
>>
>>      patternProperties:
>>        "^channel@([0-9]|1[0-6])$":
>>          type: object
>>          properties:
>>            reg:
>>              minimum: 0
>>              maximum: 16
>>              description: |
>>                Pair of pins the channel is connected to:
>>                  0: VP/VN
>>                  1-16: VAUXP[0-15]/VAUXN[0-15]
>>                Note each channel number should only be used at most once.
>>
>>            xlnx,bipolar:
>>              type: boolean
>>              description: If set, the channel is used in bipolar mode
>>
>>          required:
>>            - reg
>>
>>          unevaluatedProperties: false
>>
>>      required:
>>        - '#address-cells'
>>        - '#size-cells'
>>
>>      unevaluatedProperties: false
>>
>>
>> Regards
>> Sai krishna
>>
>>
>>>
>>>
>>>
>>>>
>>>> linux-xlnx/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml: properties:xlnx,channels:type: 'boolean' was expected
>>>>       hint: A vendor boolean property can use "type: boolean"
>>>>       from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
>>>>     LINT    ../Documentation/devicetree/bindings
>>>>     DTEX    Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dts
>>>>     DTC [C] Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dtb
>>>>
>>>>
>>>> Regards
>>>> Sai Krishna
>>>>
>>>>>
>>>>>> +  channels:
>>>>>> +    type: object
>>>>>> +    description: List of external channels that are connected to the ADC
>>>>>> +    properties:
>>>>>> +      '#address-cells':
>>>>>> +        const: 1
>>>>>> +      '#size-cells':
>>>>>> +        const: 0
>>>>>> +
>>>>>> +    patternProperties:
>>>>>> +      "^channel@([0-9]|1[0-6])$":
>>>>>> +        type: object
>>>>>> +        properties:
>>>>>> +          reg:
>>>>>> +            minimum: 0
>>>>>> +            maximum: 16
>>>>>> +            description: |
>>>>>> +              Pair of pins the channel is connected to:
>>>>>> +                0: VP/VN
>>>>>> +                1-16: VAUXP[0-15]/VAUXN[0-15]
>>>>>> +              Note each channel number should only be used at most once.
>>>>>> +
>>>>>> +          xlnx,bipolar:
>>>>>> +            type: boolean
>>>>>> +            description: If set, the channel is used in bipolar mode
>>>>>> +
>>>>>> +        required:
>>>>>> +          - reg
>>>>>> +
>>>>>> +        unevaluatedProperties: false
>>>>>
>>
> 

Re: [PATCH 5/5] dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

[David Lechner]

On 3/19/26 10:10 AM, Sai Krishna Potthuri wrote:
> Hi David Lechner,
> 
> On 3/19/2026 8:28 PM, David Lechner wrote:
>> On 3/19/26 9:49 AM, Sai Krishna Potthuri wrote:
>>> Hi David Lechner,
>>>
>>> On 3/19/2026 7:53 PM, David Lechner wrote:
>>>> On 3/19/26 8:52 AM, Sai Krishna Potthuri wrote:
>>>>> Hi Krzysztof,
>>>>>
>>>>> On 2/21/2026 4:08 PM, Krzysztof Kozlowski wrote:
>>>>>> On Fri, Feb 20, 2026 at 11:09:41AM +0530, Sai Krishna Potthuri wrote:
>>>>>>> Convert the xilinx-xadc.txt Devicetree binding to a YAML schema format
>>>>>>> and remove the old text binding.
>>>>>>>
>>>>>>> +
>>>>>>> +  xlnx,channels:
>>>>>>> +    $ref: '#/$defs/channels'
>>>>>>> +
>>>>>>> +allOf:
>>>>>>
>>>>>> Missing ref since you use unevaluatedProperties...
>>>>>>
>>>>>>> +  - if:
>>>>>>> +      required:
>>>>>>> +        - xlnx,external-mux
>>>>>>> +      properties:
>>>>>>> +        xlnx,external-mux:
>>>>>>> +          enum:
>>>>>>> +            - single
>>>>>>> +            - dual
>>>>>>> +    then:
>>>>>>> +      required:
>>>>>>> +        - xlnx,external-mux-channel
>>>>>>> +
>>>>>>> +required:
>>>>>>> +  - compatible
>>>>>>> +  - reg
>>>>>>> +
>>>>>>> +unevaluatedProperties: false
>>>>>>
>>>>>> or you meant additionalProperties?
>>>>>>
>>>>>>> +
>>>>>>> +$defs:
>>>>>>
>>>>>> Why this is a def, not used directly? I see only one usage of this def.
>>>>>
>>>>> I am getting the below error if i define the patternProperties directly.
>>>>> Seems like complex vendor peroperties should be referenced via $ref.
>>>>> Please suggest if there is any better way to deal this.
>>>>
>>>> It is hard to say without seeing the new version of what you wrote.
>>>
>>> In v1 series, i created $def and referenced this in xlnx,channels to avoid the error that i mentioned.
>>
>> Is the code below the code that causes the error?
> 
> No, the below code is not creating the error but Krzysztof asked the question on this code,
> "Why this is a def, not used directly? I see only one usage of this def."
> 
> I am saying if i don't use the def and use it directly i am seeing the error that i mentioned. So, asking is there any better way to handle this case other than using def.

If you could show us the actual code that is causing the error, then
we could perhaps spot a mistake or suggest an alternative.

> 
> Regards
> Sai Krishna
> 
>>
>>>
>>> v1 code:
>>>    xlnx,channels:
>>>      $ref: '#/$defs/channels'
>>>
>>>    $defs:
>>>    channels:
>>
>> Is this indent bug just from copying to email or does it exist in
>> the source that is causing the error?
>>
>>>      type: object
>>>      description: List of external channels that are connected to the ADC
>>>      properties:
>>>        '#address-cells':
>>>          const: 1
>>>        '#size-cells':
>>>          const: 0
>>>
>>>      patternProperties:
>>>        "^channel@([0-9]|1[0-6])$":
>>>          type: object
>>>          properties:
>>>            reg:
>>>              minimum: 0
>>>              maximum: 16
>>>              description: |
>>>                Pair of pins the channel is connected to:
>>>                  0: VP/VN
>>>                  1-16: VAUXP[0-15]/VAUXN[0-15]
>>>                Note each channel number should only be used at most once.
>>>
>>>            xlnx,bipolar:
>>>              type: boolean
>>>              description: If set, the channel is used in bipolar mode
>>>
>>>          required:
>>>            - reg
>>>
>>>          unevaluatedProperties: false
>>>
>>>      required:
>>>        - '#address-cells'
>>>        - '#size-cells'
>>>
>>>      unevaluatedProperties: false
>>>
>>>
>>> Regards
>>> Sai krishna
>>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> linux-xlnx/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml: properties:xlnx,channels:type: 'boolean' was expected
>>>>>       hint: A vendor boolean property can use "type: boolean"
>>>>>       from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
>>>>>     LINT    ../Documentation/devicetree/bindings
>>>>>     DTEX    Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dts
>>>>>     DTC [C] Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dtb
>>>>>
>>>>>
>>>>> Regards
>>>>> Sai Krishna
>>>>>
>>>>>>
>>>>>>> +  channels:
>>>>>>> +    type: object
>>>>>>> +    description: List of external channels that are connected to the ADC
>>>>>>> +    properties:
>>>>>>> +      '#address-cells':
>>>>>>> +        const: 1
>>>>>>> +      '#size-cells':
>>>>>>> +        const: 0
>>>>>>> +
>>>>>>> +    patternProperties:
>>>>>>> +      "^channel@([0-9]|1[0-6])$":
>>>>>>> +        type: object
>>>>>>> +        properties:
>>>>>>> +          reg:
>>>>>>> +            minimum: 0
>>>>>>> +            maximum: 16
>>>>>>> +            description: |
>>>>>>> +              Pair of pins the channel is connected to:
>>>>>>> +                0: VP/VN
>>>>>>> +                1-16: VAUXP[0-15]/VAUXN[0-15]
>>>>>>> +              Note each channel number should only be used at most once.
>>>>>>> +
>>>>>>> +          xlnx,bipolar:
>>>>>>> +            type: boolean
>>>>>>> +            description: If set, the channel is used in bipolar mode
>>>>>>> +
>>>>>>> +        required:
>>>>>>> +          - reg
>>>>>>> +
>>>>>>> +        unevaluatedProperties: false
>>>>>>
>>>
>>
> 

Re: [PATCH 5/5] dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

[Sai Krishna Potthuri]

Hi David Lechner,

On 3/19/2026 9:05 PM, David Lechner wrote:
> On 3/19/26 10:10 AM, Sai Krishna Potthuri wrote:
>> Hi David Lechner,
>>
>> On 3/19/2026 8:28 PM, David Lechner wrote:
>>> On 3/19/26 9:49 AM, Sai Krishna Potthuri wrote:
>>>> Hi David Lechner,
>>>>
>>>> On 3/19/2026 7:53 PM, David Lechner wrote:
>>>>> On 3/19/26 8:52 AM, Sai Krishna Potthuri wrote:
>>>>>> Hi Krzysztof,
>>>>>>
>>>>>> On 2/21/2026 4:08 PM, Krzysztof Kozlowski wrote:
>>>>>>> On Fri, Feb 20, 2026 at 11:09:41AM +0530, Sai Krishna Potthuri wrote:
>>>>>>>> Convert the xilinx-xadc.txt Devicetree binding to a YAML schema format
>>>>>>>> and remove the old text binding.
>>>>>>>>
>>>>>>>> +
>>>>>>>> +  xlnx,channels:
>>>>>>>> +    $ref: '#/$defs/channels'
>>>>>>>> +
>>>>>>>> +allOf:
>>>>>>>
>>>>>>> Missing ref since you use unevaluatedProperties...
>>>>>>>
>>>>>>>> +  - if:
>>>>>>>> +      required:
>>>>>>>> +        - xlnx,external-mux
>>>>>>>> +      properties:
>>>>>>>> +        xlnx,external-mux:
>>>>>>>> +          enum:
>>>>>>>> +            - single
>>>>>>>> +            - dual
>>>>>>>> +    then:
>>>>>>>> +      required:
>>>>>>>> +        - xlnx,external-mux-channel
>>>>>>>> +
>>>>>>>> +required:
>>>>>>>> +  - compatible
>>>>>>>> +  - reg
>>>>>>>> +
>>>>>>>> +unevaluatedProperties: false
>>>>>>>
>>>>>>> or you meant additionalProperties?
>>>>>>>
>>>>>>>> +
>>>>>>>> +$defs:
>>>>>>>
>>>>>>> Why this is a def, not used directly? I see only one usage of this def.
>>>>>>
>>>>>> I am getting the below error if i define the patternProperties directly.
>>>>>> Seems like complex vendor peroperties should be referenced via $ref.
>>>>>> Please suggest if there is any better way to deal this.
>>>>>
>>>>> It is hard to say without seeing the new version of what you wrote.
>>>>
>>>> In v1 series, i created $def and referenced this in xlnx,channels to avoid the error that i mentioned.
>>>
>>> Is the code below the code that causes the error?
>>
>> No, the below code is not creating the error but Krzysztof asked the question on this code,
>> "Why this is a def, not used directly? I see only one usage of this def."
>>
>> I am saying if i don't use the def and use it directly i am seeing the error that i mentioned. So, asking is there any better way to handle this case other than using def.
> 
> If you could show us the actual code that is causing the error, then
> we could perhaps spot a mistake or suggest an alternative.

Thanks. Here is the code that is causing the error
("properties:xlnx,channels:type: 'boolean' was expected").

xlnx,channels:
     type: object
     description: List of external channels that are connected to the ADC
     properties:
       '#address-cells':
         const: 1
       '#size-cells':
         const: 0

     patternProperties:
       "^channel@([0-9]|1[0-6])$":
         type: object
         properties:
           reg:
             minimum: 0
             maximum: 16
             description: |
               Pair of pins the channel is connected to:
                 0: VP/VN
                 1-16: VAUXP[0-15]/VAUXN[0-15]
               Note each channel number should only be used at most once.

           xlnx,bipolar:
             type: boolean
             description: If set, the channel is used in bipolar mode

         required:
           - reg

         additionalProperties: false

     required:
       - '#address-cells'
       - '#size-cells'

     additionalProperties: false


Regards
Sai Krishna

> 
>>
>> Regards
>> Sai Krishna
>>
>>>
>>>>
>>>> v1 code:
>>>>     xlnx,channels:
>>>>       $ref: '#/$defs/channels'
>>>>
>>>>     $defs:
>>>>     channels:
>>>
>>> Is this indent bug just from copying to email or does it exist in
>>> the source that is causing the error?
>>>
>>>>       type: object
>>>>       description: List of external channels that are connected to the ADC
>>>>       properties:
>>>>         '#address-cells':
>>>>           const: 1
>>>>         '#size-cells':
>>>>           const: 0
>>>>
>>>>       patternProperties:
>>>>         "^channel@([0-9]|1[0-6])$":
>>>>           type: object
>>>>           properties:
>>>>             reg:
>>>>               minimum: 0
>>>>               maximum: 16
>>>>               description: |
>>>>                 Pair of pins the channel is connected to:
>>>>                   0: VP/VN
>>>>                   1-16: VAUXP[0-15]/VAUXN[0-15]
>>>>                 Note each channel number should only be used at most once.
>>>>
>>>>             xlnx,bipolar:
>>>>               type: boolean
>>>>               description: If set, the channel is used in bipolar mode
>>>>
>>>>           required:
>>>>             - reg
>>>>
>>>>           unevaluatedProperties: false
>>>>
>>>>       required:
>>>>         - '#address-cells'
>>>>         - '#size-cells'
>>>>
>>>>       unevaluatedProperties: false
>>>>
>>>>
>>>> Regards
>>>> Sai krishna
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> linux-xlnx/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml: properties:xlnx,channels:type: 'boolean' was expected
>>>>>>        hint: A vendor boolean property can use "type: boolean"
>>>>>>        from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
>>>>>>      LINT    ../Documentation/devicetree/bindings
>>>>>>      DTEX    Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dts
>>>>>>      DTC [C] Documentation/devicetree/bindings/iio/adc/xilinx-xadc.example.dtb
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Sai Krishna
>>>>>>
>>>>>>>
>>>>>>>> +  channels:
>>>>>>>> +    type: object
>>>>>>>> +    description: List of external channels that are connected to the ADC
>>>>>>>> +    properties:
>>>>>>>> +      '#address-cells':
>>>>>>>> +        const: 1
>>>>>>>> +      '#size-cells':
>>>>>>>> +        const: 0
>>>>>>>> +
>>>>>>>> +    patternProperties:
>>>>>>>> +      "^channel@([0-9]|1[0-6])$":
>>>>>>>> +        type: object
>>>>>>>> +        properties:
>>>>>>>> +          reg:
>>>>>>>> +            minimum: 0
>>>>>>>> +            maximum: 16
>>>>>>>> +            description: |
>>>>>>>> +              Pair of pins the channel is connected to:
>>>>>>>> +                0: VP/VN
>>>>>>>> +                1-16: VAUXP[0-15]/VAUXN[0-15]
>>>>>>>> +              Note each channel number should only be used at most once.
>>>>>>>> +
>>>>>>>> +          xlnx,bipolar:
>>>>>>>> +            type: boolean
>>>>>>>> +            description: If set, the channel is used in bipolar mode
>>>>>>>> +
>>>>>>>> +        required:
>>>>>>>> +          - reg
>>>>>>>> +
>>>>>>>> +        unevaluatedProperties: false
>>>>>>>
>>>>
>>>
>>
> 

Re: [PATCH 5/5] dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

[Krzysztof Kozlowski]

On 19/03/2026 16:49, Sai Krishna Potthuri wrote:
>>>>>>>>
>>>>>>>>> +
>>>>>>>>> +$defs:
>>>>>>>>
>>>>>>>> Why this is a def, not used directly? I see only one usage of this def.
>>>>>>>
>>>>>>> I am getting the below error if i define the patternProperties directly.
>>>>>>> Seems like complex vendor peroperties should be referenced via $ref.
>>>>>>> Please suggest if there is any better way to deal this.
>>>>>>
>>>>>> It is hard to say without seeing the new version of what you wrote.
>>>>>
>>>>> In v1 series, i created $def and referenced this in xlnx,channels to avoid the error that i mentioned.
>>>>
>>>> Is the code below the code that causes the error?
>>>
>>> No, the below code is not creating the error but Krzysztof asked the question on this code,
>>> "Why this is a def, not used directly? I see only one usage of this def."
>>>
>>> I am saying if i don't use the def and use it directly i am seeing the error that i mentioned. So, asking is there any better way to handle this case other than using def.
>>
>> If you could show us the actual code that is causing the error, then
>> we could perhaps spot a mistake or suggest an alternative.

Thanks David, I am surprised how many emails we need to exchange just to
see the actual code.

> 
> Thanks. Here is the code that is causing the error
> ("properties:xlnx,channels:type: 'boolean' was expected").
> 
> xlnx,channels:

Device nodes do not have any prefixes. Just take a look at any DTS or
any binding.

Probably that's the reason, because nothing in this code looks
particularly odd. Anyway, please do not come with odd syntax in the code
without any explanation, just to make it passing the tests, so for
example ignoring the checks we have.


Best regards,
Krzysztof

Re: [PATCH 5/5] dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

[David Lechner]

On 3/19/26 11:49 AM, Krzysztof Kozlowski wrote:
> On 19/03/2026 16:49, Sai Krishna Potthuri wrote:
>>>>>>>>>
>>>>>>>>>> +
>>>>>>>>>> +$defs:
>>>>>>>>>
>>>>>>>>> Why this is a def, not used directly? I see only one usage of this def.
>>>>>>>>
>>>>>>>> I am getting the below error if i define the patternProperties directly.
>>>>>>>> Seems like complex vendor peroperties should be referenced via $ref.
>>>>>>>> Please suggest if there is any better way to deal this.
>>>>>>>
>>>>>>> It is hard to say without seeing the new version of what you wrote.
>>>>>>
>>>>>> In v1 series, i created $def and referenced this in xlnx,channels to avoid the error that i mentioned.
>>>>>
>>>>> Is the code below the code that causes the error?
>>>>
>>>> No, the below code is not creating the error but Krzysztof asked the question on this code,
>>>> "Why this is a def, not used directly? I see only one usage of this def."
>>>>
>>>> I am saying if i don't use the def and use it directly i am seeing the error that i mentioned. So, asking is there any better way to handle this case other than using def.
>>>
>>> If you could show us the actual code that is causing the error, then
>>> we could perhaps spot a mistake or suggest an alternative.
> 
> Thanks David, I am surprised how many emails we need to exchange just to
> see the actual code.
> 
>>
>> Thanks. Here is the code that is causing the error
>> ("properties:xlnx,channels:type: 'boolean' was expected").
>>
>> xlnx,channels:
> 
> Device nodes do not have any prefixes. Just take a look at any DTS or
> any binding.
> 
> Probably that's the reason, because nothing in this code looks
> particularly odd. Anyway, please do not come with odd syntax in the code
> without any explanation, just to make it passing the tests, so for
> example ignoring the checks we have.
> 
> 
> Best regards,
> Krzysztof

Since this is converting existing 12-years-old .txt bindings, I don't
think we can "fix" the bindings by dropping the vendor prefix.

I think in cases like this, Rob will usually fix the tooling to ignore
this as a special case. (I had a similar case last year on a conversion
I did.)

So I think the right thing to do is to not use $def and explain in the
commit message why the error is expected (we can't change existing bindings
even though they are "wrong" by current standards).

If this was a new binding, we should be using the common adc.yaml for IIO
ADCs which already has patterProperties for channels and a bipolar flag.
But we are stuck with this vendor-prefixed one here.

Re: [PATCH 5/5] dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

[Krzysztof Kozlowski]

On 19/03/2026 20:07, David Lechner wrote:
> On 3/19/26 11:49 AM, Krzysztof Kozlowski wrote:
>> On 19/03/2026 16:49, Sai Krishna Potthuri wrote:
>>>>>>>>>>
>>>>>>>>>>> +
>>>>>>>>>>> +$defs:
>>>>>>>>>>
>>>>>>>>>> Why this is a def, not used directly? I see only one usage of this def.
>>>>>>>>>
>>>>>>>>> I am getting the below error if i define the patternProperties directly.
>>>>>>>>> Seems like complex vendor peroperties should be referenced via $ref.
>>>>>>>>> Please suggest if there is any better way to deal this.
>>>>>>>>
>>>>>>>> It is hard to say without seeing the new version of what you wrote.
>>>>>>>
>>>>>>> In v1 series, i created $def and referenced this in xlnx,channels to avoid the error that i mentioned.
>>>>>>
>>>>>> Is the code below the code that causes the error?
>>>>>
>>>>> No, the below code is not creating the error but Krzysztof asked the question on this code,
>>>>> "Why this is a def, not used directly? I see only one usage of this def."
>>>>>
>>>>> I am saying if i don't use the def and use it directly i am seeing the error that i mentioned. So, asking is there any better way to handle this case other than using def.
>>>>
>>>> If you could show us the actual code that is causing the error, then
>>>> we could perhaps spot a mistake or suggest an alternative.
>>
>> Thanks David, I am surprised how many emails we need to exchange just to
>> see the actual code.
>>
>>>
>>> Thanks. Here is the code that is causing the error
>>> ("properties:xlnx,channels:type: 'boolean' was expected").
>>>
>>> xlnx,channels:
>>
>> Device nodes do not have any prefixes. Just take a look at any DTS or
>> any binding.
>>
>> Probably that's the reason, because nothing in this code looks
>> particularly odd. Anyway, please do not come with odd syntax in the code
>> without any explanation, just to make it passing the tests, so for
>> example ignoring the checks we have.
>>
>>
>> Best regards,
>> Krzysztof
> 
> Since this is converting existing 12-years-old .txt bindings, I don't
> think we can "fix" the bindings by dropping the vendor prefix.

Indeed. It is being also in the driver. The prefix must stay and this
oddity must be explained in the commit msg.

Commit msg must explain all the non-obvious, unusual, unexpected odd
things the patch is doing.

> 
> I think in cases like this, Rob will usually fix the tooling to ignore
> this as a special case. (I had a similar case last year on a conversion
> I did.)
> 
> So I think the right thing to do is to not use $def and explain in the
> commit message why the error is expected (we can't change existing bindings
> even though they are "wrong" by current standards).
> 
> If this was a new binding, we should be using the common adc.yaml for IIO
> ADCs which already has patterProperties for channels and a bipolar flag.
> But we are stuck with this vendor-prefixed one here.
> 


Best regards,
Krzysztof

Re: [PATCH 5/5] dt-bindings: iio: adc: xilinx-xadc: convert to YAML format

[Krzysztof Kozlowski]

On Fri, Feb 20, 2026 at 11:09:41AM +0530, Sai Krishna Potthuri wrote:
> Convert the xilinx-xadc.txt Devicetree binding to a YAML schema format
> and remove the old text binding.
> 
> Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
> ---
>  .../bindings/iio/adc/xilinx-xadc.txt          | 141 -------------
>  .../bindings/iio/adc/xilinx-xadc.yaml         | 194 ++++++++++++++++++
>  2 files changed, 194 insertions(+), 141 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/xilinx-xadc.yaml
> 

There is a guide telling you what do we expect from patch touching DT.
Please read it. What does it tell about subject?
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18

Best regards,
Krzysztof

Re: [PATCH 0/5] iio: adc: xilinx-xadc: Add I2C interface support for System Management Wizard

[Andy Shevchenko]

On Fri, Feb 20, 2026 at 11:09:36AM +0530, Sai Krishna Potthuri wrote:
> The existing driver only supported AXI memory-mapped access to the System
> Management Wizard IP. This series extends the driver to support I2C-based
> access, which is particularly useful for System Controller usecases.
> 
> Key Changes:
> - Extract common probe logic into xadc_device_setup() and
> xadc_device_configure().
> - Add setup_channels function pointer to ops structure to support
> different ways to configure the channels.
> - Replace module_platform_driver() macro with custom init and exit
> functions to support multiple bus interfaces.
> - I2C interface support.
> - Convert binding file to YAML format.
> 
> Note: We are working on x86 platform support where fixed channel
> configuration is used(no DT support). The setup_channels function
> pointer introduced in patch 2/3 enables different channel configuration
> approaches for various platforms.

Thanks, but this series (and driver) has to be refactored differently.
Please, go back to the drawing board and redesign the approach.
We have examples of the drivers in the kernel that are using platform
and I²C approaches.

-- 
With Best Regards,
Andy Shevchenko