On Tue, 2006-12-12 at 14:24 -0800, Darrick J. Wong wrote: > I tried out the patch below, but with it applied, SCSI still issues > REPORT LUNS to the device. It seems that sdev->type = -1 and bflags = 0 Yes, the inquiry scanning is being called too early ... largely so BLIST_ROM can work, I suppose. > when scsi_get_device_flags is called because the type code is not set up > until scsi_add_lun, which is called later. In any case, the check > doesn't work for me because the SATAPI GoVault reports itself as a > Direct Access device, not a CD-ROM. Er, if it's really a CD-ROM, doesn't it need a blacklist entry with BLIST_ROM then? Regardless, MMC is the only standard that seems to be inconsistent in this regard. Anything claiming to conform to SBC will need to be explicitly blacklisted if it claims SCSI-3 or higher and doesn't support REPORT LUNS. Does the attached patch fare better? James diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 14e635a..92fb26b 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -752,8 +752,15 @@ static int scsi_add_lun(struct scsi_devi case TYPE_RBC: sdev->writeable = 1; break; - case TYPE_WORM: case TYPE_ROM: + /* MMC devices can return SCSI-3 compliance and yet + * still not support REPORT LUNS, so make them act as + * BLIST_NOREPORTLUN unless BLIST_REPORTLUN2 is + * specifically set */ + if ((*bflags & BLIST_REPORTLUN2) == 0) + *bflags |= BLIST_NOREPORTLUN; + /* fall through */ + case TYPE_WORM: sdev->writeable = 0; break; default: - 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
