| Message ID | 20241203-arm64-2024-dpisa-v3-2-a6c78b1aa297@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | arm64: Support 2024 dpISA extensions | expand |
On Tue, Dec 03, 2024 at 12:39:21PM +0000, Mark Brown wrote: > DDI0601 2024-09 defines several new feature flags in ID_AA64ISAR3_EL1, > update our description in sysreg to reflect these. > > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > arch/arm64/tools/sysreg | 18 +++++++++++++++++- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg > index 911f16c82ebd3ee98ffed965b02a5c6b153bc50c..c5af604eda6a721cedf5c9c68d6f7038156de651 100644 > --- a/arch/arm64/tools/sysreg > +++ b/arch/arm64/tools/sysreg > @@ -1566,7 +1566,23 @@ EndEnum > EndSysreg > > Sysreg ID_AA64ISAR3_EL1 3 0 0 6 3 > -Res0 63:16 > +Res0 63:32 > +UnsignedEnum 31:28 FPRCVT > + 0b0000 NI > + 0b0010 IMP > +EndEnum > +UnsignedEnum 27:24 LSUI > + 0b0000 NI > + 0b0010 IMP > +EndEnum > +UnsignedEnum 23:20 OCCMO > + 0b0000 NI > + 0b0010 IMP > +EndEnum > +UnsignedEnum 19:16 LSFE > + 0b0000 NI > + 0b0010 IMP These IMP encodings look wrong to me -- the document you reference in the commit message uses 0b0001 for the "implemented" cases. Can we _please_ just generate this stuff. It feels like we've been making silly typos over and over again with the current approach so either it's hard or we're not very good at it. Either way, it should be automated. Others have managed it [1], so it's clearly do-able. Will [1] https://github.com/ashwio/arm64-sysreg-lib
On Tue, Dec 10, 2024 at 05:09:55PM +0000, Will Deacon wrote: > Can we _please_ just generate this stuff. It feels like we've been > making silly typos over and over again with the current approach so > either it's hard or we're not very good at it. Either way, it should be > automated. > Others have managed it [1], so it's clearly do-able. Yes, the issues here are not technical ones. Though there are some complications - eg, IIRC the XML doesn't encode the signedness of fields like we do and there's areas where we've deliberately diverged. Given the amount of review I end up having to do of sysreg changes your reasoning is especially apparent to me. I've passed this feedback on (again).
On Tue, Dec 10, 2024 at 06:43:05PM +0000, Mark Brown wrote: > On Tue, Dec 10, 2024 at 05:09:55PM +0000, Will Deacon wrote: > > > Can we _please_ just generate this stuff. It feels like we've been > > making silly typos over and over again with the current approach so > > either it's hard or we're not very good at it. Either way, it should be > > automated. > > > Others have managed it [1], so it's clearly do-able. > > Yes, the issues here are not technical ones. Though there are some > complications - eg, IIRC the XML doesn't encode the signedness of > fields like we do and there's areas where we've deliberately diverged. > Given the amount of review I end up having to do of sysreg changes your > reasoning is especially apparent to me. I've passed this feedback on > (again). One thing we _could_ do is have a tool (in-tree) that takes two copies of the sysreg file (i.e. before and after applying a diff) along with a copy of the XML and, for the the new fields being added, shows how the XML represents those compared to the diff. It should then be relatively straightforward to flag the use of an unallocated encoding (like we had here) and also things like assigning a field name to a RES0 region. So this wouldn't be generating the patches from the XML, but more like using the XML as an oracle in a linter. Will
On Wed, Dec 11, 2024 at 10:40:15PM +0000, Will Deacon wrote: > On Tue, Dec 10, 2024 at 06:43:05PM +0000, Mark Brown wrote: > > Yes, the issues here are not technical ones. Though there are some > > complications - eg, IIRC the XML doesn't encode the signedness of > > fields like we do and there's areas where we've deliberately diverged. > > Given the amount of review I end up having to do of sysreg changes your > > reasoning is especially apparent to me. I've passed this feedback on > > (again). > One thing we _could_ do is have a tool (in-tree) that takes two copies > of the sysreg file (i.e. before and after applying a diff) along with a > copy of the XML and, for the the new fields being added, shows how the > XML represents those compared to the diff. It should then be relatively > straightforward to flag the use of an unallocated encoding (like we had > here) and also things like assigning a field name to a RES0 region. > So this wouldn't be generating the patches from the XML, but more like > using the XML as an oracle in a linter. That'd be useful, yes - unfortunately I think that's still something I can't work on myself at the moment for the above mentioned non-technical reasons.
On Thu, Dec 12, 2024 at 11:33:05AM +0000, Mark Brown wrote: > On Wed, Dec 11, 2024 at 10:40:15PM +0000, Will Deacon wrote: > > On Tue, Dec 10, 2024 at 06:43:05PM +0000, Mark Brown wrote: > > > > Yes, the issues here are not technical ones. Though there are some > > > complications - eg, IIRC the XML doesn't encode the signedness of > > > fields like we do and there's areas where we've deliberately diverged. > > > Given the amount of review I end up having to do of sysreg changes your > > > reasoning is especially apparent to me. I've passed this feedback on > > > (again). > > > One thing we _could_ do is have a tool (in-tree) that takes two copies > > of the sysreg file (i.e. before and after applying a diff) along with a > > copy of the XML and, for the the new fields being added, shows how the > > XML represents those compared to the diff. It should then be relatively > > straightforward to flag the use of an unallocated encoding (like we had > > here) and also things like assigning a field name to a RES0 region. > > > So this wouldn't be generating the patches from the XML, but more like > > using the XML as an oracle in a linter. > > That'd be useful, yes - unfortunately I think that's still something I > can't work on myself at the moment for the above mentioned non-technical > reasons. Is anybody able to work on it? Without insight into the "non-technical reasons", I don't know what I'm supposed to do other than write the tool myself (which means finding some spare cycles...) or refusing to take wholesale sysreg definitions until it's been ironed out :/ Will
On Thu, Dec 19, 2024 at 03:55:48PM +0000, Will Deacon wrote: > On Thu, Dec 12, 2024 at 11:33:05AM +0000, Mark Brown wrote: > > That'd be useful, yes - unfortunately I think that's still something I > > can't work on myself at the moment for the above mentioned non-technical > > reasons. > Is anybody able to work on it? Without insight into the "non-technical > reasons", I don't know what I'm supposed to do other than write the tool > myself (which means finding some spare cycles...) or refusing to take > wholesale sysreg definitions until it's been ironed out :/ Similar issues will apply to anyone at Arm as things currently stand.
On Thu, Dec 19, 2024 at 04:39:11PM +0000, Mark Brown wrote: > On Thu, Dec 19, 2024 at 03:55:48PM +0000, Will Deacon wrote: > > On Thu, Dec 12, 2024 at 11:33:05AM +0000, Mark Brown wrote: > > > That'd be useful, yes - unfortunately I think that's still something I > > > can't work on myself at the moment for the above mentioned non-technical > > > reasons. > > Is anybody able to work on it? Without insight into the "non-technical > > reasons", I don't know what I'm supposed to do other than write the tool > > myself (which means finding some spare cycles...) or refusing to take > > wholesale sysreg definitions until it's been ironed out :/ > Similar issues will apply to anyone at Arm as things currently stand. Oh, actually - shortly after I sent this mail I got a notification that there's now an "Open Source Machine Readable Data" package at: https://developer.arm.com/Architectures/A-Profile%20Architecture#Downloads as part of the 2024-12 which should unblock this, just in time for Christmas. There's just the small matter of free time to resolve!
On Thu, Dec 19, 2024 at 04:49:05PM +0000, Mark Brown wrote: > On Thu, Dec 19, 2024 at 04:39:11PM +0000, Mark Brown wrote: > > On Thu, Dec 19, 2024 at 03:55:48PM +0000, Will Deacon wrote: > > > On Thu, Dec 12, 2024 at 11:33:05AM +0000, Mark Brown wrote: > > > > > That'd be useful, yes - unfortunately I think that's still something I > > > > can't work on myself at the moment for the above mentioned non-technical > > > > reasons. > > > > Is anybody able to work on it? Without insight into the "non-technical > > > reasons", I don't know what I'm supposed to do other than write the tool > > > myself (which means finding some spare cycles...) or refusing to take > > > wholesale sysreg definitions until it's been ironed out :/ > > > Similar issues will apply to anyone at Arm as things currently stand. > > Oh, actually - shortly after I sent this mail I got a notification that > there's now an "Open Source Machine Readable Data" package at: > > https://developer.arm.com/Architectures/A-Profile%20Architecture#Downloads > > as part of the 2024-12 which should unblock this, just in time for > Christmas. There's just the small matter of free time to resolve! <party.gif> That's great! Hopefully we can knock up some basic linter tools in the new year. Thanks, Will
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg index 911f16c82ebd3ee98ffed965b02a5c6b153bc50c..c5af604eda6a721cedf5c9c68d6f7038156de651 100644 --- a/arch/arm64/tools/sysreg +++ b/arch/arm64/tools/sysreg @@ -1566,7 +1566,23 @@ EndEnum EndSysreg Sysreg ID_AA64ISAR3_EL1 3 0 0 6 3 -Res0 63:16 +Res0 63:32 +UnsignedEnum 31:28 FPRCVT + 0b0000 NI + 0b0010 IMP +EndEnum +UnsignedEnum 27:24 LSUI + 0b0000 NI + 0b0010 IMP +EndEnum +UnsignedEnum 23:20 OCCMO + 0b0000 NI + 0b0010 IMP +EndEnum +UnsignedEnum 19:16 LSFE + 0b0000 NI + 0b0010 IMP +EndEnum UnsignedEnum 15:12 PACM 0b0000 NI 0b0001 TRIVIAL_IMP
DDI0601 2024-09 defines several new feature flags in ID_AA64ISAR3_EL1, update our description in sysreg to reflect these. Signed-off-by: Mark Brown <broonie@kernel.org> --- arch/arm64/tools/sysreg | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)