Show a cover letter.

GET /api/1.2/covers/2226043/?format=api
HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "id": 2226043,
    "url": "http://patchwork.ozlabs.org/api/1.2/covers/2226043/?format=api",
    "web_url": "http://patchwork.ozlabs.org/project/linux-pci/cover/1776825522-6390-1-git-send-email-shawn.lin@rock-chips.com/",
    "project": {
        "id": 28,
        "url": "http://patchwork.ozlabs.org/api/1.2/projects/28/?format=api",
        "name": "Linux PCI development",
        "link_name": "linux-pci",
        "list_id": "linux-pci.vger.kernel.org",
        "list_email": "linux-pci@vger.kernel.org",
        "web_url": null,
        "scm_url": null,
        "webscm_url": null,
        "list_archive_url": "",
        "list_archive_url_format": "",
        "commit_url_format": ""
    },
    "msgid": "<1776825522-6390-1-git-send-email-shawn.lin@rock-chips.com>",
    "list_archive_url": null,
    "date": "2026-04-22T02:38:39",
    "name": "[RESEND,v3,0/3] Add Devres managed IRQ vectors allocation",
    "submitter": {
        "id": 66993,
        "url": "http://patchwork.ozlabs.org/api/1.2/people/66993/?format=api",
        "name": "Shawn Lin",
        "email": "shawn.lin@rock-chips.com"
    },
    "mbox": "http://patchwork.ozlabs.org/project/linux-pci/cover/1776825522-6390-1-git-send-email-shawn.lin@rock-chips.com/mbox/",
    "series": [
        {
            "id": 500916,
            "url": "http://patchwork.ozlabs.org/api/1.2/series/500916/?format=api",
            "web_url": "http://patchwork.ozlabs.org/project/linux-pci/list/?series=500916",
            "date": "2026-04-22T02:38:41",
            "name": "Add Devres managed IRQ vectors allocation",
            "version": 3,
            "mbox": "http://patchwork.ozlabs.org/series/500916/mbox/"
        }
    ],
    "comments": "http://patchwork.ozlabs.org/api/covers/2226043/comments/",
    "headers": {
        "Return-Path": "\n <linux-pci+bounces-52911-incoming=patchwork.ozlabs.org@vger.kernel.org>",
        "X-Original-To": [
            "incoming@patchwork.ozlabs.org",
            "linux-pci@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=rock-chips.com header.i=@rock-chips.com\n header.a=rsa-sha256 header.s=default header.b=UhXt+dov;\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-pci+bounces-52911-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)",
            "smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=rock-chips.com header.i=@rock-chips.com\n header.b=\"UhXt+dov\"",
            "smtp.subspace.kernel.org;\n arc=none smtp.client-ip=220.197.32.71",
            "smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=rock-chips.com",
            "smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=rock-chips.com"
        ],
        "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)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g0kWf2lBGz1y2d\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 22 Apr 2026 13:01:18 +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 EF08530078E5\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 22 Apr 2026 02:54:39 +0000 (UTC)",
            "from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id DBA2339901C;\n\tWed, 22 Apr 2026 02:54:37 +0000 (UTC)",
            "from mail-m3271.qiye.163.com (mail-m3271.qiye.163.com\n [220.197.32.71])\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 A4773392825\n\tfor <linux-pci@vger.kernel.org>; Wed, 22 Apr 2026 02:54:27 +0000 (UTC)",
            "from localhost.localdomain (unknown [61.154.14.86])\n\tby smtp.qiye.163.com (Hmail) with ESMTP id 3ba417a8b;\n\tWed, 22 Apr 2026 10:38:54 +0800 (GMT+08:00)"
        ],
        "ARC-Seal": "i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776826475; cv=none;\n b=d/FdvWicoAHXm8DJE/nJNqhU83uU0juzWCk47VOdSj2X3eiMrNSbQPJ5kIfNOPnc8IPVqGbI7jOL501Ht2jepp64agjJSFisvFqYLxAmd+oezwl9GzHiBviKLP/ty9WwNOrJsSqC37mg4QMaLRa3z/WUJs8PwHRGInljkZE23Tw=",
        "ARC-Message-Signature": "i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776826475; c=relaxed/simple;\n\tbh=8IOkIu2e1/A67+NCy4H+cqEiZH27ZnRHfVIr1t7Se1U=;\n\th=From:To:Cc:Subject:Date:Message-Id;\n b=ut3dsklTCjvUTSHTOQ8rbOy6tqR2cCqDCMPAdZYjMM1khYNnQ13IrlLVb83dNgM1g4y6AlVMmTs/MmidRcQuBC3RDMHmzwtNoQlQUVAQK7GuL2Ff5vzijNgXrAQMo9Fh1FqfV5m02NJJgmTeHTQXPcamm+CA6lS7iDUEveVZMnY=",
        "ARC-Authentication-Results": "i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=rock-chips.com;\n spf=pass smtp.mailfrom=rock-chips.com;\n dkim=pass (1024-bit key) header.d=rock-chips.com header.i=@rock-chips.com\n header.b=UhXt+dov; arc=none smtp.client-ip=220.197.32.71",
        "From": "Shawn Lin <shawn.lin@rock-chips.com>",
        "To": "Bjorn Helgaas <bhelgaas@google.com>",
        "Cc": "Nirmal Patel <nirmal.patel@linux.intel.com>,\n\tJonathan Derrick <jonathan.derrick@linux.dev>,\n\tKurt Schwemmer <kurt.schwemmer@microsemi.com>,\n\tLogan Gunthorpe <logang@deltatee.com>,\n\tPhilipp Stanner <phasta@kernel.org>,\n\tlinux-pci@vger.kernel.org,\n\tShawn Lin <shawn.lin@rock-chips.com>",
        "Subject": "[RESEND PATCH v3 0/3] Add Devres managed IRQ vectors allocation",
        "Date": "Wed, 22 Apr 2026 10:38:39 +0800",
        "Message-Id": "<1776825522-6390-1-git-send-email-shawn.lin@rock-chips.com>",
        "X-Mailer": "git-send-email 2.7.4",
        "X-HM-Tid": "0a9db30e087509cckunm3ea616f516de41",
        "X-HM-MType": "1",
        "X-HM-Spam-Status": "e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly\n\ttZV1koWUFITzdXWS1ZQUlXWQ8JGhUIEh9ZQVkZTxlKVk9KGkoYTEJMTUhDGVYVFAkWGhdVEwETFh\n\toSFyQUDg9ZV1kYEgtZQVlNSlVKTk9VSk9VQ01ZV1kWGg8SFR0UWUFZT0tIVUpLSU9PT0hVSktLVU\n\tpCS0tZBg++",
        "DKIM-Signature": "a=rsa-sha256;\n\tb=UhXt+dovoFkzUOACiwp3FA952rEzEdfhlXegVd788OJEkfHU4Z8r+rnHLHnB6EiyUNPoLAFI1+o0D7scJWa6RNGbFCvv/3YsZdPvJ14c3Z8Xz+8aE5m0Pvl1Fq9wZ+lf4zXtChCP0tN12bgZOvIXs66WT4sH6Yqn5yhraI1Jjws=;\n c=relaxed/relaxed; s=default; d=rock-chips.com; v=1;\n\tbh=rlAvgz3k001W3UeH9eq6jRAGmorNmIBwVYc9jN9LXJA=;\n\th=date:mime-version:subject:message-id:from;",
        "Precedence": "bulk",
        "X-Mailing-List": "linux-pci@vger.kernel.org",
        "List-Id": "<linux-pci.vger.kernel.org>",
        "List-Subscribe": "<mailto:linux-pci+subscribe@vger.kernel.org>",
        "List-Unsubscribe": "<mailto:linux-pci+unsubscribe@vger.kernel.org>"
    },
    "content": "There is a long-standing design issue in the PCI/MSI subsystem where the\nimplicit, automatic management of IRQ vectors by the devres framework\nconflicts with explicit driver cleanup, creating ambiguity and potential\nresource management bugs.\n\nHistorically, pcim_enable_device() not only manages standard PCI resources\n(BARs) via devres but also implicitly triggers automatic IRQ vector management\nwhen calling pci_alloc_irq_vectors[_affinity], because pcim_enable_device()\nsets is_managed flag, thus pcim_msi_release() will register a cleanup action.\n\nThis creates an ambiguous ownership model. Many drivers follow a pattern of:\n1. Calling pci_alloc_irq_vectors() to allocate interrupts.\n2. Also calling pci_free_irq_vectors() in their error paths or remove routines.\n\nWhen such a driver also uses pcim_enable_device(), the devres framework may\nattempt to free the IRQ vectors a second time upon device release, leading to\na double-free. Analysis of the tree shows this hazardous pattern exists widely,\nwhile 35 other drivers correctly rely solely on the implicit cleanup.\n\nThis series introduces new managed APIs: pcim_alloc_irq_vectors()and\npcim_alloc_irq_vectors_affinity(). Drivers that wish to have devres-managed IRQ\nvectors should use these functions. They are currently the same as non-devres\nmanaged version. In the short term, the series converts two drivers within the\nPCI subsystem to use the new APIs. The long-term goal is to convert all other\ndrivers which wish to use these managed functions, and finally to remove the\nproblematic hybrid management pattern from pcim_enable_device() and\npcim_setup_msi_release() entirely.\n\n\nChanges in v3:\n- Rework the commit message and function doc (Philipp)\n- Remove setting is_msi_managed flag from new APIs (Philipp)\n\nChanges in v2:\n- Rebase\n- Introduce patches only for PCI subsystem to convert the API\n\nShawn Lin (3):\n  PCI/MSI: Add Devres managed IRQ vectors allocation\n  PCI: switchtec: Replace pci_alloc_irq_vectors() with\n    pcim_alloc_irq_vectors()\n  PCI: vmd: Replace pci_alloc_irq_vectors() with\n    pcim_alloc_irq_vectors()\n\n drivers/pci/controller/vmd.c   |  4 ++--\n drivers/pci/msi/api.c          | 47 ++++++++++++++++++++++++++++++++++++++++++\n drivers/pci/switch/switchtec.c |  6 +++---\n include/linux/pci.h            | 22 ++++++++++++++++++++\n 4 files changed, 74 insertions(+), 5 deletions(-)"
}