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