From: Hannes Reinecke <hare@suse.de>
To: Phil Pemberton <philpem@philpem.me.uk>,
linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Damien Le Moal <dlemoal@kernel.org>,
Niklas Cassel <cassel@kernel.org>,
"James E . J . Bottomley" <James.Bottomley@HansenPartnership.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH v5 3/6] ata: libata-scsi: route non-zero LUN commands for multi-LUN ATAPI
Date: Wed, 13 May 2026 15:11:05 +0200 [thread overview]
Message-ID: <b79bb2d1-2968-45cf-8db2-976fb499743b@suse.de> (raw)
In-Reply-To: <20260512202728.299414-4-philpem@philpem.me.uk>
On 5/12/26 22:27, Phil Pemberton wrote:
> Two changes are required to route commands to ATAPI LUNs other than 0:
>
> 1. __ata_scsi_find_dev(): The existing code rejects any scsi_device
> with a non-zero LUN, returning NULL and dropping the command on
> the floor. Hoist a non-zero LUN early-exit ahead of the original
> channel/id checks: when scsidev->lun is non-zero, allow it through
> only if the underlying ata_device is ATAPI class. The original
> LUN-0 path is left structurally unchanged.
>
> 2. atapi_xlat(): Older ATAPI devices (SCSI-2 era) expect the LUN in
> CDB byte 1 bits 7:5 rather than relying on transport-level LUN
> addressing. Encode scmd->device->lun into those bits, preserving
> the existing command-specific bits in 4:0. This is required by
> both the Panasonic PD/CD combos and Nakamichi CD changers.
>
> The SCSI layer caps the LUN at shost->max_lun, so a value beyond
> the device's nr_luns should never reach this point; guard with
> WARN_ON_ONCE() and return AC_ERR_INVALID if it does, since the
> 3-bit CDB field cannot represent it.
>
> Signed-off-by: Phil Pemberton <philpem@philpem.me.uk>
> ---
> drivers/ata/libata-scsi.c | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index 7c3d31dc49a1..2d714efc855f 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -2953,6 +2953,15 @@ static unsigned int atapi_xlat(struct ata_queued_cmd *qc)
> memset(qc->cdb, 0, dev->cdb_len);
> memcpy(qc->cdb, scmd->cmnd, scmd->cmd_len);
>
> + /*
> + * SCSI-2 CDB LUN encoding: bits 7:5 of byte 1 (3-bit field).
> + * The SCSI layer caps the LUN at shost->max_lun (<= ATAPI_MAX_LUN),
> + * so this should never trip; warn and reject if it does.
> + */
> + if (WARN_ON_ONCE(scmd->device->lun >= dev->nr_luns))
> + return AC_ERR_INVALID;
cf my comment to the previous patch.
I'd prefer to have 'scmd->device->host->max_lun' as the upper limit.
And we should check the that value does not exceed ATAPI_MAX_LUN.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
next prev parent reply other threads:[~2026-05-13 13:11 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 [this message]
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
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=b79bb2d1-2968-45cf-8db2-976fb499743b@suse.de \
--to=hare@suse.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=philpem@philpem.me.uk \
/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.