Subject: Re: com rumblings...
To: None <email@example.com>
From: Izumi Tsutsui <firstname.lastname@example.org>
Date: 06/17/2006 00:51:29
> > 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)