On Wed, Jun 15, 2022 at 2:19 PM William Breathitt Gray <william.gray@xxxxxxxxxx> wrote: > On Wed, Jun 15, 2022 at 02:00:26PM +0200, Andy Shevchenko wrote: > > On Wed, Jun 15, 2022 at 1:55 PM William Breathitt Gray > > <william.gray@xxxxxxxxxx> wrote: > > > On Wed, Jun 15, 2022 at 11:44:54AM +0200, Andy Shevchenko wrote: > > > > On Mon, Jun 6, 2022 at 4:27 PM William Breathitt Gray > > > > <william.gray@xxxxxxxxxx> wrote: > > > > > > > > > > Reduce magic numbers and improve code readability by implementing and > > > > > utilizing named register data structures. > > > > > > > > Can we consider using regmap APIs instead? > > > > > The regmap API may be more appropriate here. I'll investigate and see if > > > I can convert this over to it. > > > > I just realized that this driver is for the old PC104 (like?) hardware > > that most likely uses IO ports, I don't remember if we have support > > for IO ports in regmap (MMIO -- yes for sure). > Hmm, I don't see IO ports mentioned in include/linux/regmap.h, so I > don't think the regmap API directly supports it (maybe someone familiar > with regmap knows). Although we do get a virtual mapping cookie via > ioport_map() in this driver, I don't know if we can pass that to the > regmap functions and have it actually work. The problem is with accessors which are inconsistent in regmap MMIO implementation. I think it should be converted to use ioreadXX()/iowriteXX() in all cases (currently only BE cases use them). Another variant is to provide read*_be() / write*_be() for all architectures, replace corresponding ops in regmap MMIO and introduce regmap IO with inX()/outX. The former seems to me the best option, while the latter is cleaner. +Cc: Mark if he knows more about this. -- With Best Regards, Andy Shevchenko
