<div dir="ltr"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">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. </span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">To summarize the below text,</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">"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"</span><br>
<div><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">-------------------------------------------</span></div>
<div><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">From: J. Rick Ramstetter</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">Sent: Monday, January 06, 2014 11:53 AM</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">To: <a href="mailto:mdharm-usb@one-eyed-alien.net">mdharm-usb@one-eyed-alien.net</a></span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">Subject: Help request: Blocking access to USB mass storage device across momentary power loss</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">Hello Matthew,</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">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.</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">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).</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">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.</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">We have observed the following behaviors:</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">(1) The SMSC chip becomes, in USB terminology, "orphaned"</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">(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)</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">(3) That reset causes the SMSC chip to reset, but the SD cards are not reset due to improper wiring</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">(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.</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">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.</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">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.</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">Can you offer any advice on the goal of blocking userspace read() and write() calls during the device's blackout?</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">I can see a few different approaches to this, including:</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">* A FUSE layer</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">* Pausing the Host in the SCSI layers</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">* Preventing the calls to scsi_add_host() et all in the USB layer</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">Some more specific questions:</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">* Is any documentation regarding the design and requirements of power operations in the Linux SCSI code available on the internet?</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">* Besides host self-blocking (shost->host_self_blocked), does SCSI have any facility for host "pausing" or temporary disconnection?</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">* Is this a problem for the SCSI layer at all, or does the USB / USB Mass Storage layer need to handle it?</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">Thank you for your time,</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">
<span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px">--Rick R.</span><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.363636016845703px"><br></span></div></div>