Subject: SDcard Framework Suspend & Resume [PSARC/2008/742 Self Review] To: PSARC-ext@Sun.Com Cc: Bcc: one-pager-list@sac.sfbay one-pager-log@sac.sfbay sac-bar@sac.sfbay The following automatic case addresses a need for a pair of new functions required to fix a suspend/resume bug in the SDcard framework. If anyone has any questions, or feels the case should be "promoted" to a fast track or (heaven forbid!) a full case, please don't hesitate to ask. Note that case seeks patch binding for SDcard, and that the affected interfaces are Consolidation Private. -- Garrett Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: SDcard Framework Suspend & Resume 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 01 December, 2008 4. Technical Description SDcard Framework Suspend & Resume Problem: The SDcard framework (PSARC 2007/659 and PSARC 2008/001) needs to handle DDI_SUSPEND and DDI_RESUME events within the framework, in order to ensure that background kernel threads (specifically the master slot processing thread) does not wind up getting dispatched while the the host adapter is suspended. (Note that kernel threads, unlike user threads, are suspended *after* devices, and resumed *before* devices.) Solution: We add two new functions for SDcard adapters to call: void sda_host_suspend(sda_host_t *); void sda_host_resume(sda_host_t *); The physical driver will call these functions before suspending, and after resuming (respectively) the underlying hardware. The SDA framework guarantees that none of the driver's entry points (at least the ones registered with the SDA framework) will be called in between sda_host_suspend() and the sda_host_resume() calls. As with the other SDA support routines, these are Consolidation Private. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open