Dave Martin [off-list ref] writes:

On Mon, Aug 21, 2017 at 03:50:32PM +0100, Alex Benn?e wrote:

quoted

Dave Martin [off-list ref] writes:

quoted

On Mon, Aug 21, 2017 at 01:34:38PM +0100, Alex Benn?e wrote:

[...]

quoted

quoted

quoted

quoted

Dave Martin [off-list ref] writes:

[...]

quoted

quoted

quoted

quoted

quoted

+#define ZCR_ELx_LEN_SHIFT	0
+#define ZCR_ELx_LEN_SIZE	9
+#define ZCR_ELx_LEN_MASK	0x1ff
+

LEN should be 0/4/0xf

LEN, bits [3:0]

Constrains the scalable vector register length for EL1 and EL0 to
(LEN+1)x128 bits.

The SVE supplement is not very explicit about the meaning of bits [8:4],
but they are reserved to extend the LEN field in the future, in case
that's ever needed for future architecture revisions.  I've aimed for
Linux to cope with this.

Basically bits [8:4] are read-as-zero, write-ignore today, but in
the future some or all of them may be LEN field bits.

In particular, this means that writing all bits [8:0] with 1 will
configure the largest supported vector length, even on future
architecture versions that may have a larger LEN field.

Ahh ok. It's not clear from the html and it is certainly implied in the
supplement (2.1.1) that the architectural max is:

  The size of every vector register is an IMPLEMENTATION DEFINED
  multiple of 128 bits, up to an architectural maximum of 2048 bits.

quoted

It didn't seem useful to distinguish the two classes of bits here.

Maybe a comment clarifying would be useful then?

OK, I think I can say something like:

/*
 * The ZCR_ELx_LEN_* definitions intentionally include bits [8:4]
 * which are reserved by the SVE architecture for future expansion of
 * the LEN field, with compatible semantics.
 */

Any good?

Works for me ;-)

Cheers
---Dave

--
Alex Benn?e