11 Sep, 2017
1 commit
-
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:
Signed-off-by: Scott Bauer
Signed-off-by: Jens Axboe
18 Feb, 2017
1 commit
-
Insted of bloating the containing structure with it all the time this
allocates struct opal_dev dynamically. Additionally this allows moving
the definition of struct opal_dev into sed-opal.c. For this a new
private data field is added to it that is passed to the send/receive
callback. After that a lot of internals can be made private as well.Signed-off-by: Christoph Hellwig
Tested-by: Scott Bauer
Reviewed-by: Scott Bauer
Signed-off-by: Jens Axboe
07 Feb, 2017
1 commit
-
This patch implements the necessary logic to bring an Opal
enabled drive out of a factory-enabled into a working
Opal state.This patch set also enables logic to save a password to
be replayed during a resume from suspend.Signed-off-by: Scott Bauer
Signed-off-by: Rafael Antognolli
Reviewed-by: Christoph Hellwig
Signed-off-by: Jens Axboe