On Fri, 2012-09-14 at 13:20 +0800, Aaron Lu wrote: > On Thu, Sep 13, 2012 at 10:26:44AM +0100, James Bottomley wrote: > > On Thu, 2012-09-13 at 17:07 +0800, Aaron Lu wrote: > > > So I think this is basically 2 things, one is the runtime suspend of the > > > disk, another is when it is runtime suspended, how to remove its power. > > > I'm currently doing the latter one, which is simpler, so I want to do it > > > first :-) > > > > Well, I don't like the way the interaction of the patches is going. > > You're the one proposing powering down the device outside of the > > standards defined transitions, so you need to be responsible for the > > actions that necessitates, including synchronizing the cache. The specs > > OK, I'll update the code. > > > (SPC-4) say that cache management is explicitly unnecessary for the > > standard SCSI power states (Active, Idle, Standby and Stopped), so > > Just read the SPC-4 spec, in section 5.12.3, it has words like this: > > Logical units that contain cache memory shall write all cached data to > the medium for the logical unit(e.g., as a logical unit would do in > response to a SYNCHRONIZE CACHE command as described SBC-3) prior to > entering into any power condition that prevents accessing the > media(e.g., before a hard drive stops its spindle motor during a change > to the standby power condition). > > So this looks like cache needs to be synced before the device enter > standby/stopped power condition. Or do I miss somthing? Um, no it says the device shall do the sync on its own (as though it received a sync cache). That section says the device shall be responsible for cache management in the power states. > > someone at some point is going to read that and remove the unnecessary > > cache sync in the code. When that happens, you'll start getting data > > loss. > > Indeed, I'll make sure cache gets synced when we are to power off the > device. Thanks for the remind. Great, thanks. James -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
