[PATCH v4 01/26] arm64/cpuinfo: Restore define for AIVIVT cache type

[Mark Rutland]

On Wed, Jun 22, 2022 at 01:04:53PM +0100, Mark Brown wrote:
> On Wed, Jun 22, 2022 at 12:09:33PM +0100, Mark Rutland wrote:
> > On Mon, Jun 20, 2022 at 01:43:42PM +0100, Mark Brown wrote:
> > > In 155433cb365ee466 ("arm64: cache: Remove support for ASID-tagged VIVT
> > > I-caches") we removed all the support fir AIVIVT cache types and renamed
> > > all references to the field to say "unknown" since support for AIVIVT
> > > caches was removed from the architecture. Since the correspoding removal
> 
> > I'm not too keen on this, becuase architecturally AIVIVT does not exist in
> > ARMv8, and the real bug here is that the ARM ARM still calls this AIVIVT rather
> > than saying it's reserved.
> 
> Yes, it's rather difficult to divine the intent of the architecture here
> - I was erring on the side of the name having been left there for *some*
> reason, though equally it could just be done that way to ensure nobody
> confuses things by trying to allocate what looks like a previously
> reserved value in future.

Sure; I completely agree this is not at all clear, and as above I'd argue this
is a bug (or at least a deficiency of clarity) in the ARM ARM.

> > > -#define ICACHE_POLICY_RESERVED	1
> > > +#define ICACHE_POLICY_AIVIVT	1
> 
> > How about we just delete ICACHE_POLICY_RESERVED entirely...
> 
> Sure.
> 
> > ... then in subsequent patches we don't need to define a bogus
> > ICACHE_POLICY_AIVIVT value in the scripted headers.
> 
> I think if we don't have the value be the same as it is in the
> architecture we're going to have the next person who happens to look at
> this go and try to define the missing value again.  I suppose we can add
> a comment in the text file...

FWIW, I'm perfectly happy with a comment along the lines of:

# AIVIVT is deprecated and the encoding is reserved from ARMv8.0

... at the right place in the sysreg definitions file.

Thanks,
Mark