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