[bootwrapper PATCH v3 01/15] aarch64: correct ZCR_EL3.LEN initialization

[Mark Brown]

On Tue, Jan 25, 2022 at 04:33:39PM +0000, Mark Rutland wrote:
> On Tue, Jan 25, 2022 at 03:59:38PM +0000, Mark Brown wrote:
> > On Tue, Jan 25, 2022 at 03:00:43PM +0000, Mark Rutland wrote:

> > > As the same time, rename ZCR_EL3_LEN_MASK to ZCR_EL3_LEN_MAX, as it is
> > > used as a value rather than as a bit mask.

> > Well, it's both and we do call it a mask in both the kernel and TF-A
> > too...

> Here specifically in the boot-wrapper I'm just using it as a value, so I don't
> see that those are relevant?

That's also a bunch of the other usage - the kernel uses it to set the
maximum available value by virtue of setting every possible bit in the
bitfield, though it does also use it as a mask in places.

> The idea was to be consistent with the <register>_<field>_<valuename> naming,
> and avoiding the "why are you programming a mask as the value" questions from
> last time around, where the unambiguous options are:

I've not seen that - I did see that there had been some discussion as to
why the code had been including the reserved bits but hadn't seen any
discussion of confusion between mask and max.

> a) Use <register>_<field>_<valuename> definition, as here.

> b) Use <register>_<field>_MASK, and add comments at each usage as to why we use
>    a mask as a value, to explain why that isn't a bug.

> c) Have both <register>_<field>_MASK and some value definition, and use some
>    insertion helper to insert the value.

> ... and I went with (a) because it was the simplest.

> Is there a problem with this?

My concern is continuity of the enumeration algorithm between the
various implementations we have, it's something we're not currently
great with and this creates a separation between the kernel and the boot
wrapper implementations.  There's no change in what's actually being
done but it creates some additional effort to figure out why we're
setting a maximum here and not trying to set all the bits as we do in
the kernel.  TF-A is doing something else again (actually two different
things if you include SME which uses the same algorithm for the
streaming vector length), for SVE it uses a maximum length too but it
uses a lower length than the maximum representable one that's used here.

It may be that the best thing to do is to make this change but also
update the kernel to have separate but identical mask and maximum
definitions, though TBH I'd rather not actually have that update happen
while the SME series is pending.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220125/6e49e689/attachment-0001.sig>