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

[Phil Pemberton]

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