LGTM! Thanks for your work. I will make the necessary style tweaks before committing (I noted a couple).

Updated for very confusing way of describing the pin drive strength field that had resulted in an off by one error that cleared the pull-up control.

I think I may have had some brain fade about shifting with a shifted number.

As described in my previous comments. Now tested and shown to be working.

Thanks for looking at this. It will be next week before I can test any changes and put up a new, tested diff. I'm away from home at the moment and don't trust doing a restart remotely. I've managed to get the restart working more often that not (it simply doesn't work by default) but haven't got anything working well enough to publish or trust

Hi, thanks for this submission.

I am sorry to speak up only now, after the review sat open for so long. But in looking over the change it seems to be incomplete.

I added MPASS macro following the example of AMD64's code in a corresponding place. I verified that the execution always visits ecall_handler() before it arrives here.

if td1 is always curthread, then a kassert is needed

how hard it would be to implement MSI interface here? to support MSI interrupts from devices, which is a crucial functionality

In D53232#1216532, @jrtc27 wrote:

This will not fix that bug. fence is fence iorw, iorw, so all you are doing is relaxing some ordering requirements.

This will not fix that bug. fence is fence iorw, iorw, so all you are doing is relaxing some ordering requirements.

@jrtc27 I've update the revision, PTAL

In D53232#1216063, @jrtc27 wrote:

Do we actually have a proper definition of what *our* memory barrier APIs are meant to mean? What the ISA manual says is a sensible mapping isn't necessarily what we want; note that the table you're referencing is for "Linux memory primitives", and we are not Linux, nor do we follow its memory model.

Do we actually have a proper definition of what *our* memory barrier APIs are meant to mean? What the ISA manual says is a sensible mapping isn't necessarily what we want; note that the table you're referencing is for "Linux memory primitives", and we are not Linux, nor do we follow its memory model.

Shall I send a new patch? No comments on this one.

FYI, it's best practice to generate diffs with full context (-U999999 or whatever).

• Refactor aplic code into common init and aplic/imsic specific code.
• Add support for IMSIC.

In D43452#1055467, @br wrote:

Hi Himanshu what is status of this? could you regenerate for the latest HEAD ?

Hi Himanshu what is status of this? could you regenerate for the latest HEAD ?

Reworked APLIC_IDC_REG as asked