In D55603#1311570, @afscoelho_gmail.com wrote:

Hi @aokblast, I've found your rapl driver for amd and I'm interested in continuing the work. It's been sitting since March and I'd like to pick it up. Are you still planning to work on it, or would you be OK with me taking over? Thanks

In D57194#1311193, @bz wrote:

Fantasic! You are solving one of my local TODOs :)

Can you make all these USB changes belonging together a stack in Phabricator?
It's a bit hard to grasp which all are there or belong together.
I'd be happy to at least scroll through them even if I cannot review them all in detail most likely.

% git show 9dbb804f59533d7d539200367394e4013714b02c
commit 9dbb804f59533d7d539200367394e4013714b02c
Author:     Bjoern A. Zeeb <bz@FreeBSD.org>
AuthorDate: Mon Feb 9 01:11:41 2026 +0000
Commit:     Bjoern A. Zeeb <bz@FreeBSD.org>
CommitDate: Sun May 24 15:53:58 2026 +0000

    TODO usb: add USB_SPEED_SUPER_PLUS to enum usb_dev_speed
    
    While nothing in our native USB stack uses the USB 3.1 "SUPERSPEED+"
    setting yet, a LinuxKPI based wireless driver does check for it.
    
    TODO: The arrays in usbd_get_std_packet_size() likely need to be updated.
    
    Sponsored by:   The FreeBSD Foundation
    MFC after:      3 days

diff --git sys/dev/usb/usb.h sys/dev/usb/usb.h
index 3e972f876c6a..f07eb9adfe40 100644
--- sys/dev/usb/usb.h
+++ sys/dev/usb/usb.h
@@ -755,8 +755,9 @@ enum usb_dev_speed {
        USB_SPEED_FULL,
        USB_SPEED_HIGH,
        USB_SPEED_SUPER,
+       USB_SPEED_SUPER_PLUS,
 };
-#define        USB_SPEED_MAX   (USB_SPEED_SUPER+1)
+#define        USB_SPEED_MAX   (USB_SPEED_SUPER_PLUS+1)
 
 /*
  * The "USB_REV" macros defines all the supported USB revisions.

In D56970#1310860, @adrian wrote:

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

• this code gets used or was used in some bootloader builds, right? So we need to make sure it runs in its standalone mode versus in the kernel

Minor fixes

Minor fixes

Minor fixes

Minor fixes

FIxes

Rebase to main and use safe_read

Rebase to main

Repalace _NOCFI with __nosanitizerkcfi

Rebase to main and reflect markj@'s comment

Will merge this in next tomorrow.

Rebase to main

@jhb Since it is really trivial. I will merge this next Tuesday if you don't reply.

Rebase to main

bhyve wait mode fails to run with or without this path. I am not sure what is the problem...

Rebase to main

Just split the patch with multiple smaller one.

Split patches

Fixes

In D56970#1310204, @kevans wrote:

Sorry, on the list to give this a closer look today- it looked nice on the surface and cleans up one annoyance I've had in the past with how this stuff works, but I want to be sure that we don't accidentally regress the serial bits.

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!

In D52166#1273856, @bz wrote:

Woohoo. Happy to see updates here.

I've rebased my main once in between; while my smart card reader still works on Win11 after passthru one of my licensing dongles no longer does. I'll grab an updated stack from here the next days and rebuild to see. I haven't had time to debug it anyway so can as well do it on the latest revision. Thanks for all this work!

• xhci: Refactor xhci_generic_setup code
• AI fixed
• AI fix: 2

• fix by me

• draft:
• fix: AI fix
• fix by me

Remove size limit and relies on the frontend

In D57063#1307650, @bz wrote:

What's the expected bandwidth needed for that with VNC? 30Mbit/s?

Elaborate commit msg again

In D57009#1306459, @christos wrote:

I understand that the change here locks the channels we actually want, instead of both of them. However, the effect is the same; if priv has both channels allocated, then your code will also lock both of them, just not at the same time. But I don't understand why doing this fixes the issue. Could you elaborate further?

In D57009#1306393, @christos wrote:

Please explain in a commit message what this change does. What does WITNESS complain about? Why are you changing the order of dsp_lock_chans()? And why did you remove the dsp_lock_chans() call in dsp_poll()?

Elaborate on commit msg

Refactor commit msg

Some lock and unlock stuff

Fix shutdown order

In D55592#1303241, @emaste wrote:

Just received panic: mtx_lock() of spin mutex Fan mutex @ ... upon sysctl -a.
I may not have all updates from this review in place.

Add missing mtx_unlock