[OpenBIOS] [PATCH] ppc: Convert IO macros to inline functions

Alexander Graf agraf at suse.de
Thu Nov 11 20:07:00 CET 2010


On 11.11.2010, at 19:33, Blue Swirl <blauwirbel at gmail.com> wrote:

> On Thu, Nov 11, 2010 at 6:21 PM, Andreas Färber <andreas.faerber at 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 at 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.

Any reason we can't just make it void* and map it for real where necessary?

Alex




More information about the OpenBIOS mailing list