On platforms not requiring runtime updates to the configuration base address, mconfigptr can be hardwired to zero.

[andreiw]

Is there really a use case here?

mconfigptr is an M-mode register, accessible to tightly-coupled platform firmware, not even to OSes. Do you anticipate that there could be multiple "layers" of M-Mode components, one of which will generate the ASN.1 blob and set the register pointer, while other components are entirely generic and will in turn read this register and decode the ASN.1 blob? Why would this be a good idea? Couldn't these components entirely skip using the CSR and communicate the ASN.1 blob between themselves? And if they are doing that, couldn't these components skip the ASN.1 encoding entirely? Given that the ASN.1 data won't ever leave M mode (S mode will expect DT and maybe generate ACPI...)

mconfigptr makes sense to me only in the sense of a chip coming with hardcoded/microcoded description and the register is RO.

[andreiw]

Also, if mconfigptr is hardwired to zero, then the out-of-band use case is impossible.

[radimkrcmar]

Related to #138.