[PATCH v2 4/4] arm64: Document values for system registers on boot

[Mark Brown]

On Thu, Apr 08, 2021 at 06:16:03PM +0100, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:

> > Specify that where the architecture provides a reset value that value
> > must be used.

> >    level where the kernel image will be entered must be initialised by
> >    software at a higher exception level to prevent execution in an UNKNOWN
> > -  state.
> > +  state.  Where these architected system registers have reset values
> > +  specified by the architecture they must be initialised to those values
> > +  unless specified more specifically.

> Is that always enforceable? Is that even desirable?

I'm not convinced on either front frankly, like I said in the cover
letter I was worrying that it is too strict a requirement.  I couldn't
think of a better/more appropriate wording and figured it might start a
discussion.

> Take for example ICC_SRE_EL2.SRE. The reset value for that bit is
> 0. But it is extremely likely that the FW has set this bit to 1 in
> order to be able to use interrupts with the sysreg interface. However,
> as outlined in the GIC spec:

> <quote>
> If software changes this bit from 1 to 0, the results are UNPREDICTABLE.
> </quote>

That definitely means it's unenforcable without an explict override for
that case, having now seen that case I'm sure there's others.

> We could go and specify this one, but I fear there is a lot of things
> we'd have to make explicit...

Yeah, that's pushing me towards dropping this patch.  We could add a
general statement recommending that people use the defaults without
actually requiring it but that's just vague and unenforcable instead of
strict and unimplementable which isn't particularly better.  If we're
going to have to keep updating the document it's going to be less effort
all round to just update for cases we can't handle in code rather than
keep on adding exceptions and require firmware to reset lots of stuff we
don't *really* have strict requirements for.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210408/8015603d/attachment.sig>