USB device serial numbers may change between current device stack and the device_next stack

[henrikbrixandersen]

Describe the bug
USB device serial numbers may change between current device stack and the device_next stack for the same MCU.

To Reproduce
Steps to reproduce the behavior:

1. west build -b frdm_k64f/mk64f12 samples/subsys/usb/hid-mouse/
2. west flash
3. Note down the reported USB serial number (see below).
4. west build -p always -b frdm_k64f/mk64f12 samples/subsys/usb/hid-mouse/ -- -DCONF_FILE="usbd_next_prj.conf" -DEXTRA_DTC_OVERLAY_FILE="usbd_next.overlay"
5. west flash
6. Note down the reported USB serial number (see below)

Expected behavior
The USB serial number maintains its value across the two USB device stacks.

Impact
A firmware update including a switch from the device stack to the device_next stack can result in changed USB serial numbers for devices in the field, causing issues when the USB serial number is used to uniquely identify a USB device (e.g. multiple USB debug adapters, multiple USB serial ports, multiple USB network adapters, ... connected to the same USB host).

Logs and console output
Linux lsusb output when using the current device stack:

$ lsusb -d 2fe3:0007 -v|grep iSerial
  iSerial                 3 4E4548322008002D

Linux lsusb output when using the current device_next stack:

$ lsusb -d 2fe3:0007 -v|grep iSerial
  iSerial                 3 FFFFFFFF4E4548322008002D

Environment (please complete the following information):

• OS: Linux
• Toolchain: Zephyr SDK
• Commit SHA: 99e6280

Additional context
The current USB device stack allows limiting the length of the reported USB serial number via CONFIG_USB_DEVICE_SN. By default, the USB serial number string is limited to 16 characters (based on the length of the string "0123456789ABCDEF"). The new USB device_next stack does not allow for this, causing the full length of the HWID being used.

I am labeling this as a bug, as this is how it will likely be seen from anybody implementing a USB device based on Zephyr.

[jfischer-no]

As mentioned above it is what hwinfo returns on this platform, we will not limit what hwinfo provides to its users. There will be a new macro to add a custom serial number that is fully user controllable.

[henrikbrixandersen]

As mentioned above it is what hwinfo returns on this platform, we will not limit what hwinfo provides to its users. There will be a new macro to add a custom serial number that is fully user controllable.

The point is that the serial number changes between the two stacks even on the same board. This will definitely be a surprise for downstream users.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[jfischer-no]

There is actually no hard dependency on HWINFO. You can disable it for your application, #86452 has fixed it for USB samples and shell. But if you want to use it, the stack should use the full serial number provided by HWINFO, and should not be truncated due to legacy stack behavior.