All cool by me.

I am ready to commit this and have applied my suggested changes locally. Please confirm that you are happy with the copyright header text, and I will proceed.

Made changes as suggested.

New diff in a few minutes.

Note, the eqos(4) driver has an uncertain future. It is possible that we will move to supporting this hardware with the dwc(4) driver instead; see https://reviews.freebsd.org/D59191 if interested.

Generally LGTM, with some minor tweaks needed.

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.