{"id":2228535,"url":"http://patchwork.ozlabs.org/api/1.2/covers/2228535/?format=json","web_url":"http://patchwork.ozlabs.org/project/linux-ide/cover/20260426190920.2051289-1-philpem@philpem.me.uk/","project":{"id":13,"url":"http://patchwork.ozlabs.org/api/1.2/projects/13/?format=json","name":"Linux IDE development","link_name":"linux-ide","list_id":"linux-ide.vger.kernel.org","list_email":"linux-ide@vger.kernel.org","web_url":null,"scm_url":null,"webscm_url":null,"list_archive_url":"","list_archive_url_format":"","commit_url_format":""},"msgid":"<20260426190920.2051289-1-philpem@philpem.me.uk>","list_archive_url":null,"date":"2026-04-26T19:09:13","name":"[v3,0/7] ata: libata-scsi: multi-LUN ATAPI device support","submitter":{"id":93108,"url":"http://patchwork.ozlabs.org/api/1.2/people/93108/?format=json","name":"Phil Pemberton","email":"philpem@philpem.me.uk"},"mbox":"http://patchwork.ozlabs.org/project/linux-ide/cover/20260426190920.2051289-1-philpem@philpem.me.uk/mbox/","series":[{"id":501551,"url":"http://patchwork.ozlabs.org/api/1.2/series/501551/?format=json","web_url":"http://patchwork.ozlabs.org/project/linux-ide/list/?series=501551","date":"2026-04-26T19:09:18","name":"ata: libata-scsi: multi-LUN ATAPI device support","version":3,"mbox":"http://patchwork.ozlabs.org/series/501551/mbox/"}],"comments":"http://patchwork.ozlabs.org/api/covers/2228535/comments/","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-ide@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=philpem.me.uk header.i=@philpem.me.uk\n header.a=rsa-sha256 header.s=mail header.b=dQ6woGqF;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-ide+bounces-5536-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=philpem.me.uk header.i=@philpem.me.uk\n header.b=\"dQ6woGqF\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=178.62.38.78","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=philpem.me.uk","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=philpem.me.uk"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g3btf0wqTz1yHg\n\tfor ; Mon, 27 Apr 2026 05:12:42 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 4DEF03037D4F\n\tfor ; Sun, 26 Apr 2026 19:09:42 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id ED44537C93C;\n\tSun, 26 Apr 2026 19:09:38 +0000 (UTC)","from nick.sneptech.io (nick.sneptech.io [178.62.38.78])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E2D837C11A;\n\tSun, 26 Apr 2026 19:09:36 +0000 (UTC)","from wolf.philpem.me.uk (81-187-163-148.ip4.reverse-dns.uk\n [81.187.163.148])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\t(Authenticated sender: mailrelay_wolf@philpem.me.uk)\n\tby nick.sneptech.io (Postfix) with ESMTPSA id 54E09BE5D4;\n\tSun, 26 Apr 2026 19:09:29 +0000 (UTC)","from cheetah.homenet.philpem.me.uk (cheetah.homenet.philpem.me.uk\n [10.0.0.32])\n\tby wolf.philpem.me.uk (Postfix) with ESMTPSA id E0CF75FADA;\n\tSun, 26 Apr 2026 20:09:28 +0100 (BST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777230578; cv=none;\n b=FuQBhA+cTbwSL75AykvIG48dpYUE6Rrbj1nGYgFQAy0Ff5kn0bsBEhOU2L+agt3vJ5qMJWM8AWv1R/j6MGPGgsu5VRTHZ2Y90tlD5tRIfLjMJwue7wOOmlqQH7je6jwWR2mCk6XWXHLQSNehscv+B68k9RZ1GFSAxAElYyjdFSo=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777230578; c=relaxed/simple;\n\tbh=w7v77urmj9Myt8HPQQMb8jqREmEgbrUy31DNNSLEPgc=;\n\th=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type;\n b=RRaaTKMmK9cYAHlC5cEh3vI7/PHyhJEfC5wzx6sVUKfrxm9BSiXbstjKW/9jPxfeUXTAKxKSDZ+YOgCbpzm2SEs/wwqHyY/Ve2KZAof04b0tKspwC5Ih/uRm+ARKFr2YrXo15v5/LxjXfs+d3nlkKlvyDTB7auoqaxRAY6Qdsbk=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=philpem.me.uk;\n spf=pass smtp.mailfrom=philpem.me.uk;\n dkim=pass (1024-bit key) header.d=philpem.me.uk header.i=@philpem.me.uk\n header.b=dQ6woGqF; arc=none smtp.client-ip=178.62.38.78","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=philpem.me.uk;\n\ts=mail; t=1777230569;\n\tbh=w7v77urmj9Myt8HPQQMb8jqREmEgbrUy31DNNSLEPgc=;\n\th=From:To:Cc:Subject:Date:From;\n\tb=dQ6woGqFC+GYYiIrwkb+NTdimevxp4N1N/6EDf/CjMX+vSxlStWSC3uYJ+dncBTk/\n\t lNJUgwKYZ4gvUpxKmkcicZEVM6GzXUtA/BGhof94VJe/ppOxSIxM26m0d0CzqgtJ0j\n\t AEA2mjBEYd20taPeto9xGZ6b+wtX4cR53i2iW6+Y=","From":"Phil Pemberton ","To":"linux-ide@vger.kernel.org,\n\tlinux-scsi@vger.kernel.org","Cc":"linux-kernel@vger.kernel.org,\n\tDamien Le Moal ,\n\tNiklas Cassel ,\n\t\"James E . J . Bottomley\" ,\n\t\"Martin K . Petersen\" ,\n\tHannes Reinecke ,\n\tPhil Pemberton ","Subject":"[PATCH v3 0/7] ata: libata-scsi: multi-LUN ATAPI device support","Date":"Sun, 26 Apr 2026 20:09:13 +0100","Message-ID":"<20260426190920.2051289-1-philpem@philpem.me.uk>","X-Mailer":"git-send-email 2.43.0","Precedence":"bulk","X-Mailing-List":"linux-ide@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8bit"},"content":"Hi all,\n\nThis is v3, addressing review feedback from Hannes Reinecke on v2.\n\nThis series gives libata support for ATAPI devices with multiple LUNs,\nsuch as the Panasonic PD-1 PD/CD combo drive. This exposes both the\nCD-ROM and rewritable PD optical interfaces: CD-ROM as LUN 0 and PD\nas LUN 1.\n\nlibata has never supported multi-LUN ATAPI. This series adds support\nby fixing the following limitations:\n\n 1. shost->max_lun is hardcoded to 1 in ata_scsi_add_hosts(), preventing\n the SCSI layer from probing any LUN beyond 0.\n\n 2. __ata_scsi_find_dev() rejects all commands where scsidev->lun != 0,\n returning NULL and resulting in DID_BAD_TARGET.\n\n 3. The SCSI-2 CDB LUN field (byte 1, bits 7:5) is never populated.\n ATAPI tunnels SCSI commands over the ATA PACKET interface, and the\n transport-layer LUN addressing used by SPC-3+ is not available.\n Older multi-LUN ATAPI devices rely on this CDB field to route\n commands to the correct LUN.\n\n 4. ata_scsi_scan_host() only calls __scsi_add_device() for LUN 0,\n never probing additional LUNs even when the SCSI device info table\n would indicate the device supports them.\n\n 5. dev->sdev is a single pointer, but multi-LUN ATAPI puts multiple\n sdevs behind one ata_device. Every call to ata_scsi_dev_config()\n overwrote the pointer, and ata_scsi_sdev_destroy() tore down the\n entire ATA device whenever any sdev was destroyed -- so removing a\n spurious LUN result during scanning would kill the whole port, and\n the other users of dev->sdev (scsi_remove_device in\n ata_port_detach(), ACPI uevents, zpodd, media-change notify,\n suspend/resume rescan) could only ever see one LUN.\n\nChanges from v2:\n\n - pdt_1f_for_no_lun is no longer set unconditionally for every ATAPI\n target. Hannes suggested making this opt-in via the SCSI device\n info table, so a new BLIST_NO_LUN_1F flag has been added to\n scsi_devinfo.h, wired in scsi_scan.c, and applied to the COMPAQ\n PD-1 entry. Targets that legitimately use PDT 0x1f / PQ 0 for\n \"LUN not present\" can now opt in without affecting other ATAPI\n devices. This adds two new patches (4/7 and the updated 6/7).\n\n - Dropped the one-shot dmesg hint that pointed users at\n libata.atapi_max_lun when a BLIST_FORCELUN device was detected.\n Hannes felt the kernel should not be advertising its own knobs;\n the parameter is documented in the relevant patch and that's the\n expected place for users to discover it.\n\n - atapi_xlat() now rejects scmd->device->lun >= 8 with\n AC_ERR_INVALID instead of silently truncating. The SCSI-2 CDB\n LUN field is only 3 bits wide, so a request to a LUN outside that\n range is unrepresentable on the wire and must fail.\n\n - Patches 1/7 and 2/7 carry Hannes' Reviewed-by tags from v2.\n\n - Added an optional 7/7 that extends BLIST_NO_LUN_1F to the MATSHITA\n and NEC OEM-branded PD-1 variants. See note below.\n\nThe series is split as:\n\n 1/7: libata-scsi: add libata.atapi_max_lun module parameter.\n\n 2/7: libata-scsi: convert dev->sdev to a per-LUN array and update\n every caller.\n\n 3/7: libata-scsi: relax __ata_scsi_find_dev() to accept non-zero LUN\n for ATAPI devices, and encode the LUN in CDB byte 1 bits 7:5.\n Reject LUN >= 8 with AC_ERR_INVALID.\n\n 4/7: scsi: add a BLIST_NO_LUN_1F blacklist flag, which sets\n scsi_target.pdt_1f_for_no_lun for matching devices so that\n PDT 0x1f / PQ 0 INQUIRY responses are treated as \"LUN not\n present\" and silently skipped.\n\n 5/7: libata-scsi: after adding LUN 0, trigger scsi_scan_target() for\n BLIST_FORCELUN ATAPI devices only. Single-LUN devices are\n completely unaffected.\n\n 6/7: scsi_devinfo: add the COMPAQ-branded variant of the PD-1 to the\n device info table with BLIST_FORCELUN | BLIST_SINGLELUN |\n BLIST_NO_LUN_1F. An entry already exists for the Panasonic\n OEM-branded \"MATSHITA PD-1\" and the NEC \"NEC PD-1 ODX654P\".\n\n 7/7: scsi_devinfo: extend BLIST_NO_LUN_1F to the MATSHITA and NEC\n PD-1 variants for completeness. This patch is *optional* --\n it has not been tested on those OEM units (the author only has\n a COMPAQ unit), but the three variants are the same Panasonic\n LF-1095/LF-1195 mechanism with the same firmware family, so\n the quirk is expected to apply equally. The flag is a no-op\n on devices that do not return PDT 0x1f / PQ 0 for non-existent\n LUNs, so the worst case is that it has no effect. Drop or\n hold this patch if confirmation on real MATSHITA / NEC\n hardware is preferred first.\n\nTested on a Panasonic LF-1195C PD/CD (Compaq branded) attached to an\nata_piix host on i686, kernel 7.0.0-rc7+, with libata.atapi_max_lun=7.\nBoth LUNs enumerate correctly: the CD-ROM as sr0 and the PD as sda.\nReads from each device succeed against the appropriate media.\nNon-responding LUNs are silently skipped (no spurious \"No Device\"\nentries in dmesg). An iHAS124 DVD writer on the same machine\n(single-LUN, no BLIST_FORCELUN entry) is unaffected: only LUN 0 is\nscanned.\n\nIf the iHAS124 is scanned regardless, it seems to ignore the LUN\nparameter, and enumerates as eight drives. I expect most standard ATAPI\ndevices would behave this way, hence the BLIST_FORCELUN gate.\n\nTwo known limitations around media-change detection on multi-LUN\nATAPI devices with a shared physical media slot (e.g. PD/CD combos\nflagged BLIST_SINGLELUN):\n\n1. The block layer disables in-kernel polling by default\n (block.events_dfl_poll_msecs defaults to 0). Without polling,\n sd_check_events never runs and media insertion on the PD LUN is\n not detected automatically. sr_mod is unaffected because it\n re-reads the TOC on every open.\n\n Workaround -- either globally via kernel boot parameter:\n\n block.events_dfl_poll_msecs=2000\n\n or per-device via udev rule:\n\n ACTION==\"add\", KERNEL==\"sd*\", \\\n ATTRS{vendor}==\"COMPAQ \", ATTRS{model}==\"PD-1*\", \\\n ATTR{events_poll_msecs}=\"2000\"\n\n Even with polling enabled the sd path does not always pick up\n fresh media; `blockdev --rereadpt /dev/sdX` reliably forces a\n revalidate and proves the libata routing itself is correct.\n\n A follow-up patch could add a BLIST flag (e.g. BLIST_POLL_EVENTS)\n to scsi_devinfo and have sd_probe_async() set the per-disk poll\n interval when the flag is present. This would be a separate\n submission to the SCSI list since it touches sd.c.\n\n2. Media-change sense is not propagated across sibling LUNs. When\n one LUN reports UNIT ATTENTION (ASC 0x28 or 0x3A), the other LUNs\n are not notified. With polling enabled, sd_check_events detects\n the change independently on each LUN via TUR, so this is mainly a\n latency issue rather than a functional one. A follow-up to\n propagate media-change events to sibling LUNs in\n atapi_qc_complete is straightforward but deferred to keep this\n series focused on the LUN-scanning core.\n\nSuspend/resume with multi-LUN ATAPI attached has not yet been tested;\nthis is on the list. ata_scsi_dev_rescan iterates all populated LUN\nslots, and the SCSI layer's host-level suspend tracking already\nserialises port quiesce, so no additional per-LUN suspend counting is\nneeded in libata.\n\nComments and suggestions welcome.\n\nPhil Pemberton (7):\n ata: libata-scsi: add atapi_max_lun module parameter\n ata: libata-scsi: convert dev->sdev to per-LUN array\n ata: libata-scsi: route non-zero LUN commands for multi-LUN ATAPI\n scsi: add BLIST_NO_LUN_1F blacklist flag\n ata: libata-scsi: probe additional LUNs for multi-LUN ATAPI devices\n scsi: scsi_devinfo: add COMPAQ PD-1 multi-LUN ATAPI device quirk\n scsi: scsi_devinfo: extend BLIST_NO_LUN_1F to MATSHITA and NEC PD-1\n variants\n\n drivers/ata/libata-acpi.c | 4 +-\n drivers/ata/libata-core.c | 15 ++-\n drivers/ata/libata-scsi.c | 198 +++++++++++++++++++++---------------\n drivers/ata/libata-zpodd.c | 6 +-\n drivers/ata/libata.h | 1 +\n drivers/scsi/scsi_devinfo.c | 8 +-\n drivers/scsi/scsi_scan.c | 3 +\n include/linux/libata.h | 3 +-\n include/scsi/scsi_devinfo.h | 6 +-\n 9 files changed, 147 insertions(+), 97 deletions(-)"}