From: sashiko-bot@kernel.org
To: "Phil Pemberton" <philpem@philpem.me.uk>
Cc: cassel@kernel.org, linux-ide@vger.kernel.org, dlemoal@kernel.org
Subject: Re: [PATCH v5 4/6] scsi: add BLIST_NO_LUN_1F blacklist flag
Date: Thu, 14 May 2026 01:26:44 +0000 [thread overview]
Message-ID: <20260514012644.80F6FC19425@smtp.kernel.org> (raw)
In-Reply-To: <20260512202728.299414-5-philpem@philpem.me.uk>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The BLIST_NO_LUN_1F flag fails to suppress the spurious 'No Device' entry for an unpopulated LUN 0, violating the primary goal of the commit.
--
commit 3370505ee70b7e5a5de5aa8aad7a378c9144aa38
Author: Phil Pemberton <philpem@philpem.me.uk>
scsi: add BLIST_NO_LUN_1F blacklist flag
Some multi-LUN devices respond to INQUIRY on unpopulated LUNs with
PQ=0 / PDT=0x1f instead of the standard PQ=3. The SCSI scan layer
normally adds such devices, producing spurious No Device entries.
This commit adds a BLIST_NO_LUN_1F flag to scsi_devinfo. It sets the
target flag pdt_1f_for_no_lun during scsi_add_lun() to suppress these
spurious entries.
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index ef22a4228b855..bfbbf9be05d21 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -1069,6 +1069,8 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned char *inq_result,
> transport_configure_device(&sdev->sdev_gendev);
>
> sdev->sdev_bflags = *bflags;
> + if (sdev->sdev_bflags & BLIST_NO_LUN_1F)
> + sdev->sdev_target->pdt_1f_for_no_lun = 1;
Could this cause a regression by failing to suppress the spurious No Device
entry for an unpopulated LUN 0?
In scsi_probe_and_add_lun(), the check to skip unpopulated LUNs occurs
before scsi_add_lun() is called:
drivers/scsi/scsi_scan.c:scsi_probe_and_add_lun() {
...
if (((result[0] >> 5) == 1 || starget->pdt_1f_for_no_lun) &&
(result[0] & 0x1f) == 0x1f &&
!scsi_is_wlun(lun)) {
SCSI_LOG_SCAN_BUS(3, sdev_printk(KERN_INFO, sdev,
"scsi scan: peripheral device type"
" of 31, no device added\n"));
res = SCSI_SCAN_TARGET_PRESENT;
goto out_free_result;
}
res = scsi_add_lun(sdev, result, &bflags, shost->async_scan);
...
}
If LUN 0 is unpopulated, scsi_probe_and_add_lun() will evaluate this skip
condition while starget->pdt_1f_for_no_lun is still 0.
The skip condition will evaluate to false, and scsi_add_lun() will be
invoked. This erroneously adds LUN 0 as a spurious No Device entry.
Should starget->pdt_1f_for_no_lun be updated directly from the local bflags
inside scsi_probe_and_add_lun() before the skip condition is evaluated?
>
> if (scsi_device_is_pseudo_dev(sdev))
> return SCSI_SCAN_LUN_PRESENT;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512202728.299414-1-philpem@philpem.me.uk?part=4
next prev parent reply other threads:[~2026-05-14 1:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 20:27 [PATCH v5 0/6] ata: libata-scsi: multi-LUN ATAPI device support Phil Pemberton
2026-05-12 20:27 ` [PATCH v5 1/6] ata: libata-scsi: add atapi_max_lun module parameter Phil Pemberton
2026-05-14 0:12 ` sashiko-bot
2026-05-12 20:27 ` [PATCH v5 2/6] ata: libata-scsi: convert dev->sdev to per-LUN array Phil Pemberton
2026-05-13 13:07 ` Hannes Reinecke
2026-05-14 0:36 ` sashiko-bot
2026-05-12 20:27 ` [PATCH v5 3/6] ata: libata-scsi: route non-zero LUN commands for multi-LUN ATAPI Phil Pemberton
2026-05-13 13:11 ` Hannes Reinecke
2026-05-14 1:12 ` sashiko-bot
2026-05-12 20:27 ` [PATCH v5 4/6] scsi: add BLIST_NO_LUN_1F blacklist flag Phil Pemberton
2026-05-14 1:26 ` sashiko-bot [this message]
2026-05-12 20:27 ` [PATCH v5 5/6] ata: libata-scsi: probe additional LUNs for multi-LUN ATAPI devices Phil Pemberton
2026-05-13 13:12 ` Hannes Reinecke
2026-05-14 2:33 ` sashiko-bot
2026-05-12 20:27 ` [PATCH v5 6/6] scsi: scsi_devinfo: add COMPAQ PD-1 multi-LUN ATAPI device quirk Phil Pemberton
2026-05-14 2:48 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260514012644.80F6FC19425@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=philpem@philpem.me.uk \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.