incorrect setting of MT_DEVICE_ mem_types TEX bits on ARMv7?

Henry Gomersall henry.gomersall at smartacoustics.co.uk
Tue Dec 1 07:57:33 EST 2020


On 01/12/2020 11:56, Ard Biesheuvel wrote:
> On Tue, 1 Dec 2020 at 12:45, Henry Gomersall
> <henry.gomersall at smartacoustics.co.uk> wrote:
>> Looking at the configuration of the TEX bits for mem_types[MT_DEVICE]
>> and  mem_types[MT_DEVICE_NONSHARED] in mmu.c, they seem to be
>> inconsistent with the technical reference manual.
>>
>> Relevant lines:
>> https://github.com/torvalds/linux/blob/master/arch/arm/mm/mmu.c#L498
>>
>> The ARM architecture reference manual ARMv7-A and ARMv7-R, table B3-10
>> in section B3.8.2 describes the strongly-ordered TEX bits as 00 or 10
>> for shared and unshared respectively.
>>
>> MT_DEVICE_WC is set as I'd expect (the buffering-on case).
>>
>> It's more than possible I'm missing something, in which case I'd
>> appreciate knowing!
>>
> Are you referring to
> 
> B3.8.2
> Short-descriptor format memory region attributes, without TEX remap

Whoops, yes, it makes more sense now, apologies. Following through the
remap branch it's all consistent.

The implication from this is that the MT_DEVICE_WC case is non-cacheable
normal memory. What's the purpose of the MT_DEVICE_WC case? Is it just
intended to be an non-cacheable?

Finally, there seems to be no memory type for the unbuffered, strongly
ordered. Is there some rationale for that?

Thanks,

Henry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20201201/f4a2a6f1/attachment-0001.sig>


More information about the linux-arm-kernel mailing list