On 02/18/2016 11:06 PM, Bart Van Assche wrote:
> On 02/15/2016 12:24 AM, Hannes Reinecke wrote:
>> --- a/include/scsi/scsi_proto.h
>> +++ b/include/scsi/scsi_proto.h
>> @@ -277,5 +277,17 @@ struct scsi_lun {
>>       __u8 scsi_lun[8];
>>   };
>>
>> +/* SPC asymmetric access states */
>> +#define SCSI_ACCESS_STATE_OPTIMAL     0x00
>> +#define SCSI_ACCESS_STATE_ACTIVE      0x01
>> +#define SCSI_ACCESS_STATE_STANDBY     0x02
>> +#define SCSI_ACCESS_STATE_UNAVAILABLE 0x03
>> +#define SCSI_ACCESS_STATE_LBA         0x04
>> +#define SCSI_ACCESS_STATE_OFFLINE     0x0e
>> +#define SCSI_ACCESS_STATE_TRANSITIONING 0x0f
>> +
>> +#define SCSI_ACCESS_STATE_MASK        0x0f
>> +#define SCSI_ACCESS_STATE_PREFERRED   0x80
>> +#define SCSI_ACCESS_STATE_UNKNOWN     0x70
> 
> Please mention in the comment above these constants that the ALUA
> state values apply to both the RTPG and STPG commands but that the
> PREFERRED bit only applies to the RTPG command.
> 
> All constants in scsi_proto.h come from a SCSI standard. However,
> this patch adds a constant that does not come from a SCSI standard
> (SCSI_ACCESS_STATE_UNKNOWN). Please remove this constant entirely
> because it causes confusion. sdev_show_access_state() only
> interprets the PREFERRED bit and the lower 4 bits of the
> access_state member variable. This means that the
> SCSI_ACCESS_STATE_UNKNOWN entry in sdev_access_states[] is never
> used and hence should be left out. This also means that the
> "sdev->access_state = SCSI_ACCESS_STATE_UNKNOWN" assignment in
> scsi_scan.c is equivalent to "sdev->access_state =
> SCSI_ACCESS_STATE_OPTIMAL".
> 
Correct. Will be fixing it up.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Teamlead Storage & Networking
h...@suse.de                                   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to