Hello, Daniel Drake wrote: > Am I right in saying, to fix 2.6.21, the following patches are needed, > and no others, in this order: > > sd: fix return value of sd_sync_cache() > 3721050afc6cb6ddf6de0f782e2054ebcc225e9b > (not sure if this one is required?) It's a bug fix but not necessary for manage_start_stop. > [SCSI] sd: implement START/STOP management > 3c94c5a2fb43a654e777f509d5032b0db8ed09f The commit is is missing the first 'c', so it's c3c94c5a2fb43a654e777f509d5032b0db8ed09f. > libata: reimplement suspend/resume support using sdev->manage_start_stop > 9666f4009c22f6520ac3fb8a19c9e32ab973e828 > > libata: implement libata.spindown_compat > 920a4b1038e442700a1cfac77ea7e20bd615a2c3 > > libata: fix shutdown warning message printing > da071b42f73dabbd0daf7ea4c3ff157d53b00648 > > libata: track spindown status and skip spindown_compat if possible > 13b8d09f5de0aaa3153bbccc98baf247387823dc Now there's one more patch. http://article.gmane.org/gmane.linux.ide/18934 > Additionally, no userspace modifications are needed, at least while > Gentoo's shutdown/halt programs are not attempting to spin down libata > disks? Yes. > I note that the patch titled "SCSI: kill sht->suspend/resume" (not > included in the above tree) is not yet merged into Linus' tree. Am I > right in saying it's not required for the disk spindown stuff to work > properly? Yes, your right. It's clean up of now unused feature and doesn't affect any functionality. One thing I'm worried about is reimplement-suspend-resume (9666f400). It hasn't received testing in -mm and got merged into -rc, so it would be a good idea to wait for a week or two and see whether any regression is caused by the change before applying it to distro kernel. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
