Add a note on serialisation between the tasks and
control/data path.

In D56835#1314434, @bapt wrote:

In D56835#1314322, @kib wrote:

I did not read the whole code, only looked at some syscall interactions, and even this not in the whole sources. At least for now.

Thanks for the freeback, I see all other places where I have been lazy regarding EINTR in particular, I'll fix all of them

ok, i see where the multiple flushing is happening now. and yeah this makes drawing a single pixel have even more overhead! But that's not specifically your problem, its the API that's exposed.

(ie, can you list some of the drawing done by the bootloader that's being accelerated by this?)

hi! Oh, so this is to flush a partial region of the shadow frame buffer rather than the whole framebuffer? How does this accelerate things given the current framebuffer API in stand/ doesn't have an explicit flush() ? (ie, i think every putchar() is an individual rectangle blit, no?)

ship it, thanks!

I think this is great work and I think we should figure out how to adopt it in -head sooner rather than later.

whew this is a whole firmware data pipe and usb controller implementation! this broadly looks okay but i'd like some other usb eyeballs on it.

this broadly looks fine to me!

@imp does this look ok to you now?

This looks fine, we can refactor it further later!

oops, over-did the conversion a bit

• migrate to NET80211_CHANNEL_* macro naming, to avoid adding more IEEE80211 pollution for things that aren't in the 802.11 spec

• add IEEE80211_IS_CHAN_EQUIV() as part of this test
• add a few more conversions

nice catch! Why's this not panicing though? I thought I saw a lock assertion in usb_command_wrapper() ?

How's this relate to D57240 ?

In D48172#1103014, @bz wrote:

Ok, so where do you want to take this? Find all the places in the tree and replace them, just do net80211 and leave the drivers? Just add the macros and let someone else do them all in a go?

Also the IEEE80211_IS_CHAN_ANY() according to https://lists.freebsd.org/archives/freebsd-wireless/2025-January/002700.html

oh, hm, how's 8 RSS queues but > 8 RX queues work? In any case, good catch!

convert the rest of ANYC usage

ugh yeah you're right, our mwait() implementation does the same thing and has the same issues, doesn't it? I've come to increasingly not like that; code really needs to treat exiting the mwait() as "all state may have changed", and it's not really suitable for serialising stuff like usb state / transfers.

So I'm starting to understand what you're trying to do here, however just a few things:

sure, but yes, short-circuit evaluation in C is fine!

wait, we're still missing the sc_is_mmio bits, so I think seuros has to find those diffs and add them to this stack.

In D57146#1309632, @aokblast wrote:

In D57146#1309625, @adrian wrote:

This looks fine, is there somewhere in the XHCI specification you can reference for drop bit handling? It'd be good to have a comment there.

Nice catch!

This is a Note in xHCI spec 4.6.8:

The Reset Endpoint Command may only be issued to endpoints in the Halted
state. If software wishes to reset the Data Toggle or Sequence Number of an
endpoint that isn't in the Halted state, then software may issue a Configure
Endpoint Command with the Drop and Add bits set for the target endpoint
that is in the Stopped state or Running but Idle state.

I will attach this in the comment tomorrow, thanks!:)

This looks fine, is there somewhere in the XHCI specification you can reference for drop bit handling? It'd be good to have a comment there.

Besides wanting some function comments, this looks fine to me. I've had to do this before for MIPS boards whose MAC addresses are not in a common location :(

@bz would you mind taking a look at this and let me know if it's ok to land?

yeah, I'm pretty sure the original interface was for hardware stuff, not per-interface stuff. I don't even recall if we had per-VAP ioctls handled by the driver.

This looks good; how would we unit test this behaviour?

add some receive documentation

ok!

Want to rebase this to use the net80211_rssi_t once that diff lands?

Tested on my intel comet lake desktop w/ nvme attached via an ahci sata/raid integrated, worked just fine.

In D53910#1305645, @vladlen wrote:

In D53910#1305463, @carlavilla wrote:

In D53910#1305462, @mark_freebsdfoundation.org wrote:

@carlavilla The width is too much now - I only ever get the burger menu on my laptop screen, even at max width.

yes, happened the same to me in my computer, the problem is with the Russian language only. Maybe @vladlen can help us and put a short texts

I see the problem: Russian words in the menu are long, making the menu very wide. I have not yet found a good replacement — abbreviated versions of the menu items look rude or like slang. I would also say that the English descriptions are quite long as well, and currently the menu switches to smartphone mode at a width of 1350 px, whereas the recommended breakpoint for smartphones is 767 px.

I have a proposal. When the screen becomes smaller, the angle symbols in the menu wrap to a new line, and the menu looks strange. Could we remove these angles (I mean the HTML elements <i class="fa fa-angle-down fa-lg" aria-hidden="true"></i>)? The menu items look quite visible without these elements. As a result, the screen width can be decreased down to 767 px (smartphone size), and both English and Russian texts look good — for example, "Get FreeBSD" in both languages splits into two lines and looks good. In this case we could use:
@media screen and (max-width: 768px)