diff options
| author | Scott Bauer <scott.bauer@intel.com> | 2017-09-01 08:53:35 -0600 |
|---|---|---|
| committer | Jens Axboe <axboe@kernel.dk> | 2017-09-11 09:45:52 -0600 |
| commit | dbec491b12b52888d120e5be8f15886b3216eb19 (patch) | |
| tree | ae5c7424d03c6b60d229bd216f0666d12c366eed /block/opal_proto.h | |
| parent | f8e9ec16611baa8db77a7d46facd2ba7aa525955 (diff) | |
| download | linux-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.h | 1 |
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 |