rebase + respond to comments

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.

It is in https://reviews.freebsd.org/D57198.

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.

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.

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

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.

I think this is generally a really bad idea.

> kenv | grep vfs
vfs.root.mountfrom="ufs:/dev/ada0p2"
vfs.root.mountfrom.options="rw"

So we almost always have a : in the path, since the boot loader adds it.
And I think it breaks asking for a root device (say if the root is supposed to be nda0, but that's broken, we may not have the thumb drive you plugged in detected before we get to mountroot prompt).
And many people have zpools on usb, even when booting from ada, so their pools will disappear if the boot path is faster.

In D58869#1351233, @ngie wrote:

the root filesystem is on SATA, NVMe, or ZFS (which are never USB).

That's a bit of a bold claim because ZFS can use USB devices. Is it smart? Hell no. Is it possible? Yes. Also, you would need to deal with all GEOM layers, e.g., graid, gmirror, etc.

I understand what you're trying to solve, but I'm a bit skeptical of the approach being taken given how much things can be stacked on top of one another in FreeBSD from a storage perspective between cam (ctl anyone?), geom, and ZFS.

adress comments

In D58869#1351234, @ngie wrote:

Back in the day this also used to be a flat sleep for all of cam.. it was worse than it is currently.
I feel like better dependency tracking needs to be done to avoid this behavior.
Also... this might be deal with/benefit ukbd as back in the good old days (when there was a flat sleep), the mount root prompt would be unusable with USB keyboards, leaving the sysadmin with a wedged computer terminal asking for a root device and not being able to actually input anything on the keyboard to remedy that situation. Wash-rinse-repeat and the reboot cycle increases because power cycling sometimes reinitializes firmware and has to respin up drives in JBODs, etc (especially in the legacy BIOS and old UEFI days).
So yes, this is an inconvenience, but I would temper removing this based only on the names of functions, etc, alone.
Please go through git blame and see whether or not the change that added this code (functionally, not restylized it) was dealing with the case we think it should be dealing with (quiescing USB root devices) instead of dealing with the vfs_mountroot prompt.

Back in the day this also used to be a flat sleep for all of cam.. it was worse than it is currently.
I feel like better dependency tracking needs to be done to avoid this behavior.
Also... this might be deal with/benefit ukbd as back in the good old days (when there was a flat sleep), the mount root prompt would be unusable with USB keyboards, leaving the sysadmin with a wedged computer terminal asking for a root device and not being able to actually input anything on the keyboard to remedy that situation. Wash-rinse-repeat and the reboot cycle increases because power cycling sometimes reinitializes firmware and has to respin up drives in JBODs, etc (especially in the legacy BIOS and old UEFI days).
So yes, this is an inconvenience, but I would temper removing this based only on the names of functions, etc, alone.
Please go through git blame and see whether or not the change that added this code (functionally, not restylized it) was dealing with the case we think it should be dealing with (quiescing USB root devices) instead of dealing with the vfs_mountroot prompt.

the root filesystem is on SATA, NVMe, or ZFS (which are never USB).

The changes seem reasonable. My general concerns with the change are just related to documentation, follow up and potential future collaboration (especially if I start helping out in this space in the next few months).

Rebase

We can and should add every format we need.

Will there be more format as those from /usr/local/include/linux/videodev2.h ?

address comments

Sorry I'm late, thanks for your patience.

tested on my c720 logitech usb camera. it's .. upside down in vlc for some reason, works in browser. i'll test it with other cameras but i think we can / should iterate on this in head post refactor.

rebase

rebase

rebase

use proper device structure