Looking at this again, I think your instinct is right and the block in defs.mk can just go. It came in with the riscv EFI loader (2192efc03bc4), but 79f5991559ce had already moved -mno-relax into bsd.prog.mk and bsd.lib.mk a few months before, so the loader gets the flag from there. I removed it and checked every riscv dir under stand, they all still get -mrelax. I think an .else would also have to go under a riscv check, or else the amd64 and arm64 loaders would get -mrelax. Removing the whole block seems cleaner. What do you think?

Yes, no problem. Sorry, it's not lack of effort on my part, just ignorance. I'm new to this system and didn't know that the summary becomes the commit message, I can understand now why that would be irritating. Give a few moments, please, and I will rewrite.

If you’re to use them, at least have the decency to remove all the slop and write a proper commit message. As it stands this is a very low-effort change that feels extractive.

In D60278#1383212, @jrtc27 wrote:

Did you use LLMs to generate this?

Did you use LLMs to generate this?

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