| Message ID | 20200723144530.9992-1-mathias.nyman@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | xhci features for usb-next | expand |
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 :) What is that going to help with? thanks, greg k-h
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
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
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
On Fri, Jul 24, 2020 at 02:11:44PM +0300, Mathias Nyman wrote: > > 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. Don't add frameworks for no users. Making this a char driver is not going to fly with me, I think I remember seeing old patches that tried to do this in the past that were submitted to some random Android kernel, and they just did not make any sense. It is easier to hide custom ioctls (i.e. custom syscalls) in a char driver than it is in a tty driver, so don't fall into that trap :) good luck! greg k-h
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. Thanks -Mathias Kai-Heng Feng (1): xhci: Make debug message consistent with bus and port number Mathias Nyman (26): xhci: dbc: Don't use generic xhci inc_deq() function for dbc xhci: Don't pass struct xhci_hcd pointer to xhci_link_seg() xhci: dbc: Don't use generic xhci erst allocation and free functions xhci: dbc: Remove dbc_dma_alloc_coherent() wrapper xhci: dbc: Remove dbc_dma_free_coherent() wrapper xhci: dbc: Add device pointer to dbc structure xhci: dbc: Use dev_info() and similar instead of xhci_info() xhci: dbc: Don't use xhci_write_64() as it takes xhci as a parameter xhci: dbc: Don't pass the xhci pointer as a parameter to xhci_dbc_init_context() xhci: dbc: Get the device pointer from dbc structure in dbc_ep_do_queue() xhci: dbc: Pass dbc pointer to endpoint init and exit functions. xhci: dbc: Change to pass dbc pointer to xhci_do_dbc_stop() xhci: dbc: Pass dbc pointer to dbc_handle_xfer_event() instead of xhci_hcd pointer xhci: dbgtty: Pass dbc pointer when registering a dbctty device xhci: dbc: Pass dbc pointer to get_in/out_ep() helper functions to get endpoints xhci: dbc: Use dbc structure in the request completion instead of xhci_hcd xhci: dbc: Don't use generic xhci context allocation for dbc xhci: dbc: don't use generic xhci ring allocation functions for dbc. xhci: dbc: Pass dbc pointer to dbc memory init and cleanup functions xhci: dbc: Pass dbc pointer to dbc start and stop functions. xhci: dbc: simplify dbc requests allocation and queueing xhci: dbc: remove endpoint pointers from dbc_port structure xhci: dbctty: split dbc tty driver registration and unregistration functions. xhci: dbc: Add a operations structure to access driver functions xhci: dbgcap: remove dbc dependency on dbctty specific flag xhci: dbc: remove tty specific port structure from struct xhci_dbc drivers/usb/host/xhci-dbgcap.c | 391 +++++++++++++++++++++------------ drivers/usb/host/xhci-dbgcap.h | 69 +++--- drivers/usb/host/xhci-dbgtty.c | 219 +++++++++++------- drivers/usb/host/xhci-hub.c | 41 ++-- drivers/usb/host/xhci-mem.c | 35 +-- drivers/usb/host/xhci.h | 2 + 6 files changed, 462 insertions(+), 295 deletions(-)