Help request: Blocking access to USB mass storage device across momentary power loss

[Rick Ramstetter]

I sent the following email to "Matthew Dharm" whose name appears in Linux
2.6.35's "scsiglue.c" as that file's primary maintainer. I realize in
retrospect I should have messaged the kernelnewbies and/or linux-usb lists
first.

To summarize the below text,
"what we're hoping to do ... is reset the SD cards ... via a drop of the
appropriate power rail ...  such that in progress userspace calls to read()
and write() are blocked until the hardware completes its power on
initialization sequence"

-------------------------------------------

From: J. Rick Ramstetter
Sent: Monday, January 06, 2014 11:53 AM
To: mdharm-usb at one-eyed-alien.net
Subject: Help request: Blocking access to USB mass storage device across
momentary power loss

Hello Matthew,

I'm emailing you because your name and email address were mentioned in the
source "scsiglue.c" of Linux kernel version 2.6.35. I'm about to ask for
help with aspects of that source file, and I'm hoping you'd be kind enough
to entertain my questions.

I work for a company that makes in flight entertainment (IFE) hardware for
various non-US airlines. These units are, at their core, flight certified
movie players with a secondary storage methodology of SD cards. Each unit
interfaces with its SD card storage via an SMSC 2660 or SMSC 2640 chip; in
other words, the individual SD cards appear to the IFE units as USB mass
storage devices using the most-common forms of USB mass storage
(drivers/usb/storage/scsiglue.c, Bulk-Only, Transparent SCSI).

We've recently root-caused a bug in our use of the SMSC 26x0 chips. The
cause is in hardware: in our board design, we failed to use CRD_PWR lines
provided by the SMSC chips to power the SD cards, but instead wired the SD
cards directly to the same 3.3v rail that powers the SMSC chips. We've been
advised by SMSC that this is improper, and our own empirical testing
suggests that the SMSC chips expect to be able to "power cycle" the SD
cards by cycling the CRD_PWR lines. Though we've fixed the problem for
future board revisions, we have thousands of affected IFE units in the
field and reworking them is impossible.

We have observed the following behaviors:
(1) The SMSC chip becomes, in USB terminology, "orphaned"
(2) The IFE units react by issuing a USB port reset (the usb mass storage
driver's "scsiglue.c" sets a port reset as the scsi host bus reset function
pointer)
(3) That reset causes the SMSC chip to reset, but the SD cards are not
reset due to improper wiring
(4) The SMSC chip and SD cards cannot communicate due to non-matched state.
Accesses fall through to scsi_lib's scsi_io_completion()'s "case NOT_READY
... action = ACTION_FAIL" logic.

What we're hoping to do, and forgive me if this seems extreme, is reset the
SD cards at step (3) above via a drop of the appropriate power rail. We
have software control of that rail, and there are few devices on it, all of
which are storage devices. We've demonstrated the feasibility of
"suspending" all of the platform (hardwired platform_device) storage
devices on that rail during a blackout, such that in progress userspace
calls to read() and write() are blocked until the hardware completes its
power on initialization sequence. We have not, however, demonstrated this
feasibility with our USB Mass Storage SD card devices, and thus I'm
emailing you.

With regard to "suspending" the SD card devices, we've tried  walking the
LDM device tree from childmost device to parentmost device, invoking the
appropriate power management suspend() operations as we go (including those
for usb's endpoint.c devices), but have had no luck during our resume
operation. Upon powerup of the SD cards and SMSC chip, USB re-enumerates
the devices, and re-invokes scsi_add_host() (ref usb_stor_probe2()). The
net result is a new scsi host, a new UEVENT, and a new udev device node.

Can you offer any advice on the goal of blocking userspace read() and
write() calls during the device's blackout?

I can see a few different approaches to this, including:
* A FUSE layer
* Pausing the Host in the SCSI layers
* Preventing the calls to scsi_add_host() et all in the USB layer

Some more specific questions:
* Is any documentation regarding the design and requirements of power
operations in the Linux SCSI code available on the internet?
* Besides host self-blocking (shost->host_self_blocked), does SCSI have any
facility for host "pausing" or temporary disconnection?
* Is this a problem for the SCSI layer at all, or does the USB / USB Mass
Storage layer need to handle it?

Thank you for your time,
--Rick R.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140106/888939a7/attachment.html