summaryrefslogtreecommitdiffstats
path: root/block/opal_proto.h
diff options
context:
space:
mode:
authorScott Bauer <scott.bauer@intel.com>2017-09-01 08:53:35 -0600
committerJens Axboe <axboe@kernel.dk>2017-09-11 09:45:52 -0600
commitdbec491b12b52888d120e5be8f15886b3216eb19 (patch)
treeae5c7424d03c6b60d229bd216f0666d12c366eed /block/opal_proto.h
parentf8e9ec16611baa8db77a7d46facd2ba7aa525955 (diff)
downloadlinux-stable-dbec491b12b52888d120e5be8f15886b3216eb19.tar.gz
linux-stable-dbec491b12b52888d120e5be8f15886b3216eb19.tar.bz2
linux-stable-dbec491b12b52888d120e5be8f15886b3216eb19.zip
block: sed-opal: Set MBRDone on S3 resume path if TPER is MBREnabled
Users who are booting off their Opal enabled drives are having issues when they have a shadow MBR set up after s3/resume cycle. When the Drive has a shadow MBR setup the MBRDone flag is set to false upon power loss (S3/S4/S5). When the MBRDone flag is false I/O to LBA 0 -> LBA_END_MBR are remapped to the shadow mbr of the drive. If the drive contains useful data in the 0 -> end_mbr range upon s3 resume the user can never get to that data as the drive will keep remapping it to the MBR. To fix this when we unlock on S3 resume, we need to tell the drive that we're done with the shadow mbr (even though we didnt use it) by setting true to MBRDone. This way the drive will stop the remapping and the user can access their data. Acked-by Jon Derrick: <jonathan.derrick@intel.com> Signed-off-by: Scott Bauer <scott.bauer@intel.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'block/opal_proto.h')
-rw-r--r--block/opal_proto.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/block/opal_proto.h b/block/opal_proto.h
index f40c9acf8895..e20be8258854 100644
--- a/block/opal_proto.h
+++ b/block/opal_proto.h
@@ -46,6 +46,7 @@ enum opal_response_token {
#define GENERIC_HOST_SESSION_NUM 0x41
#define TPER_SYNC_SUPPORTED 0x01
+#define MBR_ENABLED_MASK 0x10
#define TINY_ATOM_DATA_MASK 0x3F
#define TINY_ATOM_SIGNED 0x40