Re: [PATCH v1 5/5] regmap: mmio: Introduce IO accessors that can talk to IO port

[Mark Brown]

On Mon, Aug 08, 2022 at 04:40:26PM +0200, Andy Shevchenko wrote:
> On Mon, Aug 8, 2022 at 3:31 PM Mark Brown <broonie@xxxxxxxxxx> wrote:
> > On Fri, Aug 05, 2022 at 11:53:21PM +0300, Andy Shevchenko wrote:

> > > Currently regmap MMIO is inconsistent with IO accessors. I.e.
> > > the Big Endian counterparts are using ioreadXXbe() / iowriteXXbe()
> > > which are not clean implementations of readXXbe(). Besides that
> > > some users may use regmap MMIO for IO ports, and this can be done
> > > by assigning ioreadXX()/iowriteXX() and their Big Endian counterparts
> > > to the regmap context.

> > Have you validated that nothing is relying on whatever the problem is
> > with using the io versions?

> I have cross-checked 1) the architectures that are BE and have IO port
> capability, and 2) the drivers that are using regmap MMIO with a
> big-endian setting. I found no driver is mapping IO ports and uses
> regmap MMIO at the same time. The architecture wise the x86 and ia64
> are not in question, I think. And alpha is more academical nowadays.
> Did I miss anything?

> That said, I'm 99.999% sure there is no problem with that.

The issue is the potential that something that is currently using the
ioport accessors might be relying on whatever it is that they do that
causes a problem.

> > > That said, reimplement current Big Endian MMIO accessors by replacing
> > > ioread()/iowrite() with respective read()/write() and swab() calls.
> > > While at it, add IO port support with a corresponding flag added.

> > This should be a separate patch.

> OK! Then we remove some code and (re-)add it later. Do we need this churn?
> Another way is to add IO port accessors and then fix the MMIO.

Add and then fix seems sensible,

Attachment: signature.asc
Description: PGP signature