Re: 4byte aligned com(4) and PCI_MAPREG_TYPE_MEM

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

I'd suggest to clarify what problems you are trying to solve
and consider how it should be solved, before updating your patch.

The problems you mentioned are:
(1) merge initialization of sparse register mappings (with 4 byte stride)
(2) defer consinit() for puc com to use uvm_km_alloc() in it

Your patch is trying to solve them by:
(1) change COM_INIT_REGS() (and comprobe1()) APIs to pass stride byte
(2) add an MI "extent_initted" global variable and check it in MD consinit()

My vote is:
(1) leave existing APIs and handle the quirk in MD attachment
(2) add an x86 specific MD variable to defer consinit() till cpu_startup()

Because:
(1)
 - it's really pain to change the MI APIs
   (so many attachments and most of them will rarely be tested unfortunately)
 - only three or four attachments can share the new API
   while such embedded devices often might have more other quirks
 - even if stride handling is really necessary in MI part,
   it's much better to prepare new wrap functions,
   like wdcprobe1() and wdcprobe() in wdc.c
   (i.e. prepare a new COM_INIT_REGS_STRIDE() macro with a new arg
    and make exiting COM_INIT_REGS() macro use it)

(2)
 - it's unclear what functions actually require the extent_init()
   (I guess uvm_init() is enough to call uvm_km_alloc())
 - in general MI code assumes that console devices are properly
   mapped by MD bootstrap or its firmware
 - some ports already has MD flags to switch malloc(9) or static
   memory in early device mappings and initialization

Just my two cents,

---
Izumi Tsutsui