All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Jim Lin <jilin@nvidia.com>,
	mathias.nyman@intel.com, gregkh@linuxfoundation.org
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [PATCH v3 1/1] usb: xhci: Add Clear_TT_Buffer
Date: Thu, 2 May 2019 13:56:39 +0300	[thread overview]
Message-ID: <f1688e22-05d9-ca43-5df2-2a5436631851@linux.intel.com> (raw)
In-Reply-To: <1556593592-3078-1-git-send-email-jilin@nvidia.com>

On 30.4.2019 6.06, Jim Lin wrote:
> USB 2.0 specification chapter 11.17.5 says "as part of endpoint halt
> processing for full-/low-speed endpoints connected via a TT, the host
> software must use the Clear_TT_Buffer request to the TT to ensure
> that the buffer is not in the busy state".

Good point, xhci isn't making sure TT buffers get cleared when they should.

> 
> In our case, a full-speed speaker (ConferenceCam) is behind a high-
> speed hub (ConferenceCam Connect), sometimes once we get STALL on a
> request we may continue to get STALL with the folllowing requests,
> like Set_Interface.
> 
> Here we add Clear_TT_Buffer for the following Set_Interface requests
> to get ACK successfully.
> 
> Signed-off-by: Jim Lin <jilin@nvidia.com>
> ---
> v2: xhci_clear_tt_buffer_complete: add static, shorter indentation
>      , remove its claiming in xhci.h
> v3: Add description for clearing_tt (xhci.h)
> 
>   drivers/usb/host/xhci-ring.c | 28 ++++++++++++++++++++++++++++
>   drivers/usb/host/xhci.c      |  7 +++++++
>   drivers/usb/host/xhci.h      |  2 ++
>   3 files changed, 37 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 9215a28dad40..02b1ebad81e7 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -1786,6 +1786,33 @@ struct xhci_segment *trb_in_td(struct xhci_hcd *xhci,
>   	return NULL;
>   }
>   
> +static void xhci_clear_hub_tt_buffer(struct xhci_hcd *xhci,
> +	unsigned int slot_id, struct xhci_td *td)
> +{
> +	struct xhci_virt_device *dev;
> +	struct xhci_slot_ctx *slot_ctx;
> +	int saved_devnum;
> +
> +	/*
> +	 * As part of low/full-speed endpoint-halt processing
> +	 * we must clear the TT buffer (USB 2.0 specification 11.17.5).
> +	 */
> +	if (td->urb->dev->tt && !usb_pipeint(td->urb->pipe) &&
> +	    (td->urb->dev->tt->hub != xhci_to_hcd(xhci)->self.root_hub) &&
> +	    !xhci->clearing_tt) {
> +		xhci->clearing_tt = 1;

one xhci->clearing_tt under is not enough, there might be several HS hubs, or
multi TT hubs with halted endpoints at the same time that need TT clearing.

How about a flag per endpoint?

For example Aadding a EP_CLEARING_TT flag for ep_state in struct xhci_virt_ep?
just like EP_STOP_CMD_PENDING, or EP_HALTED

> +		dev = xhci->devs[slot_id];
> +		slot_ctx = xhci_get_slot_ctx(xhci, dev->out_ctx);
> +		/* Update devnum temporarily for usb_hub_clear_tt_buffer */
> +		saved_devnum = td->urb->dev->devnum;
> +		td->urb->dev->devnum = (int) le32_to_cpu(slot_ctx->dev_state) &
> +			DEV_ADDR_MASK;

Changing the struct usb_device devnum on the fly seems like a bit of a hack, and probably
causes issues elsewhere. Devnum is tied to uevents, usbfs, sysfs etc.

We need another solution, some options:

- Let usb_hub_clear_tt_buffer() figure out address and not just use devnum if host == xhci.
- Add address to struct usb_device, (would have both address and devnum), use it when needed.
- Provide address as parameter to usb_clear_tt_buffer() (api change, changes other host drivers)
- Force devnum to be same as address, usb core can't choose address for xhci devices.

-Mathias

WARNING: multiple messages have this Message-ID (diff)
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Jim Lin <jilin@nvidia.com>,
	mathias.nyman@intel.com, gregkh@linuxfoundation.org
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Alan Stern <stern@rowland.harvard.edu>
Subject: [v3,1/1] usb: xhci: Add Clear_TT_Buffer
Date: Thu, 2 May 2019 13:56:39 +0300	[thread overview]
Message-ID: <f1688e22-05d9-ca43-5df2-2a5436631851@linux.intel.com> (raw)

On 30.4.2019 6.06, Jim Lin wrote:
> USB 2.0 specification chapter 11.17.5 says "as part of endpoint halt
> processing for full-/low-speed endpoints connected via a TT, the host
> software must use the Clear_TT_Buffer request to the TT to ensure
> that the buffer is not in the busy state".

Good point, xhci isn't making sure TT buffers get cleared when they should.

> 
> In our case, a full-speed speaker (ConferenceCam) is behind a high-
> speed hub (ConferenceCam Connect), sometimes once we get STALL on a
> request we may continue to get STALL with the folllowing requests,
> like Set_Interface.
> 
> Here we add Clear_TT_Buffer for the following Set_Interface requests
> to get ACK successfully.
> 
> Signed-off-by: Jim Lin <jilin@nvidia.com>
> ---
> v2: xhci_clear_tt_buffer_complete: add static, shorter indentation
>      , remove its claiming in xhci.h
> v3: Add description for clearing_tt (xhci.h)
> 
>   drivers/usb/host/xhci-ring.c | 28 ++++++++++++++++++++++++++++
>   drivers/usb/host/xhci.c      |  7 +++++++
>   drivers/usb/host/xhci.h      |  2 ++
>   3 files changed, 37 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 9215a28dad40..02b1ebad81e7 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -1786,6 +1786,33 @@ struct xhci_segment *trb_in_td(struct xhci_hcd *xhci,
>   	return NULL;
>   }
>   
> +static void xhci_clear_hub_tt_buffer(struct xhci_hcd *xhci,
> +	unsigned int slot_id, struct xhci_td *td)
> +{
> +	struct xhci_virt_device *dev;
> +	struct xhci_slot_ctx *slot_ctx;
> +	int saved_devnum;
> +
> +	/*
> +	 * As part of low/full-speed endpoint-halt processing
> +	 * we must clear the TT buffer (USB 2.0 specification 11.17.5).
> +	 */
> +	if (td->urb->dev->tt && !usb_pipeint(td->urb->pipe) &&
> +	    (td->urb->dev->tt->hub != xhci_to_hcd(xhci)->self.root_hub) &&
> +	    !xhci->clearing_tt) {
> +		xhci->clearing_tt = 1;

one xhci->clearing_tt under is not enough, there might be several HS hubs, or
multi TT hubs with halted endpoints at the same time that need TT clearing.

How about a flag per endpoint?

For example Aadding a EP_CLEARING_TT flag for ep_state in struct xhci_virt_ep?
just like EP_STOP_CMD_PENDING, or EP_HALTED

> +		dev = xhci->devs[slot_id];
> +		slot_ctx = xhci_get_slot_ctx(xhci, dev->out_ctx);
> +		/* Update devnum temporarily for usb_hub_clear_tt_buffer */
> +		saved_devnum = td->urb->dev->devnum;
> +		td->urb->dev->devnum = (int) le32_to_cpu(slot_ctx->dev_state) &
> +			DEV_ADDR_MASK;

Changing the struct usb_device devnum on the fly seems like a bit of a hack, and probably
causes issues elsewhere. Devnum is tied to uevents, usbfs, sysfs etc.

We need another solution, some options:

- Let usb_hub_clear_tt_buffer() figure out address and not just use devnum if host == xhci.
- Add address to struct usb_device, (would have both address and devnum), use it when needed.
- Provide address as parameter to usb_clear_tt_buffer() (api change, changes other host drivers)
- Force devnum to be same as address, usb core can't choose address for xhci devices.

-Mathias

  reply	other threads:[~2019-05-02 10:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-30  3:06 [PATCH v3 1/1] usb: xhci: Add Clear_TT_Buffer Jim Lin
2019-04-30  3:06 ` [v3,1/1] " Jim Lin
2019-05-02 10:56 ` Mathias Nyman [this message]
2019-05-02 10:56   ` Mathias Nyman
2019-05-02 12:32   ` [PATCH v3 1/1] " Jim Lin
2019-05-02 12:32     ` [v3,1/1] " Jim Lin

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=f1688e22-05d9-ca43-5df2-2a5436631851@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jilin@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=stern@rowland.harvard.edu \
    /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.