Skip to content

Support HGST SSD400M SAS drives#233

Open
pruiz wants to merge 2 commits intoDrive-Trust-Alliance:masterfrom
pruiz:pruiz/fix-hgst-nonstandard-drives
Open

Support HGST SSD400M SAS drives#233
pruiz wants to merge 2 commits intoDrive-Trust-Alliance:masterfrom
pruiz:pruiz/fix-hgst-nonstandard-drives

Conversation

@pruiz
Copy link

@pruiz pruiz commented Jun 21, 2018

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:

3.3.6.2.1 Length of parameter data

Indicates the total number of bytes that are valid in the Level 0 Discovery header and all of the feature
descriptors returned, not including this field.

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.

root and others added 2 commits June 10, 2018 05:59
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant