From: Greg KH <gregkh@linuxfoundation.org>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH 00/27] xhci features for usb-next
Date: Fri, 24 Jul 2020 09:06:43 +0200 [thread overview]
Message-ID: <20200724070643.GH3880088@kroah.com> (raw)
In-Reply-To: <be21534d-df11-c957-43eb-e64a05a45404@linux.intel.com>
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
next prev parent reply other threads:[~2020-07-24 7:06 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 14:45 [PATCH 00/27] xhci features for usb-next Mathias Nyman
2020-07-23 14:45 ` [PATCH 01/27] xhci: Make debug message consistent with bus and port number Mathias Nyman
2020-07-23 14:45 ` [PATCH 02/27] xhci: dbc: Don't use generic xhci inc_deq() function for dbc Mathias Nyman
2020-07-23 14:45 ` [PATCH 03/27] xhci: Don't pass struct xhci_hcd pointer to xhci_link_seg() Mathias Nyman
2020-07-23 14:45 ` [PATCH 04/27] xhci: dbc: Don't use generic xhci erst allocation and free functions Mathias Nyman
2020-07-23 14:45 ` [PATCH 05/27] xhci: dbc: Remove dbc_dma_alloc_coherent() wrapper Mathias Nyman
2020-07-23 14:45 ` [PATCH 06/27] xhci: dbc: Remove dbc_dma_free_coherent() wrapper Mathias Nyman
2020-07-23 14:45 ` [PATCH 07/27] xhci: dbc: Add device pointer to dbc structure Mathias Nyman
2020-07-23 14:45 ` [PATCH 08/27] xhci: dbc: Use dev_info() and similar instead of xhci_info() Mathias Nyman
2020-07-23 14:45 ` [PATCH 09/27] xhci: dbc: Don't use xhci_write_64() as it takes xhci as a parameter Mathias Nyman
2020-07-23 14:45 ` [PATCH 10/27] xhci: dbc: Don't pass the xhci pointer as a parameter to xhci_dbc_init_context() Mathias Nyman
2020-07-23 14:45 ` [PATCH 11/27] xhci: dbc: Get the device pointer from dbc structure in dbc_ep_do_queue() Mathias Nyman
2020-07-23 14:45 ` [PATCH 12/27] xhci: dbc: Pass dbc pointer to endpoint init and exit functions Mathias Nyman
2020-07-23 14:45 ` [PATCH 13/27] xhci: dbc: Change to pass dbc pointer to xhci_do_dbc_stop() Mathias Nyman
2020-07-23 14:45 ` [PATCH 14/27] xhci: dbc: Pass dbc pointer to dbc_handle_xfer_event() instead of xhci_hcd pointer Mathias Nyman
2020-07-23 14:45 ` [PATCH 15/27] xhci: dbgtty: Pass dbc pointer when registering a dbctty device Mathias Nyman
2020-07-23 14:45 ` [PATCH 16/27] xhci: dbc: Pass dbc pointer to get_in/out_ep() helper functions to get endpoints Mathias Nyman
2020-07-23 14:45 ` [PATCH 17/27] xhci: dbc: Use dbc structure in the request completion instead of xhci_hcd Mathias Nyman
2020-07-23 14:45 ` [PATCH 18/27] xhci: dbc: Don't use generic xhci context allocation for dbc Mathias Nyman
2020-07-23 14:45 ` [PATCH 19/27] xhci: dbc: don't use generic xhci ring allocation functions " Mathias Nyman
2020-07-23 14:45 ` [PATCH 20/27] xhci: dbc: Pass dbc pointer to dbc memory init and cleanup functions Mathias Nyman
2020-07-23 14:45 ` [PATCH 21/27] xhci: dbc: Pass dbc pointer to dbc start and stop functions Mathias Nyman
2020-07-23 14:45 ` [PATCH 22/27] xhci: dbc: simplify dbc requests allocation and queueing Mathias Nyman
2020-07-23 14:45 ` [PATCH 23/27] xhci: dbc: remove endpoint pointers from dbc_port structure Mathias Nyman
2020-07-23 14:45 ` [PATCH 24/27] xhci: dbctty: split dbc tty driver registration and unregistration functions Mathias Nyman
2020-07-23 14:45 ` [PATCH 25/27] xhci: dbc: Add a operations structure to access driver functions Mathias Nyman
2020-07-23 14:45 ` [PATCH 26/27] xhci: dbgcap: remove dbc dependency on dbctty specific flag Mathias Nyman
2020-07-23 14:45 ` [PATCH 27/27] xhci: dbc: remove tty specific port structure from struct xhci_dbc Mathias Nyman
2020-07-23 15:04 ` [PATCH 00/27] xhci features for usb-next Greg KH
2020-07-23 18:47 ` Mathias Nyman
2020-07-24 7:06 ` Greg KH [this message]
2020-07-24 11:11 ` Mathias Nyman
2020-07-24 16:32 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200724070643.GH3880088@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).