LGTM to me. But I think we need feedback from doc group

In D57381#1374059, @markj wrote:

@zishun.yi.dev_gmail.com @aokblast hi, I wonder if anything is blocking landing that LLVM PR upstream? That's the only thing preventing us from committing KASAN support for riscv.

Reflect comment from brooks@

In D57194#1363739, @bz wrote:

In D57194#1311278, @aokblast wrote:

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.

Hi bz@, Thanks for your reply. I might not know what is the correct way to do so. But I think in the stack tab, all of my patches can be seen in here.

I do not see any changes to usb_transfer.c in the stack.
That likely means usbd_get_std_packet_size() array accesses may get out of bounds accesses?
If I am right, this should be addressed somewhere before this or other bits go in.

Expose pcidev/drm

LG for implementation part.

In D59186#1357916, @kevans wrote:

CC releng because this should go into 14.5, IMO, which might mean an expedited MFC. I think this is reasonably safe.

@kevans Could you please check if there is any regression on your yubikey? Thanks!

In D57146#1356729, @oh wrote:

This commit make cheap USB memory key to not attach - see below.
The commit works with Samsung memory keys.
Maybe this is correct and the necessary change to get the cheap noname USB memory keys to work needs to be done in some other place.

======= NOT WORKING ====

DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 0
xhci_cmd_set_tr_dequeue_prt err: 0 drop 0
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 0
xhci_cmd_set_tr_dequeue_prt err: 0 drop 0
ugen0.4: <USB Disk 20> at usbus0
umass0 numa-domain 0 on uhub0
umass0: <USB Disk 20, class 0/0, rev 3.20/2.00, addr 5> on usbus0
umass0: SCSI over Bulk-Only; quirks = 0x0
umass0:3:0: Attached to scbus3
XHCI_EPCTX_0_EPSTATE_DISABLED - fallthrough
XHCI_EPCTX_0_EPSTATE_STOPPED
XHCI_EPCTX_0_EPSTATE_DISABLED - fallthrough
XHCI_EPCTX_0_EPSTATE_STOPPED

XHCI_EPCTX_0_EPSTATE_HALTED err 0 drop 0
XHCI_EPCTX_0_EPSTATE_STOPPED
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 0

++ Repeat last 3 printout 8 times ++

XHCI_EPCTX_0_EPSTATE_HALTED err 0 drop 0
(da8:umass-sim0:0:0:0): got CAM status 0x444
(da8:umass-sim0:0:0:0): fatal error, failed to attach to device
XHCI_EPCTX_0_EPSTATE_STOPPED
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 0
XHCI_EPCTX_0_EPSTATE_HALTED err 0 drop 0
XHCI_EPCTX_0_EPSTATE_STOPPED
(da8:umass-sim0:0:0:0): MODE SENSE for CACHE page command failed.
(da8:umass-sim0:0:0:0): Mode page 8 missing, disabling SYNCHRONIZE CACHE

REVERT COMMIT

DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 1
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 1
ugen0.4: <USB Disk 20> at usbus0
umass0 numa-domain 0 on uhub2
umass0: <USB Disk 20, class 0/0, rev 3.20/2.00, addr 3> on usbus0
umass0: SCSI over Bulk-Only; quirks = 0x0
umass0:3:0: Attached to scbus3
XHCI_EPCTX_0_EPSTATE_DISABLED break
XHCI_EPCTX_0_EPSTATE_DISABLED break
XHCI_EPCTX_0_EPSTATE_HALTED err 0 drop 0
XHCI_EPCTX_0_EPSTATE_STOPPED
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 1
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 1
XHCI_EPCTX_0_EPSTATE_HALTED err 0 drop 0
XHCI_EPCTX_0_EPSTATE_STOPPED
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 1
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 1
XHCI_EPCTX_0_EPSTATE_HALTED err 0 drop 0
XHCI_EPCTX_0_EPSTATE_STOPPED
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 1
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 1
XHCI_EPCTX_0_EPSTATE_HALTED err 0 drop 0
XHCI_EPCTX_0_EPSTATE_STOPPED
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 1
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 1
XHCI_EPCTX_0_EPSTATE_HALTED err 0 drop 0
XHCI_EPCTX_0_EPSTATE_STOPPED
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 1
DEFAULT: xhci_cmd_set_tr_dequeue_prt err: 0 drop 1
da8 at umass-sim0 bus 0 scbus3 target 0 lun 0
da8: <VendorC ProductCode 2.00> Removable Direct Access SPC-2 SCSI device
da8: Serial Number FC3056EA59044
da8: 400.000MB/s transfers
da8: 30000MB (61440000 512 byte sectors)
da8: quirks=0x2<NO_6_BYTE>
(da8:umass-sim0:0:0:0): CACHE PAGE TOO SHORT data len 3 desc len 0
(da8:umass-sim0:0:0:0): Mode page 8 missing, disabling SYNCHRONIZE CACHE

Add manual

Bug fixes

@bapt Hi, My version has been merged by @emaste. Could you please close this?

@bz if you don't have any problem. I will merge this ptach next week.

LGTM!

LGTM

It needs rebase. Do it tomorrow.

Oh, I can re-commit this version. Let me bring it back later.

It is merged by upstream. Close this now

I have merged the 1.9 -> 1.8 patch to main first. Other things fixed. Thanks!

Reflect markj@ and kib@'s comment

Anyway. Thanks!

Versioning

Hi, symbol versioning patch is merged. Please rebase and do necessary change.

In D57381#1348820, @markj wrote:

Hmm, I missed that the LLVM change has not yet landed. @zishun.yi.dev_gmail.com will you add some tests as requested in the PR? If that's done, I wonder if @dim or @aokblast can help land it?

Checked by readelf to see whether all of the public symbols have inside.

Add new missing ABI and bump shlib version

In D55686#1324705, @emaste wrote:

Incorporate feedback from @kib, add new symbols since review was originally created, use SYMBOL_MAPS.
Still TODO: bump shlib version.

In D58756#1348160, @aokblast wrote:

It is found on Gentoo which uses LLVM23 (libcxx23) to build 21. Our cases is good currently as we ship llvm21 in our base.

It is found on Gentoo which uses LLVM23 (libcxx23) to build 21. Our cases is good currently as we ship llvm21 in our base.

LGTM

In D58027#1342667, @mhorne wrote:

In D58027#1342622, @afscoelho_gmail.com wrote:

In D58027#1342399, @aokblast wrote:

Ok! I would like to confirm something with you before committing:

1. Author info: Andre Silva <andasilv@amd.com>
2. Sponsored by: Advanced Micro Devices (AMD)

Are the both desired information you expected?

Yes, they are. Thanks!

Sorry to interfere @aokblast, but I was ready to commit the whole series and just did so.

Ok! I would like to confirm something with you before committing:

In D55035#1341099, @bz wrote:

In D55035#1341066, @aokblast wrote:

In D55035#1341051, @bz wrote:

Thanks for the comment; I have a way larger branch I think than what is in review. Do you want to have a look at the entire bits? I'd be thrilled if someone will review them :) and more than happy to extract the next days.

Do you mean https://reviews.freebsd.org/D54987? I was typing something while you leave your comment:)

No, I mean more changes to be added to the stack; when I first did this it was a/multiple year(s) ago. I put some of that out earlier this year in order to get the de-coupling of LinuxKPI from the native stack structures out but that got into controversial discussions. In the follow-up I added more stuff for more USB wifi drivers ... which I never uploaded to Phab.

I'll go through what you have and would love to put a new stack up next week, if that's okay?

In D55035#1341051, @bz wrote:

Thanks for the comment; I have a way larger branch I think than what is in review. Do you want to have a look at the entire bits? I'd be thrilled if someone will review them :) and more than happy to extract the next days.

LGTM. Waiting for the feedback from @glebius :)

Plus these points, usb_unlink_urb_sub bypass unanchored in not started yet branch. Causing a forever run if the xfer hasn't start yet. Also, we need usb_put_urb in the same point

hi, it would be better to commit D57759, right? I can commit that patch for you.

In D54218#1339119, @unitrunker_protonmail.com wrote:

usbconfig stopped reporting my webcam and fingerprint reader. Instead I get 'usbconfig: could not open device: Bad file descriptor'. Problem goes away when these changes are reverted. A very strange side note: libusb20_int.h is missing from base.txz for 15.1-RELEASE (but is in src.txz). I think the problem is I'm testing against 15.1-RELEASE which is too far behind current. I need to find some hardware onto which I can run current.

I would just abandon it as somebody has much more decent works.

LGTM. Sorry that I though it was copy and paste from line 633. It should work. Thanks!