[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