Linux에서 USB 호스트 컨트롤러 공급업체를 "Linux Foundation"으로 나열하는 이유는 무엇입니까?

Linux에서 USB 호스트 컨트롤러 공급업체를 "Linux Foundation"으로 나열하는 이유는 무엇입니까?

PCI/PCIE 버스에 연결된 USB 호스트 컨트롤러가 있는 모든 PC에서 다음을 볼 수 있습니다.

$ cat /sys/bus/usb/devices/usb1/{idVendor,idProduct,manufacturer,product,serial}
1d6b
0002
Linux 4.14.157-amd64-x32 ehci_hcd
EHCI Host Controller
0000:00:1a.0

즉, EHCI 호스트 컨트롤러(이 경우 PCI 장치 위치 0000:00:1a.0)는 문자열 설명자 및 공급업체/제품 식별자의 가짜 세트로 표시됩니다. 공급업체 ID를 찾아 Linux Foundation에 해당하는지 확인하세요 1d6b. usb.ids( lsusb"Linux Foundation 2.0 루트 허브"로 나열되어 있습니다.) 그러나 참조된 PCI 장치는 serial실제 장치이며 다음과 같은 속성을 갖습니다.

$ cat /sys/bus/pci/devices/0000:00:1a.0/{vendor,device}
0x8086
0x8c2d

이러한 ID를 찾아보면 pci.idsIntel 8 시리즈/C220 시리즈 칩셋 시리즈 USB EHCI(설명과 동일)임을 알 수 있습니다 lspci. 실제 하드웨어 제조업체의 실제 하드웨어.

그렇다면 Linux는 왜 이 Intel 하드웨어를 나타내기 위해 이상한 ID 세트를 사용합니까? PCI와 USB 공급업체/제품 ID가 충돌하여 PCI 네임스페이스의 ID를 사용하여 USB 장치 트리를 부팅할 수 없다는 것을 알고 있습니다. 그런데 왜 문자열 설명자인가?

내 생각에는 "*HCI 호스트 컨트롤러"라는 이름의 전체 USB 엔터티가 가상의 엔터티이기 때문인 것 같습니다. 그러나 반면에 해당 버스에 새로 연결된 장치에는 할당되지 않는 주소(항상 = 1)가 있는 것 같습니다. 따라서 이 USB 엔터티는 실제일 수 있는 것으로 보입니다. 하지만 이 예약된 주소가 단지 회계의 한 형태일 수도 있습니다.

내 추측이 맞나요? USB 개체로서의 호스트 컨트롤러는 완전한 허구입니까? 회선에서 실제 주소 지정이 가능한 장치로 나타나지 않았습니까? 아니면 커널이 단순히 처리를 에뮬레이션하도록 하는 대신 실제로 표준 USB 요청을 보낼 수 있는 것이 있습니까?

답변1

Linux에는 호스트 컨트롤러 드라이버가 코드를 공유할 수 있도록 하는 추상화가 있습니다. 코멘트로drivers/usb/core/hcd.c설명하다:

 * USB Host Controller Driver framework
 *
 * Plugs into usbcore (usb_bus) and lets HCDs share code, minimizing
 * HCD-specific behaviors/bugs.
 *
 * This does error checks, tracks devices and urbs, and delegates to a
 * "hc_driver" only for code (and data) that really needs to know about
 * hardware differences.  That includes root hub registers, i/o queues,
 * and so on ... but as little else as possible.
 *
 * Shared code includes most of the "root hub" code (these are emulated,
 * though each HC's hardware works differently) and PCI glue, plus request
 * tracking overhead.  The HCD code should only block on spinlocks or on
 * hardware handshaking; blocking on software events (such as other kernel
 * threads releasing resources, or completing actions) is all generic.
 *
 * Happens the USB 2.0 spec says this would be invisible inside the "USBD",
 * and includes mostly a "HCDI" (HCD Interface) along with some APIs used
 * only by the hub driver ... and that neither should be seen or used by
 * usb client device drivers.
 *

register_root_hub()이 함수 위의 설명에 표시된 대로 USB 장치 주소 1은 의 루트 허브에 할당됩니다 .

 * register_root_hub - called by usb_add_hcd() to register a root hub
 * @hcd: host controller for this root hub
 *
 * This function registers the root hub with the USB subsystem.  It sets up
 * the device properly in the device tree and then calls usb_new_device()
 * to register the usb device.  It also assigns the root hub's USB address
 * (always 1).

이는 공급업체 ID의 경우 제품 ID 1, 2, 3이 각각 루트 허브 1.1, 2.0 및 3.0에 해당함 usb.ids을 보여주는 데이터베이스에 의해 확인됩니다 .1d6b

이 장치에 대한 Linux 장치 트리에는 위에서 설명한 USB HCD 프레임워크에 의해 추상화된 USB 호스트 컨트롤러(실제 장치)와 USB 루트 허브(또한 실제 장치)가 혼합되어 있습니다.

이제 xHCI를 사용하는 일부 최신 시스템에는 EHCI 컨트롤러도 있습니다.인텔사 통합요금매칭센터항상 붙어있습니다. 이들은 루트 허브가 아니며 주소가 1이 아닌 2입니다.인텔 매뉴얼, 5.19.1장:

The Hubs convert low and full-speed traffic into high-speed traffic.

관련 정보