NetBSD Problem Report #60073

From tsutsui@ceres.dti.ne.jp  Thu Mar 12 18:53:47 2026
Return-Path: <tsutsui@ceres.dti.ne.jp>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "R12" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 2D8141A9239
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 12 Mar 2026 18:53:47 +0000 (UTC)
Message-Id: <202603121853.62CIrdgd008699@ceres.dti.ne.jp>
Date: Fri, 13 Mar 2026 03:53:39 +0900 (JST)
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Reply-To: tsutsui@ceres.dti.ne.jp
To: gnats-bugs@NetBSD.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: xhci(4): NetBSD xHCI roothub uses ud_addr=0 instead of 1?
X-Send-Pr-Version: 3.95
X-From4GNATS: "Izumi Tsutsui via gnats" <gnats-admin@NetBSD.org>

>Number:         60073
>Category:       kern
>Synopsis:       xhci(4): NetBSD xHCI roothub uses ud_addr=0 instead of 1?
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 12 18:55:00 +0000 2026
>Last-Modified:  Thu Mar 19 23:55:00 +0000 2026
>Originator:     Izumi Tsutsui
>Release:        NetBSD 10.1
>Organization:
>Environment:
System: NetBSD mirage 10.1 NetBSD 10.1 (GENERIC) #3: Mon Jan 5 01:48:52 JST 2026 tsutsui@mirage:/s/netbsd-10/src/sys/arch/i386/compile/GENERIC i386
Architecture: all (tested on i386 and amd64)
Machine: all (S/A)
>Description:
This is partly a question about intended semantics/design,
but it also affects correctness when the USB layer design assumes
"ud_addr and ub_devices[] indexing are consistent".

src/sys/dev/usb/usb.h defines:

#define USB_MAX_DEVICES         128             /* 0, 1-127 */
#define USB_MIN_DEVICES         2               /* unused + root HUB */
#define USB_START_ADDR          0

so this looks to imply
- address 0 as the default/unconfigured address
- address 1 as the first usable permanent address, typically the root hub

The implementation of usbd_new_device() in src/sys/dev/usb/usb_subr.c
seems to follow the above assumption, even in the roothub case:

---
int
usbd_getnewaddr(struct usbd_bus *bus)
{
	int addr;

	for (addr = 1; addr < USB_MAX_DEVICES; addr++) {
		size_t dindex = usb_addr2dindex(addr);
		if (bus->ub_devices[dindex] == NULL)
			return addr;
	}
	return -1;
}

 :

usbd_status
usbd_new_device(device_t parent, struct usbd_bus *bus, int depth, int speed,
    int port, struct usbd_port *up)
{

 :

	addr = usbd_getnewaddr(bus);

 :

	dev->ud_addr = USB_START_ADDR;

 :

	/* Set the address */
	DPRINTFN(5, "setting device address=%jd", addr, 0, 0, 0);
	err = usbd_set_address(dev, addr);
	if (err) {
		DPRINTF("set address %jd failed, err = %jd", addr, err, 0, 0);
		err = USBD_SET_ADDR_FAILED;
		usbd_remove_device(dev, up);
		return err;
	}

	/* Allow device time to set new address */
	usbd_delay_ms(dev, USB_SET_ADDRESS_SETTLE);
	dev->ud_addr = addr;	/* new device address now */
	bus->ub_devices[usb_addr2dindex(addr)] = dev;

 :

---

However, in xHCI xhci_new_device(), the root hub is created with
addr=0 (without explicit initialization):

---
static usbd_status
xhci_new_device(device_t parent, struct usbd_bus *bus, int depth,
    int speed, int port, struct usbd_port *up)
{

 :
	dev->ud_addr = 0;

 :

	if (depth == 0 && port == 0) {
		KASSERT(bus->ub_devices[USB_ROOTHUB_INDEX] == NULL);
		bus->ub_devices[USB_ROOTHUB_INDEX] = dev;

		/* Establish the default pipe. */
		err = usbd_setup_pipe(dev, 0, &dev->ud_ep0,
		    USBD_DEFAULT_INTERVAL, &dev->ud_pipe0);
		if (err) {
			DPRINTFN(1, "setup default pipe failed %jd", err,0,0,0);
			goto bad;
		}
		err = usbd_get_initial_ddesc(dev, dd);
		if (err) {
			DPRINTFN(1, "get_initial_ddesc %ju", err, 0, 0, 0);
			goto bad;
		}
	} else {

 :
---

Actually, xHCI root hub is attached at addr 0:

---
uhub0 at usb0: NetBSD (0x0000) xHCI root hub (0x0000), class 9/0, rev 3.00/1.00, addr 0
uhub0: 4 ports with 4 removable, self powered
uhub1 at usb1: NetBSD (0x0000) xHCI root hub (0x0000), class 9/0, rev 2.00/1.00, addr 0
uhub1: 4 ports with 4 removable, self powered
---

So xHCI stores the roothub in ub_devices[USB_ROOTHUB_INDEX]
(where USB_ROOTHUB_INDEX is 1) while keeping ud_addr == 0.

Note ehci, ohci, and dwtwo etc. use addr=1 for root hubs:
---
uhub2 at usb4: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhub3 at usb2: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
uhub4 at usb3: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
uhub4: 2 ports with 2 removable, self powered
uhub5 at usb6: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
uhub5: 2 ports with 2 removable, self powered
uhub6 at usb5: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
uhub6: 2 ports with 2 removable, self powered
uhub7 at usb7: NetBSD (0x0000) EHCI root hub (0x0000), class 9/0, rev 2.00/1.00, addr 1
uhub7: 10 ports with 10 removable, self powered
---

---
uhub0 at usb0: NetBSD (0x0000) DWC2 root hub (0x0000), class 9/0, rev 2.00/1.00, addr 1
uhub0: 1 port with 1 removable, self powered
---

FreeBSD and OpenBSD also use addr=0 for xHCI root hubs.

I am not sure whether this is an intentional NetBSD xHCI design choice,
or an inconsistency in the xHCI implementation.

If intentional, it may be worth documenting clearly.
If not intentional, it may be preferable to align xHCI
roothub address handling with the rest of the USB stack
(ehci/ohci etc.) and with other BSDs.

This question became visible while debugging a separate
xHCI cleanup issue: the roothub is kept at ub_devices[1]
but has ud_addr == 0, code paths that index cleanup by
ud_addr can accidentally affect the roothub slot
(I'll file an independent PR about this issue).

>How-To-Repeat:

1) Boot NetBSD on a machine with xHCI
2) Observe xHCI roothub attach lines in dmesg (see above)

>Fix:
Yes, please.

---
Izumi Tsutsui

>Audit-Trail:
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
        tsutsui@ceres.dti.ne.jp
Subject: Re: kern/60073: xhci(4): NetBSD xHCI roothub uses ud_addr=0 instead
	 of 1?
Date: Fri, 13 Mar 2026 03:58:33 +0900

 Sorry, a fatal typo:

 > FreeBSD and OpenBSD also use addr=0 for xHCI root hubs.

 This should be
 >> FreeBSD and OpenBSD also use addr=1 for xHCI root hubs.

 https://dmesgd.nycbug.org/index.cgi?do=view&id=8854
 >> uhub0: <AMD XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1

 https://dmesgd.nycbug.org/index.cgi?do=view&id=8824
 >> uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1

 ---
 Izumi Tsutsui

From: "Jonathan A. Kollasch" <jakllsch@kollasch.net>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/60073: xhci(4): NetBSD xHCI roothub uses ud_addr=0 instead
 of 1?
Date: Thu, 12 Mar 2026 14:40:28 -0500

 Using address 0 for the NetBSD xhci(4) root hub is precisely what I
 intended to do.

 An xHCI hardware/firmware implementation has exclusive discretion as to
 how it allocates bus addresses to devices.  The only address it will
 never give a device is 0, as that is the un-addressed initial state of
 a new device.  An xHCI hardware/firmware implementation is allowed to
 use identical USB addresses for real devices on different bus interfaces
 (think multiple USB1/2 bus interfaces to increase available bandwidth
 across multiple USB1/2 root ports).  Hardware/firmware implementations
 are also allowed to allocate address 1 to a device on the bus(es).

 The OS's USB root hub is *not* a real device.  USB Transactions to the
 OS-implemented root hub never reach the data lines of the bus, and there
 is no mechanism to notify the xHCI hardware/firmware that the OS has
 reserved a bus address for a virtual (root hub) device.

 Any solution to 60074 should take these constraints into account.

 I agree this should be documented in comments in the code.

From: "Izumi Tsutsui" <tsutsui@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60073 CVS commit: pkgsrc/comms/libhidapi
Date: Fri, 13 Mar 2026 10:37:25 +0000

 Module Name:	pkgsrc
 Committed By:	tsutsui
 Date:		Fri Mar 13 10:37:25 UTC 2026

 Modified Files:
 	pkgsrc/comms/libhidapi: Makefile PLIST distinfo
 Added Files:
 	pkgsrc/comms/libhidapi/patches: patch-netbsd_CMakeLists.txt
 	    patch-netbsd_hid.c

 Log Message:
 libhidapi: update to 0.15.0

 pkgsrc changes:

  - add PLIST_VARS for libhidapi-netbsd (NetBSD HID native backend)
  - pull iconv(3) const check from libusb version
  - check both addr 0 and 1 on enumerating devices (see NetBSD PR/60073)

 Upstream changes:
  https://github.com/libusb/hidapi/releases/tag/hidapi-0.15.0

 general: Add hid_send_output_report() (#677)
 general: Add hid_read_error() (#721)

 winapi: add hid_winapi_set_write_timeout (#700)
 winapi: improvements for hid_get_report_descriptor/hid_winapi_descriptor_reconstruct_pp_data (#707)

 hidraw: report only Top-Level Usage_page/Usage pairs as 'unique' devices (#601)

 macOS: add option to mimic 1.0.0 compatibility version (#709)

 NetBSD: UHID native backend implementation (#612)

 libusb: add abstraction for thread model, allow building using non-POSIX runtime
 libusb: enable support for Xbox 360 and Xbox One controllers (#572)

 general: various other fixes and improvements


 To generate a diff of this commit:
 cvs rdiff -u -r1.12 -r1.13 pkgsrc/comms/libhidapi/Makefile
 cvs rdiff -u -r1.8 -r1.9 pkgsrc/comms/libhidapi/PLIST
 cvs rdiff -u -r1.9 -r1.10 pkgsrc/comms/libhidapi/distinfo
 cvs rdiff -u -r0 -r1.1 \
     pkgsrc/comms/libhidapi/patches/patch-netbsd_CMakeLists.txt \
     pkgsrc/comms/libhidapi/patches/patch-netbsd_hid.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: jakllsch@kollasch.net
Cc: gnats-bugs@netbsd.org, tsutsui@ceres.dti.ne.jp
Subject: Re: kern/60073: xhci(4): NetBSD xHCI roothub uses ud_addr=0 insteadof
	 1?
Date: Fri, 20 Mar 2026 08:53:56 +0900

 jakllsch@ wrote:

 > Any solution to 60074 should take these constraints into account.

 I understand that any solution to kern/60074 needs to respect
 those constraints.

 But then, as the initial xHCI implementation author, what fix do you
 think is correct? I already posted a possible fix in PR/60074:
  https://mail-index.netbsd.org/netbsd-bugs/2026/03/12/msg092172.html

 Could you comment on that proposal, or explain what change you expect
 instead in the PR?

 Thanks,
 ---
 Izumi Tsutsui

Home	PR Database Search