On 02/13/13 20:52, Jeremy Linton wrote:
On 2/13/2013 9:06 AM, Hannes Reinecke wrote:
So add a new flag 'support_64bit_luns' to the scsi host and modify report
lun scan to not check for max_luns during scanning if that flag is set.
This will get rid of the
Along these lines, I don't think the scsilun_to_int() and int_to_scsilun()
routines are correct for > 2^14 luns. SAM 4.6 defines bits 6,7 of byte zero
in the LU representation format as the address method. Which when set to 00b
limits it to 256 luns but the overflow into the bus ID probably works for some
devices.
Those routines should probably select/detect an alternative address method
for luns > 256.
Or am I missing something?
I think the LUN-to-int translation should depend on the LUN addressing
method supported by the target. SAM-5 defines the following LUN
addressing methods:
a) peripheral device addressing method;
b) flat space addressing method;
c) logical unit addressing method,
d) extended logical unit addressing method;
e) long extended logical unit addressing method.
scsilun_to_int() does the translation correctly for some of these
addressing methods but not for all of them.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
