garrett_damore@tadpole.com wrote:

> > I'm not sure if these implementations are good idea
> > (because I'm not a programmer but just a dumb reader),
> > but I think it could reduce changes from -current common style.
> > (note I don't test these changes at all though)
> >   
> 
> Heh.  The original com code "deviates" by having these routines which
> take a bus_tag_t and a bus_addr_t.  Its ugly.  I'd like to clean them up
> even further, but that is even more change.  I'm trying to minimize the
> number of changes I have to make.  I spent pretty much an entire workday
> yesterday touching a bunch of code that I can't even test.

Well, I suggest a way to avoid most of MD changes.
(but maybe I was wrong...)

> > Hmm. What happens if we have to support another com variant which
> > is attached to MI bus but also has odd regster mapping?
> 
> Then you better define COM_REGSMAP.   Right now the "weird" variants are
> all on MD busses.

Where should it be defined?
I think it should be automatically defined if such device is configured.

> I considered this even.   But I decided to go and touch all the MD
> attachments, because frankly a bunch of them go and modify the softc
> structure directly anyway.

I don't think you have to change any MD code which doesn't require
own reg mapping if you have these macro:

>> 	struct com_regs sc_regs;
>> #define sc_iot		sc_regs.cr_iot
>> #define sc_ioh		sc_regs.cr_ioh
>> #define sc_iobase	sc_regs.cr_iobase

(I'm not sure about performance impact of these macro)
---
Izumi Tsutsui