Retrieve the Caching mode page

CBI/BBB isn't supposed to be, nor is designed to support SAM-modern devices. So while REQUEST LUN /may/ work on some devices which implement it in their firmware, it is NOT a requirement for those devices as they are not required to adhere to any SAM version. Those transport protocols define a class-specific request to get the maximum LUN, and another to reset the target port (instead of I_T Reset or LU Reset). They also do not support SCSI Status completion of the command, nor Autosense. They also do not provide TMFs. They provide none of the SCSI transport protocol services in support of the Execute Command procedure call. The SCSI layer shouldn't be trying to guess their "SCSI version", and or treat them as real SCSI devices sending REPORT LUNs, etc. commands.

Newer, modern transport protocols over USB, are part of SAM, and it is devices who connect via those protocols that are being disadvantaged, due to the adoption (assumption) of CBI/BBB well into the SCSI layer.

To this effect, the transport protocol can tell upper layers if the device is true SCSI (new usb transports or other) or hybrid (usb-storage). In the former case, the device is a SCSI device, in the latter, only basic commands should be attempted.

This isn't to say that firmware for those devices wouldn't be buggy. Of course it will, and most will probably port their legacy FW over to the new SPTL, but the protocol requirements are there by design (i.e. there is no longer Get Max Lun class-specific request, the application client has to send REPORT LUNS, and FW has to answer it) and we have to accommodate that.

It is in this spirit that this patch doesn't change wire behavior, but simply parses data returned by a command already supported by older protocols.