All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Mathias Nyman <mathias.nyman@intel.com>,
	linux-usb@vger.kernel.org, lukaszx.szulc@intel.com,
	Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	iommu@lists.linux-foundation.org
Subject: usb HC busted?
Date: Fri, 20 Jul 2018 10:09:25 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1807201006580.1512-100000@iolanthe.rowland.org> (raw)

On Fri, 20 Jul 2018, Mathias Nyman wrote:

> >> But we need to fix this properly as well.
> >> xhci needs to be more in sync with usb core in usb_set_interface(), currently xhci
> >> has the altssetting up and running when usb core hasn't event started flushing endpoints.
> > 
> > Absolutely.  The core tries to be compatible with host controller
> > drivers that either allocate bandwidth as it is requested or else
> > allocate bandwidth all at once when an altsetting is installed.
> > 
> > xhci-hcd falls into the second category.  However, this approach
> > requires the bandwidth verification for the new altsetting to be
> > performed before the old altsetting has been disabled, and the xHCI
> > hardware can't do this.
> > 
> > We may need to change the core so that the old endpoints are disabled
> > before the bandwidth check is done, instead of after.  Of course, this
> > leads to an awkward situation if the check fails -- we'd probably have
> > to go back and re-install the old altsetting.
> 
> That would help xhci a lot.
> 
> If we want to avoid the awkward altsetting re-install after bandwidth failure
> then adding a extra endpoint flush before checking the bandwidth would already help a lot.
> 
> The endpoint disabling can then be remain after bandwidth checking.
> Does that work for other host controllers?

As far as I know, the other host controller drivers don't really care 
how this is done.  xHCI is the only technology where the hardware has 
to verify the bandwidth requirements.  (Maybe some other SuperSpeed 
controller design also cares, but if so then this change is unlikely to 
hurt.)

Alan Stern
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
To: Mathias Nyman <mathias.nyman-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Mathias Nyman
	<mathias.nyman-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Greg KH
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	lukaszx.szulc-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	Andy Shevchenko
	<andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Andy Shevchenko
	<andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
	Sudip Mukherjee
	<sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: usb HC busted?
Date: Fri, 20 Jul 2018 10:09:25 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1807201006580.1512-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <f8cfa055-cfd8-db66-a386-72bf904e17cd-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

On Fri, 20 Jul 2018, Mathias Nyman wrote:

> >> But we need to fix this properly as well.
> >> xhci needs to be more in sync with usb core in usb_set_interface(), currently xhci
> >> has the altssetting up and running when usb core hasn't event started flushing endpoints.
> > 
> > Absolutely.  The core tries to be compatible with host controller
> > drivers that either allocate bandwidth as it is requested or else
> > allocate bandwidth all at once when an altsetting is installed.
> > 
> > xhci-hcd falls into the second category.  However, this approach
> > requires the bandwidth verification for the new altsetting to be
> > performed before the old altsetting has been disabled, and the xHCI
> > hardware can't do this.
> > 
> > We may need to change the core so that the old endpoints are disabled
> > before the bandwidth check is done, instead of after.  Of course, this
> > leads to an awkward situation if the check fails -- we'd probably have
> > to go back and re-install the old altsetting.
> 
> That would help xhci a lot.
> 
> If we want to avoid the awkward altsetting re-install after bandwidth failure
> then adding a extra endpoint flush before checking the bandwidth would already help a lot.
> 
> The endpoint disabling can then be remain after bandwidth checking.
> Does that work for other host controllers?

As far as I know, the other host controller drivers don't really care 
how this is done.  xHCI is the only technology where the hardware has 
to verify the bandwidth requirements.  (Maybe some other SuperSpeed 
controller design also cares, but if so then this change is unlikely to 
hurt.)

Alan Stern

             reply	other threads:[~2018-07-20 14:09 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-20 14:09 Alan Stern [this message]
2018-07-20 14:09 ` usb HC busted? Alan Stern
  -- strict thread matches above, loose matches on Subject: below --
2018-07-21 10:55 Sudip Mukherjee
2018-07-21 10:55 ` Sudip Mukherjee
2018-07-20 12:54 Sudip Mukherjee
2018-07-20 12:54 ` Sudip Mukherjee
2018-07-20 11:46 Mathias Nyman
2018-07-20 11:46 ` Mathias Nyman
2018-07-20 11:10 Mathias Nyman
2018-07-20 11:10 ` Mathias Nyman
2018-07-19 17:32 Sudip Mukherjee
2018-07-19 17:32 ` Sudip Mukherjee
2018-07-19 15:42 Mathias Nyman
2018-07-19 15:42 ` Mathias Nyman
2018-07-19 14:57 Alan Stern
2018-07-19 14:57 ` Alan Stern
2018-07-19 11:34 Sudip Mukherjee
2018-07-19 11:34 ` Sudip Mukherjee
2018-07-19 10:59 Mathias Nyman
2018-07-19 10:59 ` Mathias Nyman
2018-07-17 17:01 Sudip Mukherjee
2018-07-17 17:01 ` Sudip Mukherjee
2018-07-17 15:59 Sudip Mukherjee
2018-07-17 15:59 ` Sudip Mukherjee
2018-07-17 15:52 Greg Kroah-Hartman
2018-07-17 15:52 ` Greg KH
2018-07-17 15:10 Sudip Mukherjee
2018-07-17 15:10 ` Sudip Mukherjee
2018-07-17 15:08 Alan Stern
2018-07-17 15:08 ` Alan Stern
2018-07-17 14:49 Sudip Mukherjee
2018-07-17 14:49 ` Sudip Mukherjee
2018-07-17 14:40 Sudip Mukherjee
2018-07-17 14:40 ` Sudip Mukherjee
2018-07-17 14:31 Alan Stern
2018-07-17 14:31 ` Alan Stern
2018-07-17 14:28 Alan Stern
2018-07-17 14:28 ` Alan Stern
2018-07-17 13:53 Greg Kroah-Hartman
2018-07-17 13:53 ` Greg KH
2018-07-17 13:20 Sudip Mukherjee
2018-07-17 13:20 ` Sudip Mukherjee
2018-07-17 12:04 Greg Kroah-Hartman
2018-07-17 12:04 ` Greg KH
2018-07-17 11:41 Sudip Mukherjee
2018-07-17 11:41 ` Sudip Mukherjee
2018-06-30 21:07 Sudip Mukherjee
2018-06-30 21:07 ` Sudip Mukherjee
2018-06-29 11:41 Mathias Nyman
2018-06-29 11:41 ` Mathias Nyman
2018-06-27 12:20 Sudip Mukherjee
2018-06-27 12:20 ` Sudip Mukherjee
2018-06-27 11:59 Sudip Mukherjee
2018-06-27 11:59 ` Sudip Mukherjee
2018-06-25 16:15 Sudip Mukherjee
2018-06-25 16:15 ` Sudip Mukherjee
2018-06-21 11:01 Mathias Nyman
2018-06-21 11:01 ` Mathias Nyman
2018-06-21  0:53 Sudip Mukherjee
2018-06-21  0:53 ` Sudip Mukherjee
2018-06-08  9:07 Sudip Mukherjee
2018-06-08  9:07 ` Sudip Mukherjee
2018-06-07  7:40 Mathias Nyman
2018-06-07  7:40 ` Mathias Nyman
2018-06-06 16:45 Sudip Mukherjee
2018-06-06 16:45 ` Sudip Mukherjee
2018-06-06 16:42 Sudip Mukherjee
2018-06-06 16:42 ` Sudip Mukherjee
2018-06-06 15:36 Andy Shevchenko
2018-06-06 15:36 ` Andy Shevchenko
2018-06-06 14:12 Mathias Nyman
2018-06-06 14:12 ` Mathias Nyman
2018-06-04 15:28 Sudip Mukherjee
2018-06-03 19:37 Sudip Mukherjee
2018-05-24 13:35 Mathias Nyman

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=Pine.LNX.4.44L0.1807201006580.1512-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lukaszx.szulc@intel.com \
    --cc=m.szyprowski@samsung.com \
    --cc=mathias.nyman@intel.com \
    --cc=mathias.nyman@linux.intel.com \
    --cc=sudipm.mukherjee@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.