Support HGST SSD400M SAS drives#233
Open
pruiz wants to merge 2 commits intoDrive-Trust-Alliance:masterfrom
Open
Support HGST SSD400M SAS drives#233pruiz wants to merge 2 commits intoDrive-Trust-Alliance:masterfrom
pruiz wants to merge 2 commits intoDrive-Trust-Alliance:masterfrom
Conversation
This is a oneliner fix ensuring SAT-2 passthru drive identification logic attempts, when failing, are retried as SCSI inquiry commands, in order to correctly detect enterprise SAS drives.
…h report an invalid length field at discovery0 header field.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi,
While working with the aforementioned SAS/SSD drives I've found the length field reported by the drive to a discovery0 request to be incorrect. Instead of reporting the full length of the discovery0 header + feature pages. It only reports the space occupied by feature pages (assuming the discovery0 header size is fixed and can be accounted on it's own, I guess).
By reading the spec (see: https://trustedcomputinggroup.org/wp-content/uploads/TCG_Storage_Architecture_Core_Spec_v2.01_r1.00.pdf), the length field is described as:
However, as stated, this drives (incorrectly?) return a length field not accounting for discovery0 header itself. So, this patch, overcomes such issue, by assuming a length field smaller than the discovery0 header size, should not be accounting for the header. So we keep parsing discovery0 response by as much as such length bytes of feature pages.