This updates ID_AA64MMFR2_EL1.VARange register fields as per the definition
based on DDI0601 2024-03.
Cc: Catalin Marinas <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Anshuman Khandual <[email protected]>
---
This applies on v6.9-rc4
arch/arm64/tools/sysreg | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index a4c1dd4741a4..6d7213dcbeb5 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1739,6 +1739,7 @@ EndEnum
UnsignedEnum 19:16 VARange
0b0000 48
0b0001 52
+ 0b0010 56
EndEnum
UnsignedEnum 15:12 IESB
0b0000 NI
--
2.25.1
On Fri, Apr 19, 2024 at 07:43:25AM +0530, Anshuman Khandual wrote:
> This updates ID_AA64MMFR2_EL1.VARange register fields as per the definition
> based on DDI0601 2024-03.
>
> Cc: Catalin Marinas <[email protected]>
> Cc: Will Deacon <[email protected]>
> Cc: Mark Brown <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Signed-off-by: Anshuman Khandual <[email protected]>
> ---
> This applies on v6.9-rc4
>
> arch/arm64/tools/sysreg | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index a4c1dd4741a4..6d7213dcbeb5 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -1739,6 +1739,7 @@ EndEnum
> UnsignedEnum 19:16 VARange
> 0b0000 48
> 0b0001 52
> + 0b0010 56
Is anybody using this? I'm not sure there's a lot of value in adding
these fields one-by-one for the sake of completeness.
Will
On 4/19/24 19:16, Will Deacon wrote:
> On Fri, Apr 19, 2024 at 07:43:25AM +0530, Anshuman Khandual wrote:
>> This updates ID_AA64MMFR2_EL1.VARange register fields as per the definition
>> based on DDI0601 2024-03.
>>
>> Cc: Catalin Marinas <[email protected]>
>> Cc: Will Deacon <[email protected]>
>> Cc: Mark Brown <[email protected]>
>> Cc: [email protected]
>> Cc: [email protected]
>> Signed-off-by: Anshuman Khandual <[email protected]>
>> ---
>> This applies on v6.9-rc4
>>
>> arch/arm64/tools/sysreg | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
>> index a4c1dd4741a4..6d7213dcbeb5 100644
>> --- a/arch/arm64/tools/sysreg
>> +++ b/arch/arm64/tools/sysreg
>> @@ -1739,6 +1739,7 @@ EndEnum
>> UnsignedEnum 19:16 VARange
>> 0b0000 48
>> 0b0001 52
>> + 0b0010 56
>
> Is anybody using this? I'm not sure there's a lot of value in adding
> these fields one-by-one for the sake of completeness.
This is not being used currently but will be required for upcoming
features. I was under the impression that register fields (atleast
for the ID registers) should be kept updated, with latest released
spec ? Besides lately arch/arm64/tools/sysreg serves as very good
reference for all necessary register fields.
https://developer.arm.com/documentation/ddi0601/2024-03/AArch64-Registers/ID-AA64MMFR2-EL1--AArch64-Memory-Model-Feature-Register-2
On Mon, Apr 22, 2024 at 08:38:40AM +0530, Anshuman Khandual wrote:
>
>
> On 4/19/24 19:16, Will Deacon wrote:
> > On Fri, Apr 19, 2024 at 07:43:25AM +0530, Anshuman Khandual wrote:
> >> This updates ID_AA64MMFR2_EL1.VARange register fields as per the definition
> >> based on DDI0601 2024-03.
> >>
> >> Cc: Catalin Marinas <[email protected]>
> >> Cc: Will Deacon <[email protected]>
> >> Cc: Mark Brown <[email protected]>
> >> Cc: [email protected]
> >> Cc: [email protected]
> >> Signed-off-by: Anshuman Khandual <[email protected]>
> >> ---
> >> This applies on v6.9-rc4
> >>
> >> arch/arm64/tools/sysreg | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> >> index a4c1dd4741a4..6d7213dcbeb5 100644
> >> --- a/arch/arm64/tools/sysreg
> >> +++ b/arch/arm64/tools/sysreg
> >> @@ -1739,6 +1739,7 @@ EndEnum
> >> UnsignedEnum 19:16 VARange
> >> 0b0000 48
> >> 0b0001 52
> >> + 0b0010 56
> >
> > Is anybody using this? I'm not sure there's a lot of value in adding
> > these fields one-by-one for the sake of completeness.
>
> This is not being used currently but will be required for upcoming
> features. I was under the impression that register fields (atleast
> for the ID registers) should be kept updated, with latest released
> spec ? Besides lately arch/arm64/tools/sysreg serves as very good
> reference for all necessary register fields.
Why? The linux headers aren't documenting the architecture.
Will
On Mon, Apr 22, 2024 at 06:16:13PM +0100, Will Deacon wrote:
> On Mon, Apr 22, 2024 at 08:38:40AM +0530, Anshuman Khandual wrote:
> > This is not being used currently but will be required for upcoming
> > features. I was under the impression that register fields (atleast
> > for the ID registers) should be kept updated, with latest released
> > spec ? Besides lately arch/arm64/tools/sysreg serves as very good
> > reference for all necessary register fields.
> Why? The linux headers aren't documenting the architecture.
I don't know that it's something that we should be doing apropos of
nothing but if people have done updates and they're not unreasonbly
complicated to review it does seem useful to integrate them to avoid
duplicated work. There have been some issues with that around the ID
registers (which are going to be on the places most prone to this I
guess).
On 4/23/24 10:47, Mark Brown wrote:
> On Mon, Apr 22, 2024 at 06:16:13PM +0100, Will Deacon wrote:
>> On Mon, Apr 22, 2024 at 08:38:40AM +0530, Anshuman Khandual wrote:
>
>>> This is not being used currently but will be required for upcoming
>>> features. I was under the impression that register fields (atleast
>>> for the ID registers) should be kept updated, with latest released
>>> spec ? Besides lately arch/arm64/tools/sysreg serves as very good
>>> reference for all necessary register fields.
>
>> Why? The linux headers aren't documenting the architecture.
>
> I don't know that it's something that we should be doing apropos of
> nothing but if people have done updates and they're not unreasonbly
> complicated to review it does seem useful to integrate them to avoid
> duplicated work. There have been some issues with that around the ID
> registers (which are going to be on the places most prone to this I
> guess).
The other problem is by not updating the individual register fields with
the latest spec, it also gives an wrong impression about that field, and
also might create confusion.