Conversation
There was a problem hiding this comment.
Pull request overview
Refactors USB hub/device initialization by deriving hub speed from the hub protocol and adjusting xHCI slot-context assignment logic (plus minor comment/format cleanup).
Changes:
- Set
HubInfo.speedduring hub configuration based on the hub’s descriptor protocol (FS/HS/SS). - Refactor xHCI device addressing to clarify Route String derivation and make TT-parent assignment conditional.
- Re-enable a delay in the “wait for port enabled” polling loop to avoid tight spinning.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| usb-host/src/backend/kmod/xhci/device.rs | Updates Route String comment and refactors TT parent-hub selection logic when addressing devices. |
| usb-host/src/backend/kmod/hub/device.rs | Assigns hub speed from hub protocol during configure; reintroduces a delay in port-enable polling loop. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| while let Some(p) = parent_id { | ||
| let parent_hub = info.infos.get(&p).unwrap(); | ||
| tt_port = parent_hub.port_id; | ||
| if parent_hub.hub_depth == -1 { | ||
| break; | ||
| } | ||
| if matches!(parent_hub.speed, Speed::High) { | ||
| hs_parent = Some(p); | ||
| break; |
There was a problem hiding this comment.
TT parent traversal overwrites tt_port with parent_hub.port_id before checking whether the current parent_hub is the HS hub. For a LS/FS device behind a HS hub (possibly through FS hubs), this makes parent_port_number end up as the HS hub’s upstream port number (port on its parent, e.g. root port) instead of the HS hub port that leads to the LS/FS device (or downstream FS hub). Consider keeping a separate child_port (initialized to info.port_id) and only updating it when moving up a non-HS hub; when parent_hub.speed is High, use the current child_port for set_parent_port_number.
1 participant
…omments