It is fine as-is, we can rename it later if needs be.

I tested this patch with two BUFFALO LUA2-TX (aue(4)) dongles that show the exact same dmesg.

@rkitover_gmail.com
Thank you for your effort.

I would like to understand the technical reasoning behind rejecting hidwacom before doing a rename. The rename itself is mechanical, but I want to understand what makes the name problematic so I can apply the same logic to future drivers.

In D56729#1300523, @guest-seuros wrote:

I think hidwacom is the better name here.

This is Wacom hardware, and it does not speak a generic "remote" protocol. It uses a Wacom-specific, undocumented HID report protocol. I decoded it from USB traffic captured against their Windows driver, and only later found that Linux already handles the same protocol in drivers/hid/wacom_wac.c under the hid-wacom driver.

If this were a published or vendor-neutral remote-control protocol, I would agree that hidremote would be a better name. But in this case, hidremote would make the driver look more generic than it really is.
The important part is not that the device is a remote, but that it is a Wacom HID device using Wacom-specific reports.

Linux also has support for multiple remotes and some additional quirks, but I cannot test those yet since I only have one ExpressKey Remote. I would rather land the tested base driver first and leave the untested multi-remote/quirk handling for future work.

Also, Wacom hardware is not limited to drawing tablets. Wacom EMR digitizers ship embedded in several laptops, including Lenovo ThinkPad X200t/X220t/X230t/Yoga models, and machines from HP, Dell, Asus, and Panasonic. Those are not drawing tablets either, but they still use Wacom-specific constants/protocol details. Samsung use it for their flagship phones and screens.

I will add the hidbus(4) xref.

Remove PHY checking, MII bus lock is sufficient

Hi, I have a patch for media in aue that should work, can you test please:

MII bus lock patch is here:

Add Differential Review to commit message

I've updated my patches to just use MII lock which is sufficient, as you found out, this one and:

Keep only MII bus lock, it's enough.

Keep only MII bus lock, it's enough.

Remove everything except MII bus lock, which is sufficient.

Also, thanks for you patient and contribution. This patch makes some improvement for multiple devices case.

Plus these point. Should we add O_CLOEXEC in here as libusb opened program can panic and thus flock never unlock

In D57293#1312969, @adrian wrote:

nice catch! Why's this not panicing though? I thought I saw a lock assertion in usb_command_wrapper() ?

nice catch! Why's this not panicing though? I thought I saw a lock assertion in usb_command_wrapper() ?

Refactor commit msg

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.

ugh yeah you're right, our mwait() implementation does the same thing and has the same issues, doesn't it? I've come to increasingly not like that; code really needs to treat exiting the mwait() as "all state may have changed", and it's not really suitable for serialising stuff like usb state / transfers.

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

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

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

Just split the patch with multiple smaller one.