On 23.7.2020 18.04, Greg KH wrote: > On Thu, Jul 23, 2020 at 05:45:03PM +0300, Mathias Nyman wrote: >> Hi Greg >> >> This series for usb-next is almost completely about decoupling and >> cleaning up relations between xhci, xhci debug capability (DbC), >> and the DbC tty support. >> >> Real motivation behind this is to later turn DbC into a proper device >> allowing us to bind different drivers to it, like dbctty. > > I don't really understand why you want to do that, but ok :) Well to be fair loading different drivers for DbC isn't the only motivation. Just using the Linux device model solves issues we are currently seeing when using DbC on systems with several xHCI controllers. The original DbC implementation didn't take this into account. And as a bigger picture DbC is just one extended capability. xHC controller provides a list of support extended capabilities, each one with an ID and often a mmio region (inside xhci mmio range). We don't handle these consistently in the xhci driver, for example the role switch capability is currently turned into a platform device while the DbC capability support is squashed all into the xhci driver. Long term idea here would be to create a extended capability bus where each capability is a device, (child of xhci device) and drivers for these match based on the capability ID. > > What is that going to help with? The option to load other drivers for the DbC capability will help other developers to write "standard" Linux drivers that provide different interfaces than TTY to send data over DbC. I don't fully understand these TTY limitations myself, but there is a strong push to implement this, and the task to provide the infrastructure for this landed on my table. Thanks -Mathias
