Show a cover letter.

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

{
    "id": 2225992,
    "url": "http://patchwork.ozlabs.org/api/covers/2225992/?format=api",
    "web_url": "http://patchwork.ozlabs.org/project/linux-pci/cover/1776821127-234830-1-git-send-email-shawn.lin@rock-chips.com/",
    "project": {
        "id": 28,
        "url": "http://patchwork.ozlabs.org/api/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": "<1776821127-234830-1-git-send-email-shawn.lin@rock-chips.com>",
    "list_archive_url": null,
    "date": "2026-04-22T01:25:24",
    "name": "[v3,0/3] Add Devres managed IRQ vectors allocation",
    "submitter": {
        "id": 66993,
        "url": "http://patchwork.ozlabs.org/api/people/66993/?format=api",
        "name": "Shawn Lin",
        "email": "shawn.lin@rock-chips.com"
    },
    "mbox": "http://patchwork.ozlabs.org/project/linux-pci/cover/1776821127-234830-1-git-send-email-shawn.lin@rock-chips.com/mbox/",
    "series": [
        {
            "id": 500907,
            "url": "http://patchwork.ozlabs.org/api/series/500907/?format=api",
            "web_url": "http://patchwork.ozlabs.org/project/linux-pci/list/?series=500907",
            "date": "2026-04-22T01:25:24",
            "name": "Add Devres managed IRQ vectors allocation",
            "version": 3,
            "mbox": "http://patchwork.ozlabs.org/series/500907/mbox/"
        }
    ],
    "comments": "http://patchwork.ozlabs.org/api/covers/2225992/comments/",
    "headers": {
        "Return-Path": "\n <linux-pci+bounces-52890-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=X6G52eu+;\n\tdkim-atps=neutral",
            "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-52890-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=\"X6G52eu+\"",
            "smtp.subspace.kernel.org;\n arc=none smtp.client-ip=45.254.49.220",
            "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 [172.234.253.10])\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 4g0hPn4VNHz1yGs\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 22 Apr 2026 11:26:05 +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 8AD0D300F134\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 22 Apr 2026 01:26:00 +0000 (UTC)",
            "from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id A446C2D7386;\n\tWed, 22 Apr 2026 01:25:59 +0000 (UTC)",
            "from mail-m49220.qiye.163.com (mail-m49220.qiye.163.com\n [45.254.49.220])\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 944D4335BA\n\tfor <linux-pci@vger.kernel.org>; Wed, 22 Apr 2026 01:25:56 +0000 (UTC)",
            "from localhost.localdomain (unknown [61.154.14.86])\n\tby smtp.qiye.163.com (Hmail) with ESMTP id 3ba07bb26;\n\tWed, 22 Apr 2026 09:25:45 +0800 (GMT+08:00)"
        ],
        "ARC-Seal": "i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776821159; cv=none;\n b=fEeHJVrvz1zfQYzum9cYhebT0u5AK+U7zBLJmxrshoi1Yc++KCmi2W166EDI0WI1BUvVUlgyvGLoV1I5GqrFsukLS4TZ/GF1HQ5zfkHCQaZPdnYBDoNiqp+kK89zcOxeE+bSeh2mOUXyDC0Ud5tm8Zz7/hEGEcJjfSUT1iZmrho=",
        "ARC-Message-Signature": "i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776821159; c=relaxed/simple;\n\tbh=FapvHKhHuHGEUhwmMlxlgK5wFbzLcR/YVtjzNQfj/y0=;\n\th=From:To:Cc:Subject:Date:Message-Id;\n b=r5SWx8r7dwAtuhjaX2zOUL1Pvg1uCX5vzU+1FWH9G5niSSq78tapy4y946IbLtTcFmW9Q33EaMEX1AGrjcnlbUTys3fnd2ghNPaJCmx5rvyGKYRoEkCnXLLMI7ECZY/FOfg9uDM8n98kAEnBYw+e71M61zFj2LV1R2awvqhqlHA=",
        "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=X6G52eu+; arc=none smtp.client-ip=45.254.49.220",
        "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": "[PATCH v3 0/3] Add Devres managed IRQ vectors allocation",
        "Date": "Wed, 22 Apr 2026 09:25:24 +0800",
        "Message-Id": "<1776821127-234830-1-git-send-email-shawn.lin@rock-chips.com>",
        "X-Mailer": "git-send-email 2.7.4",
        "X-HM-Tid": "0a9db2cb0d0109cckunm4d4f8bca15dec9",
        "X-HM-MType": "1",
        "X-HM-Spam-Status": "e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly\n\ttZV1koWUFITzdXWS1ZQUlXWQ8JGhUIEh9ZQVlCSBoZVk1DHU5LGUsZHktPSVYVFAkWGhdVEwETFh\n\toSFyQUDg9ZV1kYEgtZQVlNSlVKTk9VSk9VQ01ZV1kWGg8SFR0UWUFZT0tIVUpLSU9PT0hVSktLVU\n\tpCS0tZBg++",
        "DKIM-Signature": "a=rsa-sha256;\n\tb=X6G52eu+bmZwEpHMN4wp3voEa+0qHL+/D8tcu9+vqszzDrM/7qwpIEfeMrPEXLSET6qqv7n07JIhXq71pm2/CHz538YiahhyLEUR5mVrNLT0dis3kXA4lEDSUTFPXkceciIVE9wZB6+dZqhKq+3RXSu9eBrdCRIntxrdfFjxPPc=;\n c=relaxed/relaxed; s=default; d=rock-chips.com; v=1;\n\tbh=1f90EMBDsB8nqVk5sZbeh+FS5qzfGZ/gu7kALfL7AvU=;\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          | 51 ++++++++++++++++++++++++++++++++++++++++++\n drivers/pci/switch/switchtec.c |  6 ++---\n include/linux/pci.h            | 22 ++++++++++++++++++\n 4 files changed, 78 insertions(+), 5 deletions(-)"
}