Currently, sysreg has value as 0b0010 for the presence of GICv4.1 in
ID_PFR1_EL1 and ID_AA64PFR0_EL1, instead of 0b0011 as per ARM ARM.
Hence, correct them to reflect ARM ARM.
Signed-off-by: Raghavendra Rao Ananta <redacted>
---
arch/arm64/tools/sysreg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Currently, sysreg has value as 0b0010 for the presence of GICv4.1 in
ID_PFR1_EL1 and ID_AA64PFR0_EL1, instead of 0b0011 as per ARM ARM.
Hence, correct them to reflect ARM ARM.
Signed-off-by: Raghavendra Rao Ananta <redacted>
---
arch/arm64/tools/sysreg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
I wonder why we have different naming schemes for the same feature...
EndEnum
SignedEnum 23:20 AdvSIMD
0b0000 IMP
Yup, this looks correct and checks out against revision H.b of the GICv3
spec, revision K.a of the ARM ARM, and even I.a (which the original
patches were referencing).
Once more, it shows that these dumps should be automatically generated
from the XML instead of (creatively) hand-written.
Reviewed-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
Currently, sysreg has value as 0b0010 for the presence of GICv4.1 in
ID_PFR1_EL1 and ID_AA64PFR0_EL1, instead of 0b0011 as per ARM ARM.
Hence, correct them to reflect ARM ARM.
Signed-off-by: Raghavendra Rao Ananta <redacted>
---
arch/arm64/tools/sysreg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Fortunately there is no user for this bit inside kernel. We had checked
against the correct hard-coded value (0x3) in gic_cpuif_has_vsgi().
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Currently, sysreg has value as 0b0010 for the presence of GICv4.1 in
ID_PFR1_EL1 and ID_AA64PFR0_EL1, instead of 0b0011 as per ARM ARM.
Hence, correct them to reflect ARM ARM.
Signed-off-by: Raghavendra Rao Ananta <redacted>
---
arch/arm64/tools/sysreg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
I wonder why we have different naming schemes for the same feature...
Both definitions were added via different commits and different developers who
might just have interpreted the following common description bit differently.
"System register interface to version 4.1 of the GIC CPU interface is supported"
1224308075f1 ("arm64/sysreg: Convert ID_PFR1_EL1 to automatic generation")
cea08f2bf406 ("arm64/sysreg: Convert ID_AA64PFR0_EL1 to automatic generation")
But I agree that same fields should be named exactly the same both in their 32
bit and 64 bit variants.
quoted
EndEnum
SignedEnum 23:20 AdvSIMD
0b0000 IMP
Yup, this looks correct and checks out against revision H.b of the GICv3
spec, revision K.a of the ARM ARM, and even I.a (which the original
patches were referencing).
Once more, it shows that these dumps should be automatically generated
from the XML instead of (creatively) hand-written.
Reviewed-by: Marc Zyngier <maz@kernel.org>
M.
Currently, sysreg has value as 0b0010 for the presence of GICv4.1 in
ID_PFR1_EL1 and ID_AA64PFR0_EL1, instead of 0b0011 as per ARM ARM.
Hence, correct them to reflect ARM ARM.
Signed-off-by: Raghavendra Rao Ananta <redacted>
---
arch/arm64/tools/sysreg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Currently, sysreg has value as 0b0010 for the presence of GICv4.1 in
ID_PFR1_EL1 and ID_AA64PFR0_EL1, instead of 0b0011 as per ARM ARM.
Hence, correct them to reflect ARM ARM.
Signed-off-by: Raghavendra Rao Ananta <redacted>
---
arch/arm64/tools/sysreg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Currently, sysreg has value as 0b0010 for the presence of GICv4.1 in
ID_PFR1_EL1 and ID_AA64PFR0_EL1, instead of 0b0011 as per ARM ARM.
Hence, correct them to reflect ARM ARM.