On 10/01/15 19:18, Peter Maydell wrote: > On 1 October 2015 at 15:36, Laszlo Ersek <ler...@redhat.com> wrote: >> I think I finally understand this difference now. It is all rooted in >> the difference between the internal APIs sysbus_add_io() and >> sysbus_init_mmio(). Both of these are called from the device realize >> functions, but the first (sysbus_add_io()) wants the IO port address at >> once, whereas the second (sysbus_init_mmio()) doesn't want the address >> -- the actual mapping (sysbus_mmio_map()) is delayed to board code; the >> device code doesn't want to be aware of it. > > Yes. The sysbus_add_io() API is firmly wedded to the x86 I/O port > concept and to the idea that devices are at fixed I/O port addresses > which don't depend on what board they're in (because the few > non-x86 systems that set up some kind of "IO port" abstraction > are generally doing it to look more x86-like). > > That said, sysbus_add_io() is one of those odd functions which > we use half a dozen times in the whole codebase and which leaves > me wondering if it ought to be refactored to work differently > (eg split into "declare IO ports" and "map IO ports into IO space" > like the mmio functions)...
I had the same idea looming in the back of my mind, but I wouldn't know how to attack the refactoring (plus I wouldn't want to delay Marc's work with it -- after all the function is not being introduced by this series), so I didn't bring it up. :P Thanks! Laszlo
