Re: [PATCH v3 2/9] arm64/sysreg: Update ID_AA64ISAR3_EL1 to DDI0601 2024-09

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux