In D52744#1205716, @alc wrote:

In D52744#1205060, @andrew wrote:

Note that the llsc instructions have some subtly when implementing fully sequentially consistent semantics. As the acquire and release are on different instructions this means memory operations may move into the sequence & be swapped. As we don't implement them in atomic(9) this shouldn't be an issue, however will be if we latter add them.

I vaguely recall Linux having an issue with the aforementioned behavior about 8-10 years ago in the implementation of a synchronization primitive.

On arm64 atomics with an acquire then later memory operations can move before the store, however the store needs to succeed as if it doesn't then we will execute the load-acquire again.

Won't that cause problems for stable/15 when stable/16 is branched?

Rebase + update comments

I'm just trying to keep things out of early boot if they don't need to be there.

I'm not opposed to the current change, but think it would be less confusing if we pass a value that is more obvious it is negative to the stp instructions.

Are you receiving the exception within the exception entry asm? I can easily see functional issues if they happen before the stp on line 73, although it may not be until later to be fully safe.

I've added support to manage which features/errata are enabled at boot time & used this to disable this workaround by default, but let the user enable it if they are affected by it.

• Fix a midr check
• Rebase past D52358 so the workaround is disabled by default, but can be enabled

In D52342#1195108, @emaste wrote:

As an aside, I compared non-device-specific options in sys/amd64/conf/GENERIC and sys/arm64/conf/std.arm64. Aside from this BLOAT_KERNEL_WITH_EXTERR the following differences exist:

arm64 only

• CC_CUBIC

I expect we would need bus_activate_resource as it's called via bus_generic_rman_alloc_resource in gpiobus_alloc_resource.

Use the correct revision range