On 21/12/2018 16:37, Mathias Nyman wrote: > On 21.12.2018 17:53, Tj wrote: >> On 11/12/2018 14:00, Mathias Nyman wrote: >>>> Any advice or experience as to what we might be missing? >>> >>> What does sudo lsusb -v on the host say about the target device? >>> What's the dbc status on the target? you did enable it right? >>> (on target, cat /sys/bus/pci/devices/0000:00:14.0/dbc) >> >> Is this documentation incomplete? >> >> https://www.kernel.org/doc/html/v4.14/driver-api/usb/usb3-debug-port.html >> > > > That's the documentation for a old 4.14 kernel. > > see this instead: > https://www.kernel.org/doc/html/v4.19/driver-api/usb/usb3-debug-port.html > Thanks; hadn't realised we'd been looking at the older docs but it doesn't help. That specifically shows that writing to the 'dbc' node is a userspace procedure on the target - we're dealing with kernel earlyprintk. We have a custom kernel with all built-ins for testing with: $ egrep 'DBC|XHCI' .config CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DBGCAP=y CONFIG_USB_XHCI_PCI=y CONFIG_EARLY_PRINTK_USB_XDBC=y and a command-line including "earlyprintk=xdbc" >From what you've said, and looking at our host dmesg reports, it looks like we're only getting confirmation that the host is detecting the debug cable and the target XHCI hardware *but not* the target OS's debug function (which might explain the unexpected idProduct) that should be enabled by CONFIG_EARLY_PRINTK_USB_XDBC. I've just reviewed the kernel config options and cannot see anything else that would appear to affect this. Thanks for helping out on this; we'd given up on making sense of it and not having a working example to compare against we're working blind.
