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

From: Sai Krishna Potthuri

Date: Wed Mar 18 2026 - 05:21:33 EST


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