[RFC PATCH 0/3] ata: libata-scsi: add multi-LUN support for ATAPI devices

Phil Pemberton
2026-04-09T21:06:10Z

Hi all,

This series gives libata support for ATAPI devices with multiple LUNs,
such as the Panasonic PD-1 PD/CD combo drive. This exposes both the
CD-ROM and rewritable PD optical interfaces: CD-ROM as LUN 0 and PD
as LUN 1.

libata has never supported multi-LUN ATAPI. This series adds support
by fixing the following limitations:

1. shost->max_lun is hardcoded to 1 in ata_scsi_add_hosts(), preventing
the SCSI layer from probing any LUN beyond 0.

2. __ata_scsi_find_dev() rejects all commands where scsidev->lun != 0,
returning NULL and resulting in DID_BAD_TARGET.

3. The SCSI-2 CDB LUN field (byte 1, bits 7:5) is never populated.
ATAPI tunnels SCSI commands over the ATA PACKET interface, and the
transport-layer LUN addressing used by SPC-3+ is not available.
Older multi-LUN ATAPI devices rely on this CDB field to route
commands to the correct LUN.

4. ata_scsi_scan_host() only calls __scsi_add_device() for LUN 0,
never probing additional LUNs even when the SCSI device info table
would indicate the device supports them.

5. ata_scsi_dev_config() assigned dev->sdev for every LUN, and
ata_scsi_sdev_destroy() tore down the entire ATA device whenever
any sdev was destroyed -- so removing a spurious LUN result during
scanning would kill the whole port.

The series is split as:

1/3: scsi_devinfo: add the COMPAQ-branded variant of the PD-1 to the
device info table. An entry already exists for the Panasonic
OEM-branded "MATSHITA PD-1" and the NEC "NEC PD-1 ODX654P".

2/3: libata-scsi: raise max_lun, route non-zero LUNs to the same
ata_device for ATAPI, encode the LUN in CDB byte 1, and fix the
slave_configure/slave_destroy callbacks to track LUN 0 only.

3/3: libata-scsi: probe additional LUNs in ata_scsi_scan_host() for
ATAPI devices flagged BLIST_FORCELUN, stopping at PDT 0x1f.

Tested on a Panasonic LF-1195C PD/CD (Compaq branded) attached to an
ata_piix host on i686. The CD-ROM enumerates as an 'sr' device and
the PD side enumerates as an 'sd' block device. Both LUNs work for I/O:
the CD reads correctly, and the PD drive can be partitioned, formatted
and mounted. An iHAS124 DVD writer on the same machine (single-LUN, no
BLIST_FORCELUN entry) is unaffected: it does not enter the multi-LUN
probing path.

If the iHAS124 is scanned regardless, it seems to ignore the LUN
parameter, and enumerates as eight drives. I expect most standard ATAPI
devices would behave this way, hence the BLIST_FORCELUN gate.

The "PDT 0x1f" check is based on the behaviour of the Panasonic PD/CD
drive: when an unrecognised LUN is probed, it responds with SCSI
peripheral device type 0x1F (no device).

All testing was done on kernel 7.0.0-rc7+.

This is marked RFC because:

- The CDB-byte-1 LUN encoding is a SCSI-2-era convention that may
affect well-behaved modern devices in unexpected ways. It is
currently applied to all non-zero LUN commands on ATAPI devices;
a more conservative approach would gate it on a quirk flag.

- The blast radius of changing __ata_scsi_find_dev() and the slave
callbacks deserves wider review, even though all changes are
conditional on dev->class == ATA_DEV_ATAPI or sdev->lun == 0.

- I do not have other multi-LUN ATAPI hardware to test against.

Comments and suggestions welcome.

Phil Pemberton (3):
scsi: scsi_devinfo: add COMPAQ PD-1 multi-LUN ATAPI device quirk
ata: libata-scsi: enable multi-LUN support for ATAPI devices
ata: libata-scsi: probe additional LUNs for multi-LUN ATAPI devices

drivers/ata/libata-scsi.c | 67 ++++++++++++++++++++++++++++++++++---
drivers/scsi/scsi_devinfo.c | 1 +
2 files changed, 64 insertions(+), 4 deletions(-)

--
2.39.5