On Thu, Nov 11, 2010 at 6:21 PM, Andreas Färber andreas.faerber@web.de wrote:
Am 11.11.2010 um 08:39 schrieb Alexander Graf:
On 11.11.2010, at 00:01, Andreas Färber andreas.faerber@web.de wrote:
Am 30.10.2010 um 21:51 schrieb Andreas Färber:
diff --git a/include/arch/ppc/io.h b/include/arch/ppc/io.h index e5180f2..84198f2 100644 --- a/include/arch/ppc/io.h +++ b/include/arch/ppc/io.h
+static inline void insw(phys_addr_t port, void *buf, int ns) +{
- _insw((uint16_t *)(port + isa_io_base), buf, ns);
+}
I'm wondering whether the use of phys_addr_t is right here or whether it should be uintptr_t? Would like to get this out of my queue.
PIO only defines 16 bit number of ports anyways, no?
If you say so. :) I'll try uint16_t then. We'll either need to upcast isa_io_base from uint32_t then or change that variable in qemu/init.c(?) to either phys_addr_t or uintptr_t...
Do we want to consider a phys_addr_t an address where devices are located, whether accessed through MMU or real mode, or is phys_addr_t just supposed to be the MMU counterpart to the effective address? If the latter, do we need a new addr_t type or something or is uintptr_t the type to use since we want to cast it to pointer ultimately?
I'm not sure about PPC terminology, but on Sparc the physical address space (if not mapped by MMU) can be accessed only with special alternate loads or stores. This is what Sparc64 IO macros do.
If an area is mapped it can be accessed with pointer dereference, then a pointer type or uintptr_t would be correct.