Re: Failure prints during format or mounting a usb storage device

From: Gerd Hoffmann <kraxel@redhat.com>
To: Paul Zimmerman <pauldzim@gmail.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: Wed, 8 Jul 2020 09:29:47 +0200	[thread overview]
Message-ID: <20200708072947.7hynrm53622tp3ha@sirius.home.kraxel.org> (raw)
In-Reply-To: <CADBGO79KSm3KV7=otOg=u7WjwBV=j3T7iU0fcTF-nGgtZvy+Aw@mail.gmail.com>

  Hi,

> > 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 don't think so.  dev-storage should not need to look at short-not-ok.

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

Sounds like that'll be another workaround.  dev-storage should not need
to know what kind of host adapter is used ...

A usb-storage transfer looks like this:

  (1) out transfer with the command (USB_MSDM_CBW)
  (2) data transfer, might be:
      - out (USB_MSDM_DATAOUT) for writes, or
      - in (USB_MSDM_DATAIN) for reads, or
      - nothing.
      depending on the scsi command.
  (3) in transfer with the status (USB_MSDM_CSW).

(1) and (3) usually fit into a single usb packet.
(2) can be multiple usb packets.

The critical case seem to be reads, i.e. we have in transfers for
both (2) and (3), and the transition from USB_MSDM_DATAIN state to
USB_MSDM_CSW state.

What is the sequence of usb packets submitted by the guest to hcd-dwc2
for reads?  Where exactly does it expect a short transfer?

take care,
  Gerd