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"
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@xxxxxxxxxxxxxxxxxx
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 = "" 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.
Sent: Monday, January 06, 2014 11:53 AM
To: mdharm-usb@xxxxxxxxxxxxxxxxxx
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 = "" 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.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
