On Thu, Jul 23, 2020 at 09:47:14PM +0300, Mathias Nyman wrote: > 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. I thought when that was first merged no one cared :) Nice to see that fixed here. > 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. Odd, but ok. > > 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. What other interface is asked for? And yes, I would push back, what is wrong with TTY here? It should be the most "low overhead" interface that works with common userspace tools that we have. thanks, greg k-h
