On Fri, Oct 12, 2018 at 09:56:05AM +0100, Will Deacon wrote:

On Fri, Oct 12, 2018 at 09:53:54AM +0100, Mark Rutland wrote:

quoted

On Thu, Oct 11, 2018 at 05:28:14PM +0100, Will Deacon wrote:

quoted

On Fri, Oct 05, 2018 at 09:47:38AM +0100, Kristina Martsenko wrote:

quoted

quoted

+#define ESR_ELx_EC_PAC		(0x09)

Really minor nit: but shouldn't this be ESR_EL2_EC_PAC, since this trap
can't occur at EL1 afaict?

It can also be taken to EL3 dependent on SCR_EL3.API.

We use ESR_ELx_EC_<foo> for other exceptions that can't be taken to EL1
(e.g. ESR_ELx_EC_SMC{32,64}), so I think it would be more consistent to
leave this as ESR_ELx_EC_PAC rather than ESR_EL2_EC_PAC.

Fair enough, but if we grow a different EC for ESR_EL1 that uses encoding
0x09, this all falls apart.

We haven't had overlapping encodings so far, and if we did, we'd want to
apply some policy to all of these definitions, no?

At the very list, maybe we should comment those that are EL2 or higher
with /* EL2 and above */ or just fix the misnomer and drop the useless
_ELx_ part of the names completely.

A comment sounds fine to me.

I'm not sure that s/_ELx// buys us any clarity, though; I don't think
that ESR_EC_PAC is clearly more constrained than ESR_ELx_EC_PAC.

Thanks,
Mark.