Fix make_dtb.sh

Shuffle the bindings to a new location!

Let's see if this fixes where the tcsr.h file went in the review.

Address more comments!

more updates!

More comment addressing

Address comments!

In D32538#734113, @manu wrote:

DTS and bindings shouldn't be there, it's only for the upstream ones.

Fix comment, thanks bz!

In D32538#734113, @manu wrote:

DTS and bindings shouldn't be there, it's only for the upstream ones.

net80211 has a whole chunk of things you can set when raw tx'ing frames via BPF. I think this is fine!

In D31215#702999, @avg wrote:

@adrian , in my opinion two things guarantee correct operation:

• the current element can never be removed (thanks to in_use)
• an iteration is always done with the lock held

So, whatever perturbations might happen while the lock is dropped, they should settle down before the next iteration.

In D31215#702973, @avg wrote:

@adrian , I thought that I took care of that via the in_use flag.
Could you please look again?

in general I agree with "push it into a thread", especially since we want to support LED blinking on things like behind an i2c bus, but the unlock;func;lock thing without checking the list has changed or the LED itself has been deleted is problematic to me. Yes, sure, the race is tiny and it only affects things if we're modifying the list at the same time we're doing some work, but surely we can handle that case. :-) That's why it was locked in the first place!

Oh I get it. DELAY(1) is delaying for one microsecond, which is too slow for what we're doing here.

Good catch!

nuke iiit

Yeah, I was thinking the same thing. It gets a bit unfun when we start looking at how we drain this versus direct dispatch, but let's tackle that later.

Nah, this already landed a long long time ago.

lol! this is old!

i mean, ok, until i move them into base proper :-P

Yeah, you're right, I've been neck deep in linux and internal OS regulatory domain stuff too much recently :(

Let's look at the maxpower more carefully!

err? ok, let me go and re-revisit this again.

In D28122#628804, @arichardson wrote:

Seems fine to me, but I do wonder if this means that we have some UB that clang could also exploit in the future and generate crashing code. Any idea which function the first crash is inside?

• Update to only do this with GCC
• Add comment

(I haven't forgotten about this; I only just got mips32 to boot again...)

In D27778#623889, @koobs wrote:

In D27778#623886, @adrian wrote:

hi!

In D27778#620891, @bofh wrote:

In D27778#620866, @koobs wrote:

Also Question: do any of the other qemu-* ports need to have this change made too, or do they all inherit/child port off the main one (I haven't looked)

All qemu-* ports needs to be updated.

Can I just try to land this one first, and worry about the others later? I'd at least like to see a working qemu port with user networking available for other freebsd users to test with.

Sure, let's just follow this changeset up in a timely manner so all ports are consistent

Re PORTLINT output, these ones at least should be addressed:

WARN: Makefile: you may want directory for dependency sphinx-build to be textproc/py-sphinx@${PY_FLAVOR}
WARN: Makefile: "ONLY_FOR_ARCHS" has to appear earlier.
WARN: Makefile: "USES" has to appear earlier.

Portlint output:

In D27778#620891, @bofh wrote:

In D27778#620866, @koobs wrote:

Also Question: do any of the other qemu-* ports need to have this change made too, or do they all inherit/child port off the main one (I haven't looked)

All qemu-* ports needs to be updated.

ryan - I'll push this later today, but i figured you would want to see it as well :-)

Add portrevision

In D27608#616994, @imp wrote:

Can you get this accepted upstream?