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

Blue Swirl blauwirbel at gmail.com
Thu Nov 11 21:17:33 CET 2010


On Thu, Nov 11, 2010 at 7:07 PM, Alexander Graf <agraf at suse.de> wrote:
>
> 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?

It's possible, but then all drivers which use in/out functions should
be changed.



More information about the OpenBIOS mailing list