Re: [Ksummit-discuss] [TECH TOPIC] Semantics of MMIO mapping attributes accross archs

[Andy Lutomirski <luto@amacapital.net>]

On Mon, Jul 6, 2015 at 2:52 AM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Sun, Jul 05, 2015 at 07:55:39PM +0100, Andy Lutomirski wrote:
>>
>> At some point, it would also be nice if the various macros has
>> well-defined semantics.  For example, x86 has:
>>
>> #define pgprot_noncached(prot)                                          \
>>         ((boot_cpu_data.x86 > 3)                                        \
>>          ? (__pgprot(pgprot_val(prot) |                                 \
>>                      cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS)))     \
>>          : (prot))
>>
>> Putting aside the pointless boot_cpu_data check (surely the recent PAT
>> rework completely obsoletes it), what is
>> pgprot_noncached(pgprot_writecombine(x)) supposed to do?  Currently it
>> results in garbage.  Should it have well-defined behavior instead?
>
> I never thought composing pgprot_* macros/functions is supposed to
> return a combined attribute. On arm32/arm64, this construct is just
> returning the outermost prot, i.e. noncached here. Even if we would want
> to allow such combination, we don't have enough software PTE bits for
> each prot type, so these macros simply generate the corresponding
> hardware bits (on newer ARM cores, that's a 3-bit index).
>

I should have said it more clearly: I think that this construct
*should* result in the outermost prot.  That is: pgprot_xyz(p) should
have mode xyz regardless of p.

x86 doesn't work that way right now.  Instead pgprot_xyz(p) returns
garbage if p has prot bits set.