All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Zimmerman <pauldzim@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Sai Pavan Boddu <saipava@xilinx.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Vikram Garhwal <fnuv@xilinx.com>
Subject: Re: Failure prints during format or mounting a usb storage device
Date: Tue, 7 Jul 2020 13:23:09 -0700	[thread overview]
Message-ID: <CADBGO79KSm3KV7=otOg=u7WjwBV=j3T7iU0fcTF-nGgtZvy+Aw@mail.gmail.com> (raw)
In-Reply-To: <20200707075740.dkc76ceb7wytdoem@sirius.home.kraxel.org>

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

On Tue, Jul 7, 2020 at 12:57 AM Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
> >
> > Gerd, do you know the purpose of the 'short_not_ok' parameter to
> > usb_packet_setup()?
>
> Well, some usb host controllers have a flag in the transfer control
> blocks to indicate the host controller should stop processing requests
> in case of a short transfer.
>
> The usb core uses the flag to just to that (i.e. halt the endpoint on
> short transfers).  It is also checked when usb-host pipelines requests
> (requests queued after a short-not-ok packet can't be pipelined because
> we don't know yet whenever we should continue processing the endpoint or
> not).
>
> xhci has no such flag so the flag is never set.
>
> > The simple patch below fixes the reported problem,
> > but I don't know if it could cause some other problems for XHCI.
> > hcd-ehci, hcd-ohci, hcd-uhci all set the parameter conditionally,
> > but hcd-xhci never sets it. I don't understand the purpose of the
> > parameter myself.
> >
> > diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
> > index b330e36fe6..9fb96fdd66 100644
> > --- a/hw/usb/hcd-xhci.c
> > +++ b/hw/usb/hcd-xhci.c
> > @@ -1614,7 +1614,7 @@ static int xhci_setup_packet(XHCITransfer *xfer)
> >      xhci_xfer_create_sgl(xfer, dir == USB_TOKEN_IN); /* Also sets
> int_req */
> >      usb_packet_setup(&xfer->packet, dir, ep, xfer->streamid,
> > -                     xfer->trbs[0].addr, false, xfer->int_req);
> > +                     xfer->trbs[0].addr, dir == USB_TOKEN_IN,
> xfer->int_req);
>
> I suspect this might lead to queues being halted even though they should
> not.
>
> Why does 7ad3d51ebb8a522ffcad391c4bef281245739dde look at short-not-ok?
>

Because the patch changes dev-storage to terminate the transfer if a
short packet is received, so I figured 'short-not-ok' should affect
that behavior.

I guess instead I could add another flag that only hcd-dwc2 sets. Does
that sound OK to you?

Thanks,
Paul


> take care,
>   Gerd
>
>

[-- Attachment #2: Type: text/html, Size: 3529 bytes --]

  reply	other threads:[~2020-07-07 20:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-04 18:21 Failure prints during format or mounting a usb storage device Sai Pavan Boddu
2020-07-04 18:24 ` Paul Zimmerman
2020-07-06 22:21   ` Paul Zimmerman
2020-07-06 23:12     ` Paul Zimmerman
2020-07-07  7:57       ` Gerd Hoffmann
2020-07-07 20:23         ` Paul Zimmerman [this message]
2020-07-08  7:29           ` Gerd Hoffmann
2020-07-08  7:57             ` Paul Zimmerman
2020-07-08 10:29               ` Gerd Hoffmann
2020-07-09  6:02                 ` Paul Zimmerman
2020-07-09  7:57                   ` Gerd Hoffmann
2020-07-09 21:55                     ` Paul Zimmerman

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='CADBGO79KSm3KV7=otOg=u7WjwBV=j3T7iU0fcTF-nGgtZvy+Aw@mail.gmail.com' \
    --to=pauldzim@gmail.com \
    --cc=fnuv@xilinx.com \
    --cc=kraxel@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=saipava@xilinx.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.