This first revision introduces detection only. The second corrects detection based on Sec. 7.6.9 of Intel xHCI v1.1 spec
Details
Details
- Reviewers
• hselasky darius-dons.net.au - Group Reviewers
USB
Primary development around NEC uPD720202, PCIe 1-lane and ExpressCard/34 adapters are available. Detection also returns positive results on AMD Hudson series FCH on ASUS A88XM-PLUS for DbC.
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 6753 Build 6968: arc lint + arc unit
Event Timeline
| sys/dev/usb/controller/xhci_dbc.c | ||
|---|---|---|
| 30–35 | If either <sys/types.h> or <sys/param.h> is needed, include it before other include files. (<sys/param.h> includes <sys/types.h>; do not include both.) The remaining kernel headers should be sorted alphabetically. | |
| 75–78 | Just a single space between type and name; don't initialize (or especially call functions) in declarations. temp, eecp, noff could share a line. | |
| 80 | sc_dbc_off/noff are an unsigned integers; s/-1/UINT32_MAX/ | |
| 97 | sc_dbc_off is an unsigned integer; s/-1/UINT32_MAX/ | |
| 103 | UINT32_MAX again | |
| sys/dev/usb/controller/xhci_pci.c | ||
| 104–105 | This could probably go in independent of the debug patch. | |
| 325–327 | Any err here is discarded by the halt_controller() call. | |
Comment Actions
Catch up with Sec. 7.6.9 of xHCI v1.1: DbC context sizes (DbC Info and Endpoint) are always 64 bytes, regardless of whether or not the host controller uses 32 byte contexts for ordinary endpoints (HCCPARAMS1).
This allows DbC capability to be detected on both of the AMD A88X Hudson FCH's USB 3.0 root hubs (which use discrete xhci HCD functions; 2 root hubs, 2 ports each).
Style changes from hselasky@.
Comment Actions
I actually find spelling out the bits in hex is more useful here - it's a driver and it's accessing a register, so although UINT32_MAX might well represent the value (and be equivalent to it), stylistically spelling out those bits makes it crystal clear that we're acting on a register.
However, I defer to Hans' shorthand of -1U here; I'd rather be consistent with sys/dev/usb on style.
| sys/dev/usb/controller/xhci_dbc.c | ||
|---|---|---|
| 103 | I actually find spelling out the bits in hex is more useful here - it's a driver and it's accessing a register, so although UINT32_MAX might well represent the value (and be equivalent to it), stylistically spelling out those bits makes it crystal clear that we're acting on a register. However, I defer to Hans' shorthand of -1U here; I'd rather be consistent with sys/dev/usb on style. | |
Comment Actions
It's probably also worth pointing out that because a lot of things in USB are generally named in Hungarian notation, some concessions already get made to that in/around dev/usb/*.
| sys/dev/usb/controller/xhci_dbc.h | ||
|---|---|---|
| 82 | It is probably not clever to pack structures which are used by DMA. Try to use __aligned() instead. Because on ARM platforms everything packet will be accessed byte-by-byte. | |