On 24.7.2020 10.06, Greg KH wrote: > 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. Suggestions and other approaches are welcome. > >>> 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. I've been asking the same questions about the TTY limitations. Currently there's a driver providing a character device in development. The developers are aware that they need to clarify and justify the need for a new interface to get the driver upstream. My concerns and suggestions are noted. As I don't understand these TTY limitations I'll have to let people publishing the driver do this part. I expect that the driver will clarify things. Anyway, I rather support them and work on providing the infrastructure needed to write such a driver, and give them the opportunity to implement whatever is needed. Thanks Mathias
