Heh.  I had considered raising the point that the trick of #define
sc_iot et. al. might be a bad choice and create conflicts.  But I didn't
think it would actually happen, so I just started to gut the
COM_INIT_REGS stuff.

Boy, was I wrong:  isa/ast.c is the first place (and I think there may
be at least on other) where the driver includes comvar.h, but also has
its own sc_iot.  Needless to say, this breaks things badly. 
Unfortunately I got halfway thru the conversion before I found the problem.

I think I'll go back to using the COM_INIT_REGS tweak for now.  It
worked, and even if I had to rototill all the sources, the end-result
was reliable.  Heh, I'll be undoing my undo...

Any other brilliant ideas?  I've already burned hours on this particular
fiasco....

    -- Garrett

Garrett D'Amore wrote:
> Alright, to silence this thread, I've begun the process of using a
> compat flag so that old code will "still" work.
>
> This means that right now the tree is entirely busted.  But, arm, and
> m68k probably do work now. :-)
>
> It will take me a day or so to undo the relevant changes.
>
>     -- Garrett
>
> Garrett D'Amore wrote:
>   
>> Izumi Tsutsui wrote:
>>   
>>     
>>> garrett_damore@tadpole.com wrote:
>>>
>>>   
>>>     
>>>       
>>>> Okay, I think I've converted all of sys/dev, leaving only
>>>> sys/arch/{iyonix,evbarm,hpcarm,hp300,amiga}.
>>>>     
>>>>       
>>>>         
>>> and {acorn32,arm}?
>>>
>>>   
>>>     
>>>       
>>>> Some of the sys/dev stuff hasn't been tested yet because I don't have
>>>> kernels that include them.  Once we start doing ARM arches they should
>>>> get a bit more coverage.
>>>>     
>>>>       
>>>>         
>>> Still I can't see the reason why you bother to change all MD attachments
>>> if we could implement regmap stuff without it.
>>>   
>>>     
>>>       
>> At this point, I've already done it.  I can go back and change them
>> *all* again, but frankly I don't want to redo all the work.
>>
>>   
>>     
>>>   
>>>     
>>>       
>>>> Strangly, none of the kernels I tested included com_cpcbus.c
>>>>     
>>>>       
>>>>         
>>> It's in arch/pmppc/conf/PMPPC.
>>> BTW I think com_cpcbus.c should be moved under arch/pmppc
>>> because it has MD intr_establish() in it.
>>>   
>>>     
>>>       
>> Well, someone else can do that.
>>
>>     -- Garrett
>>   
>>     
>>> ---
>>> Izumi Tsutsui
>>>   
>>>     
>>>       
>>   
>>     
>
>
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191