Cover Letter Detail
Show a cover letter.
GET /api/1.1/covers/2225151/?format=api
{ "id": 2225151, "url": "http://patchwork.ozlabs.org/api/1.1/covers/2225151/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-ide/cover/20260420122321.4161027-1-philpem@philpem.me.uk/", "project": { "id": 13, "url": "http://patchwork.ozlabs.org/api/1.1/projects/13/?format=api", "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 }, "msgid": "<20260420122321.4161027-1-philpem@philpem.me.uk>", "date": "2026-04-20T12:23:16", "name": "[v2,0/5] ata: libata-scsi: multi-LUN ATAPI device support", "submitter": { "id": 93108, "url": "http://patchwork.ozlabs.org/api/1.1/people/93108/?format=api", "name": "Phil Pemberton", "email": "philpem@philpem.me.uk" }, "mbox": "http://patchwork.ozlabs.org/project/linux-ide/cover/20260420122321.4161027-1-philpem@philpem.me.uk/mbox/", "series": [ { "id": 500602, "url": "http://patchwork.ozlabs.org/api/1.1/series/500602/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-ide/list/?series=500602", "date": "2026-04-20T12:23:21", "name": "ata: libata-scsi: multi-LUN ATAPI device support", "version": 2, "mbox": "http://patchwork.ozlabs.org/series/500602/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/covers/2225151/comments/", "headers": { "Return-Path": "\n <linux-ide+bounces-5498-incoming=patchwork.ozlabs.org@vger.kernel.org>", "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=EHrHthQS;\n\tdkim-atps=neutral", "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=104.64.211.4; helo=sin.lore.kernel.org;\n envelope-from=linux-ide+bounces-5498-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=\"EHrHthQS\"", "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 sin.lore.kernel.org (sin.lore.kernel.org [104.64.211.4])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fzlbD3h1mz1yCv\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 20 Apr 2026 22:46:00 +1000 (AEST)", "from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 46B2E3013705\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 20 Apr 2026 12:45:33 +0000 (UTC)", "from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 491113A0B1A;\n\tMon, 20 Apr 2026 12:45:27 +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 8E18139A818;\n\tMon, 20 Apr 2026 12:45:25 +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 23335BE5E5;\n\tMon, 20 Apr 2026 12:23: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 781065FC4E;\n\tMon, 20 Apr 2026 13:23:28 +0100 (BST)" ], "ARC-Seal": "i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776689127; cv=none;\n b=SluKIGWMqBJYC3sL8S4yhxzHMoRFEDTUwjPknG7ekIadipSXBt/m7FhiR+EimKXQ6c5PkK26KbpV+/5+B7lzJ2kgS3uDS+vHGZlpLZ4uJfD8bJyX/eAFsh3s/vz7Oeucf6iURoC7heUVhH5SIMuRlDYclrOj+gSlREqcChbQkCw=", "ARC-Message-Signature": "i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776689127; c=relaxed/simple;\n\tbh=Rf+ogoM9HozUI/TbYwyqCAZAG4IcaJIaj15+DrLChwA=;\n\th=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type;\n b=epX3eYeSK95XcMmOwfSb7VUe4sWpHlsOuM1p17Sll6NJlI5CsVifpA86v3VR7avEkZdYN97iBOH87iY9JKzyNYbgN4+IHeFZQFH7sYtOIQftJb1NRP6v6dpbgavcM+ej5nAto5vTAV3ghG5XMNu3oBQ4dXh58zuA0Sqw7n1iaQU=", "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=EHrHthQS; 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=1776687809;\n\tbh=Rf+ogoM9HozUI/TbYwyqCAZAG4IcaJIaj15+DrLChwA=;\n\th=From:To:Cc:Subject:Date:From;\n\tb=EHrHthQS/hJQzbVR19rth8svQB0xdcGqdO0i9XUU2jilVygE2WisoGW8fmQbtH+Jl\n\t 3TyEfVemq8trMroTbcOd5jVEKCHqglJNJrRK1MlX18KACzGgj6N65lFW7pinCLM1f+\n\t 4RN/Ca7tSazjujz9MCS8jhFsZno5CptgB2W5kyfw=", "From": "Phil Pemberton <philpem@philpem.me.uk>", "To": "Damien Le Moal <dlemoal@kernel.org>,\n\tNiklas Cassel <cassel@kernel.org>", "Cc": "\"James E . J . Bottomley\" <James.Bottomley@HansenPartnership.com>,\n\t\"Martin K . Petersen\" <martin.petersen@oracle.com>,\n\tHannes Reinecke <hare@suse.de>,\n\tlinux-ide@vger.kernel.org,\n\tlinux-scsi@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org,\n\tPhil Pemberton <philpem@philpem.me.uk>", "Subject": "[PATCH v2 0/5] ata: libata-scsi: multi-LUN ATAPI device support", "Date": "Mon, 20 Apr 2026 13:23:16 +0100", "Message-ID": "<20260420122321.4161027-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": "<linux-ide.vger.kernel.org>", "List-Subscribe": "<mailto:linux-ide+subscribe@vger.kernel.org>", "List-Unsubscribe": "<mailto:linux-ide+unsubscribe@vger.kernel.org>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=UTF-8", "Content-Transfer-Encoding": "8bit" }, "content": "Hi all,\n\nThis is v2, reworked based on review feedback from Damien Le Moal and\nHannes Reinecke.\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 v1:\n\n - dev->sdev is now a per-LUN array, as suggested by Hannes and Damien.\n v1 used a single-pointer LUN-0 guard with scsi_device_get()\n refcounting; Hannes pointed out that this left higher LUNs invisible\n to code that iterates sdevs, and Damien suggested an array indexed\n by LUN number. All call sites have been audited.\n\n - atapi_max_lun is now a libata module parameter, default 1, range\n 1..ATAPI_MAX_LUN (8, the SCSI-2 ceiling). Out-of-the-box the kernel\n behaves identically to today. A one-shot dmesg hint is printed when\n a BLIST_FORCELUN device is detected but atapi_max_lun is still 1,\n pointing the user at the knob.\n\n - Multi-LUN scanning uses a two-phase approach: __scsi_add_device()\n adds LUN 0 for every ATAPI device, then scsi_scan_target() with\n SCAN_WILD_CARD triggers the SCSI layer's sequential LUN scan only\n for devices flagged BLIST_FORCELUN. Single-LUN devices are\n completely unaffected. pdt_1f_for_no_lun is set on the target\n so that non-responding LUNs (PQ=0/PDT=0x1f) are silently skipped.\n\n - The scsi_devinfo COMPAQ PD-1 quirk now lands last in the series,\n as Damien requested.\n\nThe series is split as:\n\n 1/5: libata-scsi: add libata.atapi_max_lun module parameter.\n\n 2/5: libata-scsi: convert dev->sdev to a per-LUN array and update\n every caller.\n\n 3/5: 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\n 4/5: libata-scsi: after adding LUN 0, trigger scsi_scan_target() for\n BLIST_FORCELUN ATAPI devices only. Set pdt_1f_for_no_lun to\n suppress spurious \"No Device\" entries from non-responding LUNs.\n\n 5/5: scsi_devinfo: add the COMPAQ-branded variant of the PD-1 to the\n device info table. An entry already exists for the Panasonic\n OEM-branded \"MATSHITA PD-1\" and the NEC \"NEC PD-1 ODX654P\".\n\nTested on a Panasonic LF-1195C PD/CD (Compaq branded) attached to an\nata_piix host on i686. With libata.atapi_max_lun=7, both LUNs enumerate\ncorrectly: the CD-ROM as sr0 and the PD as sda. Non-responding LUNs are\nsilently skipped (no spurious \"No Device\" entries in dmesg). An iHAS124\nDVD writer on the same machine (single-LUN, no BLIST_FORCELUN entry) is\nunaffected: only LUN 0 is scanned.\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\nAll testing was done on kernel 7.0.0-rc7+.\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 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 (5):\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 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\n drivers/ata/libata-acpi.c | 4 +-\n drivers/ata/libata-core.c | 15 ++-\n drivers/ata/libata-scsi.c | 214 ++++++++++++++++++++++--------------\n drivers/ata/libata-zpodd.c | 6 +-\n drivers/ata/libata.h | 1 +\n drivers/scsi/scsi_devinfo.c | 1 +\n include/linux/libata.h | 3 +-\n 7 files changed, 152 insertions(+), 92 deletions(-)" }