防止 Linux 核心設置 USB 設備配置

我正在嘗試基於擷取的 USB 通信為現有的 USB 設備編寫 Linux 驅動程序。

該設備具有多種配置。不幸的是，該設備似乎不遵循 USB 規範：只有第一個設置配置請求有效。設備在發出第二個設置配置請求時鎖定並最終崩潰。USB 重置或重置配置（將其設置為 0）也無濟於事。

現在，無論出於何種原因，Linux USB Core 似乎都決定將設備的配置設置為錯誤的值（它只選擇第一個），而我沒有任何機會在它這樣做之前介入。我已經從核心模組和使用者空間 libusb 驅動程序中嘗試過它。

通過閱讀核心原始碼，似乎選擇配置的函式usb_choose_configuration()位於/drivers/usb/core/generic.c的通用驅動程序中。我可以看到如果返回 true，可以跳過該函式usb_device_is_owned()，但我不知道如何影響該函式的結果。

我希望我不必為了添加 USB 驅動程序而重新編譯整個核心。

因此，這是我的問題：

• 在將控制權交給我的驅動程序之前，如何防止系統設置配置？
• 似乎在最近的核心版本中，usbcore 是一個無法替換的內置模組。有沒有其他方法可以覆蓋usb_choose_configuration通用驅動程序中的函式（這似乎是 usbcore 的一部分）？
• 我怎樣才能讓設備擁有，以便usb_device_is_owned()在連接設備時已經返回 true？

似乎有一種方法可以防止系統嘗試設置設備的配置，它甚至可以在使用者空間工作。我偶然發現了將這個功能添加到核心的送出，幸運的是它還包含一些範常式式碼。

使用者空間程序可以通過設備文件系統聲明 USB 集線器特定埠的所有權，從而usb_device_is_owned()返回 true。

訣竅似乎是：

unsigned int port = 2; // Just as an example
// Send request 24 of type 'U' (USB), which returns an unsigned int
unsigned int ioctl_id = _IOR('U', 24, unsigned int);
// fd is a file descriptor to the hub's file in the devfs
ioctl(fd, ioctl_id, &port); 

有關 USB 子系統的一些 ioctl 請求的資訊在核心文件中進行了描述。完整列表可以在核心原始碼中找到。#defines 在這裡。

有趣的是，系統仍然為配置 0（重置配置）發送設置配置請求。

引用自：https://unix.stackexchange.com/questions/452824