* We were never calling the callback function when we got a UFI CCI(!).
* We were passing a bogus residual count on non-UFI CCIs.
* After a REQUEST SENSE, the UFI CCI may include the ASC/ASCQ from the sense
information -- don't consider this a failure.
In addition, remove a horrible hack that was causing us to drop sense
information on the floor and return empty INQUIRY responses, often in the case
where there is a UNIT ATTENTION pending during the INQUIRY. (Some drives send
the data and then fail, some don't.)
This eliminates the need for quirks for the Y-E DATA FlashBuster.
These changes work on:
umass0: SAMSUNG SFD-321U [FW 0C], rev 1.10/2.10, addr 2
umass0: using UFI over CBI with CCI
sd0 at atapibus1 drive 0: <SMSC, USB FDC, 2.10> disk removable
umass0: TEAC TEAC FD-05PUB, rev 1.10/0.00, addr 2
umass0: using UFI over CBI with CCI
sd0 at atapibus0 drive 0: <TEAC, FD-05PUB, 1026> disk removable
umass0: Y-E DATA FlashBuster-U, rev 1.00/3.04, addr 2
umass0: using UFI over CBI with CCI
sd0 at atapibus0 drive 0: <Y-E DATA, USB-FDU, 3.04> disk removable
My Imation USB FlashGO! adapter responds to a Get Max Lun request with a
stall. With uhci, this does the expected thing. With ohci, it was returning
a "data underrun" error because we weren't setting "buffer rounding" (i.e.
USBD_SHORT_XFER_OK), and the underrun was taking priority. This happened with
both the ohci in a Mac cube and the builtin ohci on the S3C2410.
So, set USBD_SHORT_XFER_OK on the Get Max Lun. Now I get a stall reported and
umass attaches correctly.
called twice. At least in NetBSD, the detach function is called when the
device is removed, even if the attach function has failed.
This is probably the cause of panics reported in kern/19326.
(umass_scsipi.c) more distinct.
It is now possible to add new command protocols with a minimum of change.
The umassbus.[ch] files have been renamed umass_scsipi.[ch] since this
reflects their purpose better.
