When SCSI-2 they can support luns past 7 and sparse luns.

Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

support the report luns opcode
.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

This is from RHEL4. I do not have any info from our bugzilla. All
I could find was something like this thread
http://lkml.org/lkml/2005/1/7/346

Report lun for linux does not work. It may be our lun format code or
it may be the device. It is probably not worth it to add anything
special for this device, so the patch just adds BLIST_NOREPORTLUN.

Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

This is from RHEL4. This box can support
scsi2 and can also support BLIST_SPARSELUN | BLIST_LARGELUN.

Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

According to Anthony Cheung all HP XP arrays with "OPEN-" 
types support REPORT_LUN. So there is no reason why we
shouldn't use it.

Signed-off-by: Anthony Cheung <anthony.cheung@hp.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

after upgrading our SUN E250 from 2.4 to 2.6 I'm seeing following error
when the HP DDS4 DAT changer gets probed:

scsi: host 1 channel 0 id 5 lun16777216 has a LUN larger than allowed by
the host adapter

The device is connected to a symbios 875 host. I've talked to Willy
about the problem, and he asked me to try to blacklist the device
for reportlun. I did that with the patch below and it solved the
problem. It now gets properly detected:

 target1:0:5: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 16)
  Vendor: HP        Model: C5713A            Rev: H307
  Type:   Sequential-Access                  ANSI SCSI revision: 03
 target1:0:5: Beginning Domain Validation
 target1:0:5: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16)
 target1:0:5: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 16)
 target1:0:5: Domain Validation skipping write tests
 target1:0:5: Ending Domain Validation
  Vendor: HP        Model: C5713A            Rev: H307
  Type:   Medium Changer                     ANSI SCSI revision: 03

Signed-off-by: tsbogend@alpha.franken.de
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

Some versions of the IBM 2104-DU3 disk enclosure
have been observed to hang Inquiries to non zero
LUNs to the SES device. This device only has LUN 0,
so this patch adds it to the BLIST to prevent scsi
core from scanning beyond LUN 0.

Signed-off-by: Brian King <brking@us.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

Conflicts:

	include/scsi/scsi_devinfo.h

Same number for two BLIST flags:  BLIST_MAX_512 and BLIST_ATTACH_PQ3

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

Some devices report a peripheral qualifier of 3 for LUN 0; with the original
code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
Also, the device at LUN 0 (which is not connected according to the PQ) is not
registered with the OS.

Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
reference for an infamous example.

This is patch 3/3:
3. Implement the blacklist flag BLIST_ATTACH_PQ3 that makes the scsi
   scanning code register PQ3 devices and continues scanning; only sg
   will attach thanks to scsi_bus_match().

Signed-off-by: Kurt Garloff <garloff@suse.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>