Prev: libata: use the enlarged capacity after late HPA unlock
Next: [PATCH] MFD: prevent null pointer dereference in mfd_add_device
From: Jeff Garzik on 15 May 2010 15:30 On 05/15/2010 02:09 PM, Tejun Heo wrote: > Implement ata_scsi_unlock_native_capacity() which will be called > through SCSI layer when block layer notices that partitions on a > device extend beyond the end of the device. It requests EH to unlock > HPA, waits for completion and returns the current device capacity. > > This allows libata to unlock HPA on demand instead of having to decide > whether to unlock upfront. Unlocking on demand is safer than > unlocking by upfront because some BIOSes write private data to the > area beyond HPA limit. This was suggested by Ben Hutchings. > > Signed-off-by: Tejun Heo<tj(a)kernel.org> > Suggested-by: Ben Hutchings<ben(a)decadent.org.uk> Acked-by: Jeff Garzik <jgarzik(a)redhat.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 16 May 2010 03:20
From: Tejun Heo <tj(a)kernel.org> Date: Sat, 15 May 2010 20:09:34 +0200 > Implement ata_scsi_unlock_native_capacity() which will be called > through SCSI layer when block layer notices that partitions on a > device extend beyond the end of the device. It requests EH to unlock > HPA, waits for completion and returns the current device capacity. > > This allows libata to unlock HPA on demand instead of having to decide > whether to unlock upfront. Unlocking on demand is safer than > unlocking by upfront because some BIOSes write private data to the > area beyond HPA limit. This was suggested by Ben Hutchings. > > Signed-off-by: Tejun Heo <tj(a)kernel.org> > Suggested-by: Ben Hutchings <ben(a)decadent.org.uk> Acked-by: David S. Miller <davem(a)davemloft.net> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |