[{"id":3678493,"web_url":"http://patchwork.ozlabs.org/comment/3678493/","msgid":"","list_archive_url":null,"date":"2026-04-17T06:10:17","subject":"Re: [PATCH v2 1/3] PCI/MSI: Add Devres managed IRQ vectors allocation","submitter":{"id":68011,"url":"http://patchwork.ozlabs.org/api/people/68011/","name":"Frank Li","email":"Frank.Li@nxp.com"},"content":"On Fri, Apr 17, 2026 at 10:26:05AM +0800, Shawn Lin wrote:\n> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for\n> pci device drivers which rely on the devres machinery to help cleanup the IRQ\n> vectors.\n>\n> Signed-off-by: Shawn Lin \n>\n> ---\n>\n> Changes in v2: None\n>\n> drivers/pci/msi/api.c | 26 ++++++++++++++++++++++++++\n> include/linux/pci.h | 22 ++++++++++++++++++++++\n> 2 files changed, 48 insertions(+)\n>\n...\n> +/**\n> + * pcim_alloc_irq_vectors_affinity() - devres managed pci_alloc_irq_vectors_affinity()\n> + * Interrupt vectors are automatically freed by the devres machinery\n> + */\n> +int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n> +\t\t\t\t unsigned int max_vecs, unsigned int flags,\n> +\t\t\t\t struct irq_affinity *affd)\n> +{\n> +\tdev->is_msi_managed = true;\n> +\treturn pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n> +\t\t\t\t\t flags, affd);\n\nany side effect if pci_alloc_irq_vectors_affinity() return fail and\nis_msi_managed keep true.\n\nFrank\n>","headers":{"Return-Path":"\n ","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 (2048-bit key;\n unprotected) header.d=nxp.com header.i=@nxp.com header.a=rsa-sha256\n header.s=selector1 header.b=lXUtO4x6;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-52686-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=nxp.com header.i=@nxp.com\n header.b=\"lXUtO4x6\"","smtp.subspace.kernel.org;\n arc=fail smtp.client-ip=40.107.159.62","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=nxp.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=nxp.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=nxp.com;"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::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 4fxkyM0Jf0z1yDF\n\tfor ; Fri, 17 Apr 2026 16:10:35 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 8D1D03072054\n\tfor ; Fri, 17 Apr 2026 06:10:31 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 04ABB2F7AAB;\n\tFri, 17 Apr 2026 06:10:30 +0000 (UTC)","from OSPPR02CU001.outbound.protection.outlook.com\n (mail-norwayeastazon11013062.outbound.protection.outlook.com [40.107.159.62])\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 9247B3191BB\n\tfor ; Fri, 17 Apr 2026 06:10:28 +0000 (UTC)","from PA4PR04MB9366.eurprd04.prod.outlook.com (2603:10a6:102:2a9::8)\n by AM0PR04MB6899.eurprd04.prod.outlook.com (2603:10a6:208:183::17) with\n Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.48; Fri, 17 Apr\n 2026 06:10:25 +0000","from PA4PR04MB9366.eurprd04.prod.outlook.com\n ([fe80::75e4:8143:ddbc:6588]) by PA4PR04MB9366.eurprd04.prod.outlook.com\n ([fe80::75e4:8143:ddbc:6588%6]) with mapi id 15.20.9818.023; Fri, 17 Apr 2026\n 06:10:24 +0000"],"ARC-Seal":["i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776406229; cv=fail;\n b=JPNBDaECDWJiaok4P3P0YK8BG1ymL//5WnaMFUyYzHAIpxspfC4ZTHJoKm9L0hBGHjtR1mjDiilpEd1HjOo5SEJwjQDf6r4L8utIoqZOz1pknBFiTLsvECnivn4Ye/VpijzPvlRaITyNMuGcEKORbN9JDVY0KRefAF2bG2ZnF0A=","i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;\n b=ot3i4UqKqlOtOXwGns4upE2Niwa4ug6t8xLjGF8LIhmHsx+Gc4k+9NlPM6n6i1axsggsRmKNTZKJBhFmTKllK0B091YoW4AbQNWnRZMq9ezH+dzmCpT4Nai7uvrhLNritSMEuFhzHG+Czc2PTmXcrrU0bdi+e660kjZzI/etUmC9ikhV460PgZwkWLfy7VVNB1afu9TYUl56cGlZC3qBuNq83EroBuf+st0EonmIydjJbpb/I5lGvpoZVsk7jy1z5nNTnIIulZ2BFyVugpbOEJUMcRNyi7l+Oet9EAWInw62LKDdU9mlDryZIgyjZdgO3910r+pJY+ek7mPtuhC8Zw=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776406229; c=relaxed/simple;\n\tbh=vckmA/ayCUYtlHPXASUrLgfhjI4Ypp6JzLQKWIs7l+Y=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:Content-Type:\n\t Content-Disposition:In-Reply-To:MIME-Version;\n b=dsd9ov0h33dqTjkcH2YvGsBRk9JZhbupPS4h9EhhsIsnpBk+yYPfFu1vWiM0OLD655GmgZDDEr4YWRZVYi/xnc3SK+C/1Upv0pWGctjeTbo6/LK4C22dHL6jfIR9vz9K1koaqz2cotiXXeA7vtaIpI7H+OT2Wx07kAxvU7OaJGw=","i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector10001;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;\n bh=LgLJIh2AcEdHlcdLwt/Eg+ur5hya9bBWvcOpEB0fpaI=;\n b=xncvPm1HvfPCz8bPNO5lAYK3PBRFWY3ZTQVJTffzhSXMOk9jql2PyQa5DXFCdvTfiNDb13xnC2pZSHdkw7j5UzyYHSVFq7FqA+TxuWinAUOSL0milRIDyOVxniWzHBBKZruB3oKkGoIdO3QHC40+5CH0sFRJCjf6XpmJ4hNfe6I/D7yfYzg7mzM44qvTrWBpajPpNqdJdPRrh6L64a54IE25x8jRgfCWIrbiUU1jycxOePOWMF3P24ey3p5zep3tXiWN6mdxTdQfTZVehS5sCYqpXJnUEa47S6ONzu70ORJ9a5LKIYp7rfujyw2wVUgVydvTFGXTr9m9d9nwWjPB9A=="],"ARC-Authentication-Results":["i=2; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=nxp.com;\n spf=pass smtp.mailfrom=nxp.com;\n dkim=pass (2048-bit key) header.d=nxp.com header.i=@nxp.com\n header.b=lXUtO4x6; arc=fail smtp.client-ip=40.107.159.62","i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass\n header.d=nxp.com; arc=none"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=LgLJIh2AcEdHlcdLwt/Eg+ur5hya9bBWvcOpEB0fpaI=;\n b=lXUtO4x6jXHHJG8Sct3ZA2LZ/3k1L4vH0uyMdkdcCxILvfCUE/doo2V6D6TwK+rigM8gDk7gBecRzWpl2ug0JiJRDABiEf5+mpkNcd96SAJK0sqWL9CdIvFRU0ZFrhwKkU2YxZ/83quP04wSeOahNFlFvWahWqAd24sEY1RDCnsLalCZZSG8H2lgsK+MnMNd6nQ/OC2TecS+IWei4rZL45O+sq3IraIpI8KafjvhcNdskOrHiPjpxLXZ/XDE3p+OfpdNuWELc+LJTYlHzhRttlxKqL/fDDtrID1Etc1cMS0JwwCjRZfxa5crYsbxjC43ssmowQ19ZsLXFfXnsf7PPw==","Date":"Fri, 17 Apr 2026 02:10:17 -0400","From":"Frank Li ","To":"Shawn Lin ","Cc":"Bjorn Helgaas ,\n\tNirmal Patel ,\n\tJonathan Derrick ,\n\tKurt Schwemmer ,\n\tLogan Gunthorpe ,\n\tPhilipp Stanner , linux-pci@vger.kernel.org","Subject":"Re: [PATCH v2 1/3] PCI/MSI: Add Devres managed IRQ vectors allocation","Message-ID":"","References":"<1776392767-83668-1-git-send-email-shawn.lin@rock-chips.com>\n <1776392767-83668-2-git-send-email-shawn.lin@rock-chips.com>","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1776392767-83668-2-git-send-email-shawn.lin@rock-chips.com>","X-ClientProxiedBy":"SA0PR11CA0118.namprd11.prod.outlook.com\n (2603:10b6:806:d1::33) To PA4PR04MB9366.eurprd04.prod.outlook.com\n (2603:10a6:102:2a9::8)","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","X-MS-PublicTrafficType":"Email","X-MS-TrafficTypeDiagnostic":"PA4PR04MB9366:EE_|AM0PR04MB6899:EE_","X-MS-Office365-Filtering-Correlation-Id":"d8636191-1cf9-4f8e-9667-08de9c48037b","X-MS-Exchange-SenderADCheck":"1","X-MS-Exchange-AntiSpam-Relay":"0","X-Microsoft-Antispam":"\n\tBCL:0;ARA:13230040|366016|376014|52116014|1800799024|19092799006|56012099003|22082099003|18002099003|38350700014;","X-Microsoft-Antispam-Message-Info":"\n\tsKlq2399IJg6WmoDq+N7DgPEpAexQIkQ4PLulG+i/3MGDZYnMFQ/nKAnC1zxq1lpeRld7YYYo0Dhz+vPfV0N1AKnLU7YOq2TYjCzR8EAZLTrLNVBjucpIsdAF/AUgE8f8EaySTB09D/ZyZD54T1FYJmuxYQIWl/8bOWTP4MKY20RjjFktLAUlgAW9UnnUMXUe4KuFUlBodwrcsYBAgVkXrKshabaXrPHPz+3XG1AJRE8c/1gH1bfq0HogwSL0ThaNXumyGSzVhHR8qIh1HQ0WgeUaxAIxW+7rQsIIKjAONLHk90XRcewPauwboAB5uVWEePD5TOs7v+CTWmnDoAOIfCJu5jlgXbBiL43MXzpy2ggtFqw/IpdVe59E+px1NQnokFQXcdMEd3cjZCtFY1XpWbKAkp1ZzrXWNQYjZrf+KVLg8tSg1TDOz2k0Rzp7duXozQ89bjAyibksRdlB+r2fzUPiY567MeLDobvtbmrMpyHIAEJer3j56124ta9czKUG+iLaCyFChEblgnl3zxs9mq7TKBBGv8QX61uzGrfaAJ14C8ZkDE5PF6cAZaC/LfjLvizTycSm8At8ZLEa12iUBORb52RF65BEPeJfb8h/cg05Ol53WyeeJwJCY5h8gB9/Qk/3MP1w6huSVPkAOJEkwRks9bt5NDWNw/sC+7iRO5uLSWhURPwRls+iHG3rg9wmsiZD1xiZYHzUXjnrYo25V1jZov7+ygXgtXBrSmZ8iMgxOQ3yDO1FmItUwF6ZB1TlOI5DLyfM9mOFpUuol4my99SvcVeAAOcIWhH9cV9a18=","X-Forefront-Antispam-Report":"\n\tCIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA4PR04MB9366.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(52116014)(1800799024)(19092799006)(56012099003)(22082099003)(18002099003)(38350700014);DIR:OUT;SFP:1101;","X-MS-Exchange-AntiSpam-MessageData-ChunkCount":"1","X-MS-Exchange-AntiSpam-MessageData-0":"\n EyUiaqr+/+0tQReEldf4ESUqOK03bvP5M5b/X7bJ+cRjsj0zSTu78cnV+NnacAIkAN1Qt9T5+VzP0QM9lj2VBWoJ2w2m0chtx5CWEulxa4nU8yKftd5CjaTqJVfDFoioklOL6WuseH+pMCkjAhb8n+MdsAl5ZWKluW/uGqlxIXQChCWpin80j+IzuGI5Rsfi5BeSMKrPzUmzzk8OZ/JjUorT4pKs3TtzjFTY5UWpwHNm0dlVS3U1R2k+2e4s8/7nDet3TIQS58aZ3jTJXL96v3KDeOoyvLu5+VF4CqQxmMQ4ntuFCfhiwcsrhrM6rNuTZgRlPmqIN6cAGtxxZSlHyELmUn+YBw3oWZJUTFQk2LaSQdv2sArNMCWrng4BY3iAXfMj0KrC8UCDCGlOC/x9ah7pWPX8TBURx30/48Q3tdyqZo27K1cLPzCYdIY1cg9MHv4cd2gTNOwgJLGTBmAKo5LkCs+nZVH1yhc7ZDm/5oSugnZ78w+rSeXbe7UoKUZc2eOhAAVspqJWcmmSVIDleQnAcLnGBJGiVm1QUVwJw1k/vyPSFKgq3knG6YFU2uAU/zC6RS/e2nwAcmQz9gwUsQFuIUbTC8Eu01kIT430aknsG4ATsbyxB5LDuIN3DaePvjrFHoQ+WCWE5dIhQHRoCNFjoUmDO/BzYo8938AzzU1f9gztMk7d5C+kUcWEL9odHSabxBlePZywgeZdI/jXluza2HsqO3ILZ9QiNPPTa904dBuwnZilIrt6AVauAs9Y1gfys+zqyp9Suxr9cGu/R31+MNbWfdT/84B7zP4Gfdu8NHJEtRh/OkaLFHI5XQhqx4L7d3XQspTJDfthyvvHibT0u3BVj/GrUz1AFzJP74XE4uiX5Kyo2WeVl3n7Nx6P6SgpL9MefqnJ2dlFZQ3dpAbXpnggZEfzD8s2AGdvBWwj79Tpehcw/zuTlN75okysZXgyEBVl7Dio5+MZhz6LxiJrfjiLmhOxd4Td5e724fdMLY+m0dmRFCF8C/+PUHkuNy4LE3H5jde6mtLeBgBaPBunysbl5YluX0aAWmd5J4kk55gjUyAPkx9nzZb72aoGrbmjmrQGbLFME9D+ZhFgof2mIEe88oBIAKa+HxG2idDrQZmOEYODZagS2E2jR0jITn6RRlDWJYGVgiKFfUokKY6fdyl2SB5doWAmistOWhc2rr3LOoiCqVhDVwRmhLH62A8rsCOZUEhm3O/kk5bmCsMADrgLjc7SKzdV0RQNNYOvBBYSg0t7DELSdnyacSnAJlK2lDng2ZaJtG6ef3EemocSVRsWTHjAqZb5y3X0xhJjcHczqB2cOcpWzG09XNUqAPezrRTb7ZveZwU1Mil8X5ExV8/40op1vnoCPXUKv1o2EM0qh7XOgKrKzk9Xjwu4DnHjQS5bxX4mvm4/kUsO1vect2Q8u0Nm2yfveG6TAzrHmjGcc3e26FUMRti8E8P27aEySHtudXtUvP9Gu98QaZCtdYOfs+xoUm9uQMAf2NSG/muLm6yttAcz6HsEO3hzAi0nnk8tTcL5pJuMJPdnegWB+XGVgu8iYAD3AL8pO3SqMoraPW8vRInLiIi8RouW0OmvBaR1O7i2hOMetne7qo0Qogvh6YC6SWwEVStJhFiU7kP3xMtZuUmQct81lITGEJIZfHfsUBeeEA38DZmZ7wH1F1nnn2DjZ37fU/kUWdd5BtKNQ2g6QsqJgy8K0FNT","X-OriginatorOrg":"nxp.com","X-MS-Exchange-CrossTenant-Network-Message-Id":"\n d8636191-1cf9-4f8e-9667-08de9c48037b","X-MS-Exchange-CrossTenant-AuthSource":"PA4PR04MB9366.eurprd04.prod.outlook.com","X-MS-Exchange-CrossTenant-AuthAs":"Internal","X-MS-Exchange-CrossTenant-OriginalArrivalTime":"17 Apr 2026 06:10:24.5020\n (UTC)","X-MS-Exchange-CrossTenant-FromEntityHeader":"Hosted","X-MS-Exchange-CrossTenant-Id":"686ea1d3-bc2b-4c6f-a92c-d99c5c301635","X-MS-Exchange-CrossTenant-MailboxType":"HOSTED","X-MS-Exchange-CrossTenant-UserPrincipalName":"\n SYnJS4oN0bbGXxExF3W5qacTbDZB7zWmLGLciXbz2qDzEQLHYU8MI+/Ino8Z/paE5hcoPr8BxiqLd340JA2FzQ==","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"AM0PR04MB6899"}},{"id":3678538,"web_url":"http://patchwork.ozlabs.org/comment/3678538/","msgid":"<9cafe1d5-1105-cfbe-2ef4-3f018ef7025d@rock-chips.com>","list_archive_url":null,"date":"2026-04-17T06:32:15","subject":"Re: [PATCH v2 1/3] PCI/MSI: Add Devres managed IRQ vectors allocation","submitter":{"id":66993,"url":"http://patchwork.ozlabs.org/api/people/66993/","name":"Shawn Lin","email":"shawn.lin@rock-chips.com"},"content":"Hi Frank\n\n在 2026/04/17 星期五 14:10, Frank Li 写道:\n> On Fri, Apr 17, 2026 at 10:26:05AM +0800, Shawn Lin wrote:\n>> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for\n>> pci device drivers which rely on the devres machinery to help cleanup the IRQ\n>> vectors.\n>>\n>> Signed-off-by: Shawn Lin \n>>\n>> ---\n>>\n>> Changes in v2: None\n>>\n>> drivers/pci/msi/api.c | 26 ++++++++++++++++++++++++++\n>> include/linux/pci.h | 22 ++++++++++++++++++++++\n>> 2 files changed, 48 insertions(+)\n>>\n> ...\n>> +/**\n>> + * pcim_alloc_irq_vectors_affinity() - devres managed pci_alloc_irq_vectors_affinity()\n>> + * Interrupt vectors are automatically freed by the devres machinery\n>> + */\n>> +int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n>> +\t\t\t\t unsigned int max_vecs, unsigned int flags,\n>> +\t\t\t\t struct irq_affinity *affd)\n>> +{\n>> +\tdev->is_msi_managed = true;\n>> +\treturn pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n>> +\t\t\t\t\t flags, affd);\n> \n> any side effect if pci_alloc_irq_vectors_affinity() return fail and\n> is_msi_managed keep true.\n\nThanks for the review! This is a good point.\n\nYou're absolutely right that in the current implementation, if\npci_alloc_irq_vectors_affinity() fails, is_msi_managed remains true\nwhile no vectors are actually allocated.\n\nThis replicates the behavior of pcim_enable_device() +\npci_alloc_irq_vectors_affinity() , which also sets\nis_msi_managed unconditionally, but that doesn't make it ideal.\n\nI think we should fix this for better self-contained behavior. The\npcim_* APIs should be robust on their own.\n\nI'll move the is_msi_managed assignment to after successful allocation\nin v3, if the general apporach looks feasible.\n\n\n> \n> Frank\n>>\n> \n>","headers":{"Return-Path":"\n ","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=C7DQVASJ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.105.105.114; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-52690-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=\"C7DQVASJ\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=220.197.32.102","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 tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114])\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 4fxn9c3KXQz1yDF\n\tfor ; Fri, 17 Apr 2026 17:50:28 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id 517C73053297\n\tfor ; Fri, 17 Apr 2026 07:48:11 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id EC32A347BC4;\n\tFri, 17 Apr 2026 07:48:09 +0000 (UTC)","from mail-m32102.qiye.163.com (mail-m32102.qiye.163.com\n [220.197.32.102])\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 AAD5A339844\n\tfor ; Fri, 17 Apr 2026 07:48:03 +0000 (UTC)","from [172.16.12.17] (unknown [58.22.7.114])\n\tby smtp.qiye.163.com (Hmail) with ESMTP id 3b19f2c60;\n\tFri, 17 Apr 2026 14:32:16 +0800 (GMT+08:00)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776412089; cv=none;\n b=IEDg8BhnOwcdiQ85RoIeXbIcVQHQvt9/BYj7IzT4PvYrfiAII/FQLffC3cXDmU5Q144r5gy0sJ5g3UNwzVuN+3rkP0xEzyMMNQb4NNy9t6wL40unmBpQiE1mzon7lSa32a8NJGn5AjVb/L+LGYPq1qrzRd5pDnfa9LaXr6ENXJE=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776412089; c=relaxed/simple;\n\tbh=UHMEUIW+jh05lb5eza5TT3MgxQCo16NqiMJS/Eo8ifg=;\n\th=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From:\n\t In-Reply-To:Content-Type;\n b=bEFZEpITZmoQcRQ+L+p4QRbhUCnVVwyAWX7YisQ11DupW9xuqpaejWZ+fO+WVkIbjd9lm7P+Zf6b77FSxoBD5XyIZ6NVRivR3T67tUXxkoNKjiXJtgToWb7ObUI9QSvcHm5SfkRhjvrQgPcBEs0zIIa/QxwPQS2c6VxUYdhtENQ=","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=C7DQVASJ; arc=none smtp.client-ip=220.197.32.102","Message-ID":"<9cafe1d5-1105-cfbe-2ef4-3f018ef7025d@rock-chips.com>","Date":"Fri, 17 Apr 2026 14:32:15 +0800","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101\n Thunderbird/102.15.1","Cc":"shawn.lin@rock-chips.com, Bjorn Helgaas ,\n Nirmal Patel ,\n Jonathan Derrick ,\n Kurt Schwemmer ,\n Logan Gunthorpe , Philipp Stanner ,\n linux-pci@vger.kernel.org","Subject":"Re: [PATCH v2 1/3] PCI/MSI: Add Devres managed IRQ vectors allocation","To":"Frank Li ","References":"<1776392767-83668-1-git-send-email-shawn.lin@rock-chips.com>\n <1776392767-83668-2-git-send-email-shawn.lin@rock-chips.com>\n ","From":"Shawn Lin ","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-HM-Tid":"0a9d9a23e25809cckunmb867f1f8346007","X-HM-MType":"1","X-HM-Spam-Status":"e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly\n\ttZV1koWUFDSUNOT01LS0k3V1ktWUFJV1kPCRoVCBIfWUFZQxoaH1YeSENJGEhDGU4aGk1WFRQJFh\n\toXVRMBExYaEhckFA4PWVdZGBILWUFZTkNVSUlVTFVKSk9ZV1kWGg8SFR0UWUFZT0tIVUpLSU9PT0\n\thVSktLVUpCS0tZBg++","DKIM-Signature":"a=rsa-sha256;\n\tb=C7DQVASJ/YUwbZBhp4b02j3GnpstuVTrofhcWEgDz7sR8qvSM+7Nlu0pE1hc+UphNWEVa0Lb2XPuHpWFLLY9ntZnOX3gW9nJUXVNtNvL6N1zY/uLyN8ChruFXN+q6xepI5PoFv9Yns1c4PLYRMFnUQstfjZ/upQkn1uCYBNpYMo=;\n c=relaxed/relaxed; s=default; d=rock-chips.com; v=1;\n\tbh=KoYhaGYwqJWwSEpHtu2ExjmIs9RJzVAemt5tG5n9Xuw=;\n\th=date:mime-version:subject:message-id:from;"}},{"id":3678580,"web_url":"http://patchwork.ozlabs.org/comment/3678580/","msgid":"","list_archive_url":null,"date":"2026-04-17T08:44:30","subject":"Re: [PATCH v2 1/3] PCI/MSI: Add Devres managed IRQ vectors\n allocation","submitter":{"id":90407,"url":"http://patchwork.ozlabs.org/api/people/90407/","name":"Philipp Stanner","email":"phasta@mailbox.org"},"content":"Hello Shawn,\n\nOn Fri, 2026-04-17 at 10:26 +0800, Shawn Lin wrote:\n> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for\n> pci device drivers which rely on the devres machinery to help cleanup the IRQ\n> vectors.\n\nThe commit message doesn't really detail *why* you add this. The rule\nof thumb is to first describe the problem and then describe roughly\nwhat the patch does about the problem. That also makes it easier for\nreviewers to quickly match code to intent\n\n> \n> Signed-off-by: Shawn Lin \n\nCould contain a Suggested-by: Philipp Stanner ? :)\n\n> \n> ---\n> \n> Changes in v2: None\n> \n>  drivers/pci/msi/api.c | 26 ++++++++++++++++++++++++++\n>  include/linux/pci.h   | 22 ++++++++++++++++++++++\n>  2 files changed, 48 insertions(+)\n> \n> diff --git a/drivers/pci/msi/api.c b/drivers/pci/msi/api.c\n> index c18559b..2362fca 100644\n> --- a/drivers/pci/msi/api.c\n> +++ b/drivers/pci/msi/api.c\n> @@ -297,6 +297,32 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n>  EXPORT_SYMBOL(pci_alloc_irq_vectors_affinity);\n>  \n>  /**\n> + * pcim_alloc_irq_vectors() - devres managed pci_alloc_irq_vectors()\n> + * Interrupt vectors are automatically freed by the devres machinery\n\nnit: \"devres machinery\" is not a very common expression. I would just\nsay \"through devres\".\n\nFor correct docstrings, though, you need to describe all the parameters\nbelow, like 'dev', 'min_vecs' etc.\n\nAlso the return value needs to be described.\n\nhttps://docs.kernel.org/doc-guide/kernel-doc.html#function-documentation\n\nDo you do \"make htmldocs\"? I think that should provide warnings for\nthat?\n\n\n> + */\n> +int pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n> +\t\t\t   unsigned int max_vecs, unsigned int flags)\n> +{\n> +\treturn pcim_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n> +\t\t\t\t\t       flags, NULL);\n> +}\n> +EXPORT_SYMBOL(pcim_alloc_irq_vectors);\n> +\n> +/**\n> + * pcim_alloc_irq_vectors_affinity() - devres managed pci_alloc_irq_vectors_affinity()\n> + * Interrupt vectors are automatically freed by the devres machinery\n> + */\n\nSame here with docstrings\n\n> +int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n> +\t\t\t\t   unsigned int max_vecs, unsigned int flags,\n> +\t\t\t\t   struct irq_affinity *affd)\n> +{\n> +\tdev->is_msi_managed = true;\n\nDo you have to set this to 'false' again? If so, who does that? A small\ncomment here could describe that.\n\n\nNote that for your cleanup, in the long run, once all users are ported,\nthese helper bools should not be necessary anymore because devres\nalready stores all the relevant state.\n\nLikewise, I would like to remove the \"is_managed\" and \"is_pinned\"\nflags, but that can only be done once all API users are ported.\n\nIf this is the case with 'is_msi_managed', too, there should be a\ncleanup TODO comment in my opinion. \"This can be removed once…\"\n\n(But I'm not super deep in PCI devres since many months; but I think I\nremember that not properly dealing with that flag state even caused us\na bug or two in the past)\n\n\nRegards,\nPhilipp\n\n> +\treturn pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n> +\t\t\t\t\t      flags, affd);\n> +}\n> +EXPORT_SYMBOL(pcim_alloc_irq_vectors_affinity);\n> +\n> +/**\n>   * pci_irq_vector() - Get Linux IRQ number of a device interrupt vector\n>   * @dev: the PCI device to operate on\n>   * @nr:  device-relative interrupt vector index (0-based); has different\n> diff --git a/include/linux/pci.h b/include/linux/pci.h\n> index 2c44545..3716c67 100644\n> --- a/include/linux/pci.h\n> +++ b/include/linux/pci.h\n> @@ -1770,6 +1770,12 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n>  \t\t\t\t   unsigned int max_vecs, unsigned int flags,\n>  \t\t\t\t   struct irq_affinity *affd);\n>  \n> +int pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n> +\t\t\t  unsigned int max_vecs, unsigned int flags);\n> +int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n> +\t\t\t\t   unsigned int max_vecs, unsigned int flags,\n> +\t\t\t\t   struct irq_affinity *affd);\n> +\n>  bool pci_msix_can_alloc_dyn(struct pci_dev *dev);\n>  struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,\n>  \t\t\t\t     const struct irq_affinity_desc *affdesc);\n> @@ -1812,6 +1818,22 @@ pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n>  \t\t\t\t\t      flags, NULL);\n>  }\n>  \n> +static inline int\n> +pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n> +\t\t\t       unsigned int max_vecs, unsigned int flags,\n> +\t\t\t       struct irq_affinity *aff_desc)\n> +{\n> +\treturn pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n> +\t\t\t\t\t      flags, aff_desc);\n> +}\n> +static inline int\n> +pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n> +\t\t      unsigned int max_vecs, unsigned int flags)\n> +{\n> +\treturn pcim_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n> +\t\t\t\t\t      flags, NULL);\n> +}\n> +\n>  static inline bool pci_msix_can_alloc_dyn(struct pci_dev *dev)\n>  { return false; }\n>  static inline struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,","headers":{"Return-Path":"\n ","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 (2048-bit key;\n secure) header.d=mailbox.org header.i=@mailbox.org header.a=rsa-sha256\n header.s=mail20150812 header.b=kjfrEH0S;\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-52702-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org\n header.b=\"kjfrEH0S\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=80.241.56.172","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=mailbox.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=mailbox.org"],"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)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxpTB0Kyjz1yD3\n\tfor ; Fri, 17 Apr 2026 18:49:02 +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 72AD331317E3\n\tfor ; Fri, 17 Apr 2026 08:44:42 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 9A3DE357A3E;\n\tFri, 17 Apr 2026 08:44:41 +0000 (UTC)","from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172])\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 A9ED92F532F\n\tfor ; Fri, 17 Apr 2026 08:44:38 +0000 (UTC)","from smtp1.mailbox.org (smtp1.mailbox.org\n [IPv6:2001:67c:2050:b231:465::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby mout-p-202.mailbox.org (Postfix) with ESMTPS id 4fxpN30mj4z9tsW;\n\tFri, 17 Apr 2026 10:44:35 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776415481; cv=none;\n b=kxOunI78R9bGSZvMJF9xq8Ri97ShwCN9J4YpAxebHXynxZptsF7oKxP5TBL4z6a3iZGdj44YN1BftLG/YoBGsnKeibkkk825Zgebww4ZXtI7UqibiQdm0AOy1knZ2PkDm/ciczzlypp5QroShfY38/TgSJ5kfJI5WQQ9ZMoPbNM=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776415481; c=relaxed/simple;\n\tbh=LzLfSmMqkxxBQDx7RKbg5cYHZJ3QetjqB5mjFYhHfcI=;\n\th=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:\n\t Content-Type:MIME-Version;\n b=egFy188ybEmvAdZa+sse6rYleN9oD9ECtgjZ8fZHal6tu5G08ssw+nKfn3HAqdBemkdRqCp14EPVGKdYt5LJmBoQwqiIoNveWl9oK+A4anM3mjkZhUD/v0Qnjsko7HZthU/a62JDFEhc4jey7P0joLoZiVNqV9ggffFsFSv1QPI=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=mailbox.org;\n spf=pass smtp.mailfrom=mailbox.org;\n dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org\n header.b=kjfrEH0S; arc=none smtp.client-ip=80.241.56.172","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org;\n s=mail20150812;\n\tt=1776415475; h=from:from:reply-to:reply-to:subject:subject:date:date:\n\t message-id:message-id:to:to:cc:cc:mime-version:mime-version:\n\t content-type:content-type:\n\t content-transfer-encoding:content-transfer-encoding:\n\t in-reply-to:in-reply-to:references:references;\n\tbh=pc4AKGOAkJyll4Gwgm7UxI/RhCv1MvaWzCa10tGDeeQ=;\n\tb=kjfrEH0SCKsPBDA7rfy0bGW7tcsQmDrlEawtDjMTQnp7QLn1CojH+SAZog9dqcr0rk8WYC\n\t9Yi03LBVOpsqGVEMR4/UDoHH827lFbelVGZrGQtEDfvPZLpqS4v67pWCMrESMFaTRJt0ED\n\tfzx5XYlffOdKS1mZb8vP9PMnSF+R13FrgUE4XCJ6Av4AY5JXcZfiHVbJhuZTkN+x71BEf1\n\tQtcSQg5pS0PrQE0LsM199f7fjccO8qb8tTHsB/6lyBWaYjKQEiT8OdbbtkGnF1DlnjWBx6\n\tC3GTR1rF1rGgRstcAB3X/35FQlxtFwppeBVhR7ikKnb2bTFG0yClyIW6991Rnw==","Message-ID":"","Subject":"Re: [PATCH v2 1/3] PCI/MSI: Add Devres managed IRQ vectors\n allocation","From":"Philipp Stanner ","Reply-To":"phasta@kernel.org","To":"Shawn Lin , Bjorn Helgaas ","Cc":"Nirmal Patel , Jonathan Derrick\n , Kurt Schwemmer\n , Logan Gunthorpe ,\n Philipp Stanner , linux-pci@vger.kernel.org","Date":"Fri, 17 Apr 2026 10:44:30 +0200","In-Reply-To":"<1776392767-83668-2-git-send-email-shawn.lin@rock-chips.com>","References":"<1776392767-83668-1-git-send-email-shawn.lin@rock-chips.com>\n\t <1776392767-83668-2-git-send-email-shawn.lin@rock-chips.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","X-MBO-RS-META":"nb44okfzyy9dgbfzasfxanhfuobrt5he","X-MBO-RS-ID":"23fd5b5fd99b053adac"}},{"id":3678620,"web_url":"http://patchwork.ozlabs.org/comment/3678620/","msgid":"","list_archive_url":null,"date":"2026-04-17T09:33:27","subject":"Re: [PATCH v2 1/3] PCI/MSI: Add Devres managed IRQ vectors allocation","submitter":{"id":66993,"url":"http://patchwork.ozlabs.org/api/people/66993/","name":"Shawn Lin","email":"shawn.lin@rock-chips.com"},"content":"Hi Philipp\n\n在 2026/04/17 星期五 16:44, Philipp Stanner 写道:\n> Hello Shawn,\n> \n> On Fri, 2026-04-17 at 10:26 +0800, Shawn Lin wrote:\n>> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for\n>> pci device drivers which rely on the devres machinery to help cleanup the IRQ\n>> vectors.\n> \n> The commit message doesn't really detail *why* you add this. The rule\n> of thumb is to first describe the problem and then describe roughly\n> what the patch does about the problem. That also makes it easier for\n> reviewers to quickly match code to intent\n> \n\nSure, will do.\n\n>>\n>> Signed-off-by: Shawn Lin \n> \n> Could contain a Suggested-by: Philipp Stanner ? :)\n> \n\nSure!\n\n>>\n>> ---\n>>\n>> Changes in v2: None\n>>\n>>  drivers/pci/msi/api.c | 26 ++++++++++++++++++++++++++\n>>  include/linux/pci.h   | 22 ++++++++++++++++++++++\n>>  2 files changed, 48 insertions(+)\n>>\n>> diff --git a/drivers/pci/msi/api.c b/drivers/pci/msi/api.c\n>> index c18559b..2362fca 100644\n>> --- a/drivers/pci/msi/api.c\n>> +++ b/drivers/pci/msi/api.c\n>> @@ -297,6 +297,32 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n>>  EXPORT_SYMBOL(pci_alloc_irq_vectors_affinity);\n>> \n>>  /**\n>> + * pcim_alloc_irq_vectors() - devres managed pci_alloc_irq_vectors()\n>> + * Interrupt vectors are automatically freed by the devres machinery\n> \n> nit: \"devres machinery\" is not a very common expression. I would just\n> say \"through devres\".\n> \n> For correct docstrings, though, you need to describe all the parameters\n> below, like 'dev', 'min_vecs' etc.\n> \n> Also the return value needs to be described.\n> \n> https://docs.kernel.org/doc-guide/kernel-doc.html#function-documentation\n> \n> Do you do \"make htmldocs\"? I think that should provide warnings for\n> that?\n> \n\n\nAhh, I didn't. I will describe all the parameters.\n\n> \n>> + */\n>> +int pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n>> +\t\t\t   unsigned int max_vecs, unsigned int flags)\n>> +{\n>> +\treturn pcim_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n>> +\t\t\t\t\t       flags, NULL);\n>> +}\n>> +EXPORT_SYMBOL(pcim_alloc_irq_vectors);\n>> +\n>> +/**\n>> + * pcim_alloc_irq_vectors_affinity() - devres managed pci_alloc_irq_vectors_affinity()\n>> + * Interrupt vectors are automatically freed by the devres machinery\n>> + */\n> \n> Same here with docstrings\n> \n>> +int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n>> +\t\t\t\t   unsigned int max_vecs, unsigned int flags,\n>> +\t\t\t\t   struct irq_affinity *affd)\n>> +{\n>> +\tdev->is_msi_managed = true;\n> \n> Do you have to set this to 'false' again? If so, who does that? A small\n> comment here could describe that.\n> \n> \n> Note that for your cleanup, in the long run, once all users are ported,\n> these helper bools should not be necessary anymore because devres\n> already stores all the relevant state.\n> \n> Likewise, I would like to remove the \"is_managed\" and \"is_pinned\"\n> flags, but that can only be done once all API users are ported.\n> \n> If this is the case with 'is_msi_managed', too, there should be a\n> cleanup TODO comment in my opinion. \"This can be removed once…\"\n> \n\nMy initial plan was to make it into 3 steps:\n(1) Set is_msi_managed true via pcim_alloc_irq_vectors*();\n(2) All pcim_enable_device() + pci_alloc_irq_vectors*() users are ported\n(3) remove is_msi_managed assignment‌ from pcim_enable_device()\n\nAs you could see, on step 1 & 2, pcim_enable_device() +\npci_alloc_irq_vectors*() users uncondictionly set is_msi_managed true.\nSo they don't have to set it false again. At least it keeps the previous\nbehaviour. For potential new pci_enable_device() +\npcim_alloc_irq_vectors*() users before all the convertion is done, It's\nindeed a problem here.\n\nDoes something below make sense to you?\n\nint pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int\n min_vecs, unsigned int max_vecs,\n unsigned int flags,\n struct irq_affinity *affd)\n{\n\tint nvecs;\n\tbool already_set_msi_managed = dev->is_msi_managed;\n\n\tif (!already_set_msi_managed)\n\t\tdev->is_msi_managed= true;\n\n\tnvecs = pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n\t\t\t\t\t flags, affd);\n\tif (nvecs < 0 && !already_set_msi_managed)\n\t\tdev->is_msi_managed = false;\n\n\treturn nvecs;\n}\n\n\nThanks.\n\n> (But I'm not super deep in PCI devres since many months; but I think I\n> remember that not properly dealing with that flag state even caused us\n> a bug or two in the past)\n> \n> \n> Regards,\n> Philipp\n> \n>> +\treturn pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n>> +\t\t\t\t\t      flags, affd);\n>> +}\n>> +EXPORT_SYMBOL(pcim_alloc_irq_vectors_affinity);\n>> +\n>> +/**\n>>   * pci_irq_vector() - Get Linux IRQ number of a device interrupt vector\n>>   * @dev: the PCI device to operate on\n>>   * @nr:  device-relative interrupt vector index (0-based); has different\n>> diff --git a/include/linux/pci.h b/include/linux/pci.h\n>> index 2c44545..3716c67 100644\n>> --- a/include/linux/pci.h\n>> +++ b/include/linux/pci.h\n>> @@ -1770,6 +1770,12 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n>>  \t\t\t\t   unsigned int max_vecs, unsigned int flags,\n>>  \t\t\t\t   struct irq_affinity *affd);\n>> \n>> +int pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n>> +\t\t\t  unsigned int max_vecs, unsigned int flags);\n>> +int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n>> +\t\t\t\t   unsigned int max_vecs, unsigned int flags,\n>> +\t\t\t\t   struct irq_affinity *affd);\n>> +\n>>  bool pci_msix_can_alloc_dyn(struct pci_dev *dev);\n>>  struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,\n>>  \t\t\t\t     const struct irq_affinity_desc *affdesc);\n>> @@ -1812,6 +1818,22 @@ pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n>>  \t\t\t\t\t      flags, NULL);\n>>  }\n>> \n>> +static inline int\n>> +pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n>> +\t\t\t       unsigned int max_vecs, unsigned int flags,\n>> +\t\t\t       struct irq_affinity *aff_desc)\n>> +{\n>> +\treturn pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n>> +\t\t\t\t\t      flags, aff_desc);\n>> +}\n>> +static inline int\n>> +pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n>> +\t\t      unsigned int max_vecs, unsigned int flags)\n>> +{\n>> +\treturn pcim_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n>> +\t\t\t\t\t      flags, NULL);\n>> +}\n>> +\n>>  static inline bool pci_msix_can_alloc_dyn(struct pci_dev *dev)\n>>  { return false; }\n>>  static inline struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,\n> \n>","headers":{"Return-Path":"\n ","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=IEm5OMzq;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.232.135.74; helo=sto.lore.kernel.org;\n envelope-from=linux-pci+bounces-52708-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=\"IEm5OMzq\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=45.254.49.241","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 sto.lore.kernel.org (sto.lore.kernel.org [172.232.135.74])\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 4fxqtm6t4Nz1yDF\n\tfor ; Fri, 17 Apr 2026 19:52:48 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 0C15C306FF71\n\tfor ; Fri, 17 Apr 2026 09:49:04 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 9EFB337C920;\n\tFri, 17 Apr 2026 09:49:02 +0000 (UTC)","from mail-m49241.qiye.163.com (mail-m49241.qiye.163.com\n [45.254.49.241])\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 DA31A38F22E\n\tfor ; Fri, 17 Apr 2026 09:48:58 +0000 (UTC)","from [172.16.12.17] (unknown [58.22.7.114])\n\tby smtp.qiye.163.com (Hmail) with ESMTP id 3b21a2228;\n\tFri, 17 Apr 2026 17:33:28 +0800 (GMT+08:00)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776419342; cv=none;\n b=rv55E1NsCNGtaZJwXVjjMwqUm8uzQs1JhT8vQi7T4OF7d/GTEPT1otktdV2Qjzq5CUembJfWLDnGFXBNe9OqGRHj136ROACoc6dUvlBpcPcIN9GBXw+Rxs5ezr4KdiVkfcF9nODoQjgOK3PtYJtqXAdJvZg3ura9yXjovTorE30=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776419342; c=relaxed/simple;\n\tbh=+AAe+Rq0Y2fN8Yqy3EtLORPir6cAxY6MZ1QNfd4z5tw=;\n\th=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From:\n\t In-Reply-To:Content-Type;\n b=t+tSWUEBsbCfWrNdlWjGQhKOXvhcsjpZfXAMj46M8uuCHztxIHABwm49CIsa0B88CdVvT26YlYW6doUYo4PosZ6N6ts86iauMrVClyolrHYgfF1OXGY/+XsNDIQcCD1/w5ckBs5grZ0mMOqFVRFHZIHHqmjiW5VjJKaTQJN+fIQ=","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=IEm5OMzq; arc=none smtp.client-ip=45.254.49.241","Message-ID":"","Date":"Fri, 17 Apr 2026 17:33:27 +0800","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101\n Thunderbird/102.15.1","Cc":"shawn.lin@rock-chips.com, Nirmal Patel ,\n Jonathan Derrick ,\n Kurt Schwemmer ,\n Logan Gunthorpe , linux-pci@vger.kernel.org,\n Bjorn Helgaas ","Subject":"Re: [PATCH v2 1/3] PCI/MSI: Add Devres managed IRQ vectors allocation","To":"phasta@kernel.org","References":"<1776392767-83668-1-git-send-email-shawn.lin@rock-chips.com>\n <1776392767-83668-2-git-send-email-shawn.lin@rock-chips.com>\n ","From":"Shawn Lin ","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-HM-Tid":"0a9d9ac9c74409cckunmb9bc2d66383580","X-HM-MType":"1","X-HM-Spam-Status":"e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly\n\ttZV1koWUFDSUNOT01LS0k3V1ktWUFJV1kPCRoVCBIfWUFZQk4dGlZOHhhPHR1CH0hCHkJWFRQJFh\n\toXVRMBExYaEhckFA4PWVdZGBILWUFZTkNVSUlVTFVKSk9ZV1kWGg8SFR0UWUFZT0tIVUpLSEpKQk\n\txVSktLVUpCS0tZBg++","DKIM-Signature":"a=rsa-sha256;\n\tb=IEm5OMzqjTDGxlDp0rd5RD0KIhWeKCE88eP1D3Sl5LoP2HoJZw5AflBD3FHf38tS1J5zbaNxY74buW/aCKaHyHGX9Ri6TOJ0jWVujc/Y4+D//foFfTaOF8nCCz3g3gy6wgeAg2XPbuCizf2MpRhht02QrYLxurKEsFeUR29eT9g=;\n c=relaxed/relaxed; s=default; d=rock-chips.com; v=1;\n\tbh=9d4bNswcIBZn5HudovMCBgtCixEer0pSL5vdahuMXSY=;\n\th=date:mime-version:subject:message-id:from;"}},{"id":3679324,"web_url":"http://patchwork.ozlabs.org/comment/3679324/","msgid":"","list_archive_url":null,"date":"2026-04-20T09:28:59","subject":"Re: [PATCH v2 1/3] PCI/MSI: Add Devres managed IRQ vectors\n allocation","submitter":{"id":90407,"url":"http://patchwork.ozlabs.org/api/people/90407/","name":"Philipp Stanner","email":"phasta@mailbox.org"},"content":"On Fri, 2026-04-17 at 17:33 +0800, Shawn Lin wrote:\n> Hi Philipp\n> \n> 在 2026/04/17 星期五 16:44, Philipp Stanner 写道:\n> > Hello Shawn,\n> > \n> > On Fri, 2026-04-17 at 10:26 +0800, Shawn Lin wrote:\n> > > pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for\n> > > pci device drivers which rely on the devres machinery to help cleanup the IRQ\n> > > vectors.\n> > \n> > The commit message doesn't really detail *why* you add this. The rule\n> > of thumb is to first describe the problem and then describe roughly\n> > what the patch does about the problem. That also makes it easier for\n> > reviewers to quickly match code to intent\n> > \n> \n> Sure, will do.\n> > `\n\n[…]\n\n> > > +int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n> > > +\t\t\t\t   unsigned int max_vecs, unsigned int flags,\n> > > +\t\t\t\t   struct irq_affinity *affd)\n> > > +{\n> > > +\tdev->is_msi_managed = true;\n> > \n> > Do you have to set this to 'false' again? If so, who does that? A small\n> > comment here could describe that.\n> > \n> > \n> > Note that for your cleanup, in the long run, once all users are ported,\n> > these helper bools should not be necessary anymore because devres\n> > already stores all the relevant state.\n> > \n> > Likewise, I would like to remove the \"is_managed\" and \"is_pinned\"\n> > flags, but that can only be done once all API users are ported.\n> > \n> > If this is the case with 'is_msi_managed', too, there should be a\n> > cleanup TODO comment in my opinion. \"This can be removed once…\"\n> > \n> \n> My initial plan was to make it into 3 steps:\n> (1) Set is_msi_managed true via pcim_alloc_irq_vectors*();\n> (2) All pcim_enable_device() + pci_alloc_irq_vectors*() users are ported\n> (3) remove is_msi_managed assignment‌ from pcim_enable_device()\n> \n> As you could see, on step 1 & 2, pcim_enable_device() +\n> pci_alloc_irq_vectors*() users uncondictionly set is_msi_managed true.\n\npcim_enable_device() does not set that flag (if you meant that; I'm not\nsure).\n\nThe flag is already set by pcim_setup_msi_release(). Why do you need a\nsecond place to set it?\n\n> So they don't have to set it false again. At least it keeps the previous\n> behaviour. For potential new pci_enable_device() +\n> pcim_alloc_irq_vectors*() users before all the convertion is done, It's\n> indeed a problem here.\n\nThe thing is that I believe that this should be orthogonal.\n\n1. You'd keep the old functions exactly as they are now.\n\n2. Then, you add new pcim_irq_vector() et. al. functions. They won't\nneed any flag, because the managed state is stored by the devres\nbackend.\n\n3. You port a few users of the pcim_enable_device() + alloc_irq()\nfunction combination\n\n4. Once you have ported all of them, you can completely remove the\nis_managed flag and related devres functionality from the old\ninterfaces.\n\n\nI don't see why new code should interact with that flag mechanism. That\nseems incorrect to me. Can you explain to me why you think it's\nnecessary?\n\n\n> \n> Does something below make sense to you?\n> \n> int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int\n>                                      min_vecs, unsigned int max_vecs,\n>                                      unsigned int flags,\n>                                      struct irq_affinity *affd)\n> {\n> \tint nvecs;\n> \tbool already_set_msi_managed = dev->is_msi_managed;\n> \n> \tif (!already_set_msi_managed)\n> \t\tdev->is_msi_managed= true;\n> \n> \tnvecs = pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n> \t\t\t\t\t      flags, affd);\n> \tif (nvecs < 0 && !already_set_msi_managed)\n> \t\tdev->is_msi_managed = false;\n\nHmm, not sure. See above.\n\n\nP.\n\n> \n> \treturn nvecs;\n> }\n> \n> \n> Thanks.\n> \n> > (But I'm not super deep in PCI devres since many months; but I think I\n> > remember that not properly dealing with that flag state even caused us\n> > a bug or two in the past)\n> > \n> > \n> > Regards,\n> > Philipp\n> > \n> > > +\treturn pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n> > > +\t\t\t\t\t      flags, affd);\n> > > +}\n> > > +EXPORT_SYMBOL(pcim_alloc_irq_vectors_affinity);\n> > > +\n> > > +/**\n> > >    * pci_irq_vector() - Get Linux IRQ number of a device interrupt vector\n> > >    * @dev: the PCI device to operate on\n> > >    * @nr:  device-relative interrupt vector index (0-based); has different\n> > > diff --git a/include/linux/pci.h b/include/linux/pci.h\n> > > index 2c44545..3716c67 100644\n> > > --- a/include/linux/pci.h\n> > > +++ b/include/linux/pci.h\n> > > @@ -1770,6 +1770,12 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n> > >   \t\t\t\t   unsigned int max_vecs, unsigned int flags,\n> > >   \t\t\t\t   struct irq_affinity *affd);\n> > >   \n> > > +int pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n> > > +\t\t\t  unsigned int max_vecs, unsigned int flags);\n> > > +int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n> > > +\t\t\t\t   unsigned int max_vecs, unsigned int flags,\n> > > +\t\t\t\t   struct irq_affinity *affd);\n> > > +\n> > >   bool pci_msix_can_alloc_dyn(struct pci_dev *dev);\n> > >   struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,\n> > >   \t\t\t\t     const struct irq_affinity_desc *affdesc);\n> > > @@ -1812,6 +1818,22 @@ pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n> > >   \t\t\t\t\t      flags, NULL);\n> > >   }\n> > >   \n> > > +static inline int\n> > > +pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n> > > +\t\t\t       unsigned int max_vecs, unsigned int flags,\n> > > +\t\t\t       struct irq_affinity *aff_desc)\n> > > +{\n> > > +\treturn pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n> > > +\t\t\t\t\t      flags, aff_desc);\n> > > +}\n> > > +static inline int\n> > > +pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n> > > +\t\t      unsigned int max_vecs, unsigned int flags)\n> > > +{\n> > > +\treturn pcim_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n> > > +\t\t\t\t\t      flags, NULL);\n> > > +}\n> > > +\n> > >   static inline bool pci_msix_can_alloc_dyn(struct pci_dev *dev)\n> > >   { return false; }\n> > >   static inline struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,\n> > \n> >","headers":{"Return-Path":"\n ","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 (2048-bit key;\n secure) header.d=mailbox.org header.i=@mailbox.org header.a=rsa-sha256\n header.s=mail20150812 header.b=kQdVTgTf;\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-52765-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org\n header.b=\"kQdVTgTf\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=80.241.56.161","smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=mailbox.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=mailbox.org"],"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 4fzgK773vLz1yCv\n\tfor ; Mon, 20 Apr 2026 19:33:31 +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 F40AA306A80B\n\tfor ; Mon, 20 Apr 2026 09:29:11 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 0C0D2385513;\n\tMon, 20 Apr 2026 09:29:11 +0000 (UTC)","from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161])\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 E654438945C\n\tfor ; Mon, 20 Apr 2026 09:29:07 +0000 (UTC)","from smtp102.mailbox.org (smtp102.mailbox.org\n [IPv6:2001:67c:2050:b231:465::102])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby mout-p-103.mailbox.org (Postfix) with ESMTPS id 4fzgCz3rzCz9tnZ;\n\tMon, 20 Apr 2026 11:29:03 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776677350; cv=none;\n b=kTQD9R95ozM4FTOHJNDyy37wqN+mxmLFQqhlSsoNT7ppptjzVu6ral9aLt1fUfy1cCYGWu9LRp2LLqgFJhiHFsjb73QihIX5iqrgxS5Z6I554+NgBbtlWdhP/d0p63+KdLGt9pNkwu9N01GrpPOKfcuUc5wk42+97JFHMEct92E=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776677350; c=relaxed/simple;\n\tbh=x7TiyUkdDfYp1S/Vh1JCZvHLfeXfMofV3Sld/1PbEiw=;\n\th=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:\n\t Content-Type:MIME-Version;\n b=TGBq7/ws36kyv6CcX74GscsMt0thlEfoRiiZbnXEt9lnFmowXW/zOSXQzaOXnbT56eVLK8FjHmMqhau9Da9b/8+DqNcTG8Nv4Mhwd8xFmra4e+8a3TWV4IPLq1m+NxCoMWH7Akk0ESXZPiW0oQ3g97f9/7nsx8sQYtzqemcVCwE=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=mailbox.org;\n spf=pass smtp.mailfrom=mailbox.org;\n dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org\n header.b=kQdVTgTf; arc=none smtp.client-ip=80.241.56.161","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org;\n s=mail20150812;\n\tt=1776677343; h=from:from:reply-to:reply-to:subject:subject:date:date:\n\t message-id:message-id:to:to:cc:cc:mime-version:mime-version:\n\t content-type:content-type:\n\t content-transfer-encoding:content-transfer-encoding:\n\t in-reply-to:in-reply-to:references:references;\n\tbh=c6ErzniT0E1fKKEStO4sFTUK7zJLaixswSUKmn39sLg=;\n\tb=kQdVTgTfYIzb8WA+hbNVqhlX/vnvZVOgRB7o1iLN+fM83hbTXDMWLJow894H6CtuzF7wDF\n\toActyA7GCxm8U1zy+RhktRIJcEaSGCxk2vUrqsK+7UPB3RzFzwlOP9VBJ5KWsSHs7n3gF8\n\tqpAZf7cOUF+bqyamyOEC85F2ZltLeLFgFYHcfju7IZ1rlVi5fpj8ycmNLLw3UaG9V4g7N7\n\tiQCK+ND9yGQLEmdEupJvlJVbWD+8jOOioztrjFuumEyC4WxbqBND+obs4XKe9o+ZvySGHG\n\tq2ssEK9qGTr5Ro0ow3LHhMdtECWBPQvNtcL3Z2/L12/74/rNLi5xUm6/glzrIA==","Message-ID":"","Subject":"Re: [PATCH v2 1/3] PCI/MSI: Add Devres managed IRQ vectors\n allocation","From":"Philipp Stanner ","Reply-To":"phasta@kernel.org","To":"Shawn Lin , phasta@kernel.org","Cc":"Nirmal Patel , Jonathan Derrick\n , Kurt Schwemmer\n , Logan Gunthorpe ,\n linux-pci@vger.kernel.org, Bjorn Helgaas ","Date":"Mon, 20 Apr 2026 11:28:59 +0200","In-Reply-To":"","References":"<1776392767-83668-1-git-send-email-shawn.lin@rock-chips.com>\n\t <1776392767-83668-2-git-send-email-shawn.lin@rock-chips.com>\n\t \n\t ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","X-MBO-RS-ID":"49dd4ba7dec644f03b3","X-MBO-RS-META":"9ik4ykgo4wkt54xf5ywpaixa8es3cjpj"}},{"id":3679348,"web_url":"http://patchwork.ozlabs.org/comment/3679348/","msgid":"<37904506-71ad-4284-67a6-32135a8265a6@rock-chips.com>","list_archive_url":null,"date":"2026-04-20T09:52:07","subject":"Re: [PATCH v2 1/3] PCI/MSI: Add Devres managed IRQ vectors allocation","submitter":{"id":66993,"url":"http://patchwork.ozlabs.org/api/people/66993/","name":"Shawn Lin","email":"shawn.lin@rock-chips.com"},"content":"在 2026/04/20 星期一 17:28, Philipp Stanner 写道:\n> On Fri, 2026-04-17 at 17:33 +0800, Shawn Lin wrote:\n>> Hi Philipp\n>>\n>> 在 2026/04/17 星期五 16:44, Philipp Stanner 写道:\n>>> Hello Shawn,\n>>>\n>>> On Fri, 2026-04-17 at 10:26 +0800, Shawn Lin wrote:\n>>>> pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for\n>>>> pci device drivers which rely on the devres machinery to help cleanup the IRQ\n>>>> vectors.\n>>>\n>>> The commit message doesn't really detail *why* you add this. The rule\n>>> of thumb is to first describe the problem and then describe roughly\n>>> what the patch does about the problem. That also makes it easier for\n>>> reviewers to quickly match code to intent\n>>>\n>>\n>> Sure, will do.\n>>> `\n> \n> […]\n> \n>>>> +int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n>>>> +\t\t\t\t   unsigned int max_vecs, unsigned int flags,\n>>>> +\t\t\t\t   struct irq_affinity *affd)\n>>>> +{\n>>>> +\tdev->is_msi_managed = true;\n>>>\n>>> Do you have to set this to 'false' again? If so, who does that? A small\n>>> comment here could describe that.\n>>>\n>>>\n>>> Note that for your cleanup, in the long run, once all users are ported,\n>>> these helper bools should not be necessary anymore because devres\n>>> already stores all the relevant state.\n>>>\n>>> Likewise, I would like to remove the \"is_managed\" and \"is_pinned\"\n>>> flags, but that can only be done once all API users are ported.\n>>>\n>>> If this is the case with 'is_msi_managed', too, there should be a\n>>> cleanup TODO comment in my opinion. \"This can be removed once…\"\n>>>\n>>\n>> My initial plan was to make it into 3 steps:\n>> (1) Set is_msi_managed true via pcim_alloc_irq_vectors*();\n>> (2) All pcim_enable_device() + pci_alloc_irq_vectors*() users are ported\n>> (3) remove is_msi_managed assignment‌ from pcim_enable_device()\n>>\n>> As you could see, on step 1 & 2, pcim_enable_device() +\n>> pci_alloc_irq_vectors*() users uncondictionly set is_msi_managed true.\n> \n> pcim_enable_device() does not set that flag (if you meant that; I'm not\n> sure).\n> \n\nMy bad, I meant pcim_enable_device() sets is_managed, so\npcim_setup_msi_release() would skip the check of `if \n(!pci_is_managed(dev) || dev->is_msi_managed)`, thus is_msi_managed is \nset at the end.\n\n> The flag is already set by pcim_setup_msi_release(). Why do you need a\n> second place to set it?\n> \n>> So they don't have to set it false again. At least it keeps the previous\n>> behaviour. For potential new pci_enable_device() +\n>> pcim_alloc_irq_vectors*() users before all the convertion is done, It's\n>> indeed a problem here.\n> \n> The thing is that I believe that this should be orthogonal.\n> \n> 1. You'd keep the old functions exactly as they are now.\n> \n> 2. Then, you add new pcim_irq_vector() et. al. functions. They won't\n> need any flag, because the managed state is stored by the devres\n> backend.\n> \n> 3. You port a few users of the pcim_enable_device() + alloc_irq()\n> function combination\n> \n> 4. Once you have ported all of them, you can completely remove the\n> is_managed flag and related devres functionality from the old\n> interfaces.\n> \n> \n> I don't see why new code should interact with that flag mechanism. That\n> seems incorrect to me. Can you explain to me why you think it's\n> necessary?\n> \n> \n\nI was thinking if we need to unset the flag but thinking more about it,\nthe answer seems no, you're right, the devres backend manages it\nproperly.\n\nThanks, Philipp!\n\n>>\n>> Does something below make sense to you?\n>>\n>> int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int\n>>                                      min_vecs, unsigned int max_vecs,\n>>                                      unsigned int flags,\n>>                                      struct irq_affinity *affd)\n>> {\n>> \tint nvecs;\n>> \tbool already_set_msi_managed = dev->is_msi_managed;\n>>\n>> \tif (!already_set_msi_managed)\n>> \t\tdev->is_msi_managed= true;\n>>\n>> \tnvecs = pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n>> \t\t\t\t\t      flags, affd);\n>> \tif (nvecs < 0 && !already_set_msi_managed)\n>> \t\tdev->is_msi_managed = false;\n> \n> Hmm, not sure. See above.\n> \n> \n> P.\n> \n>>\n>> \treturn nvecs;\n>> }\n>>\n>>\n>> Thanks.\n>>\n>>> (But I'm not super deep in PCI devres since many months; but I think I\n>>> remember that not properly dealing with that flag state even caused us\n>>> a bug or two in the past)\n>>>\n>>>\n>>> Regards,\n>>> Philipp\n>>>\n>>>> +\treturn pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n>>>> +\t\t\t\t\t      flags, affd);\n>>>> +}\n>>>> +EXPORT_SYMBOL(pcim_alloc_irq_vectors_affinity);\n>>>> +\n>>>> +/**\n>>>>    * pci_irq_vector() - Get Linux IRQ number of a device interrupt vector\n>>>>    * @dev: the PCI device to operate on\n>>>>    * @nr:  device-relative interrupt vector index (0-based); has different\n>>>> diff --git a/include/linux/pci.h b/include/linux/pci.h\n>>>> index 2c44545..3716c67 100644\n>>>> --- a/include/linux/pci.h\n>>>> +++ b/include/linux/pci.h\n>>>> @@ -1770,6 +1770,12 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n>>>>   \t\t\t\t   unsigned int max_vecs, unsigned int flags,\n>>>>   \t\t\t\t   struct irq_affinity *affd);\n>>>> \n>>>> +int pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n>>>> +\t\t\t  unsigned int max_vecs, unsigned int flags);\n>>>> +int pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n>>>> +\t\t\t\t   unsigned int max_vecs, unsigned int flags,\n>>>> +\t\t\t\t   struct irq_affinity *affd);\n>>>> +\n>>>>   bool pci_msix_can_alloc_dyn(struct pci_dev *dev);\n>>>>   struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,\n>>>>   \t\t\t\t     const struct irq_affinity_desc *affdesc);\n>>>> @@ -1812,6 +1818,22 @@ pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n>>>>   \t\t\t\t\t      flags, NULL);\n>>>>   }\n>>>> \n>>>> +static inline int\n>>>> +pcim_alloc_irq_vectors_affinity(struct pci_dev *dev, unsigned int min_vecs,\n>>>> +\t\t\t       unsigned int max_vecs, unsigned int flags,\n>>>> +\t\t\t       struct irq_affinity *aff_desc)\n>>>> +{\n>>>> +\treturn pci_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n>>>> +\t\t\t\t\t      flags, aff_desc);\n>>>> +}\n>>>> +static inline int\n>>>> +pcim_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,\n>>>> +\t\t      unsigned int max_vecs, unsigned int flags)\n>>>> +{\n>>>> +\treturn pcim_alloc_irq_vectors_affinity(dev, min_vecs, max_vecs,\n>>>> +\t\t\t\t\t      flags, NULL);\n>>>> +}\n>>>> +\n>>>>   static inline bool pci_msix_can_alloc_dyn(struct pci_dev *dev)\n>>>>   { return false; }\n>>>>   static inline struct msi_map pci_msix_alloc_irq_at(struct pci_dev *dev, unsigned int index,\n>>>\n>>>\n> \n>","headers":{"Return-Path":"\n ","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=iqtLFLnP;\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-52768-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=\"iqtLFLnP\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=45.254.49.207","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 4fzhBn0VkHz1yGs\n\tfor ; Mon, 20 Apr 2026 20:13: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 9BC5030FE4A0\n\tfor ; Mon, 20 Apr 2026 10:07:39 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 768F63939C0;\n\tMon, 20 Apr 2026 10:07:39 +0000 (UTC)","from mail-m49207.qiye.163.com (mail-m49207.qiye.163.com\n [45.254.49.207])\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 DC11130EF95\n\tfor ; Mon, 20 Apr 2026 10:07:35 +0000 (UTC)","from [172.16.12.17] (unknown [58.22.7.114])\n\tby smtp.qiye.163.com (Hmail) with ESMTP id 3b641e2ae;\n\tMon, 20 Apr 2026 17:52:09 +0800 (GMT+08:00)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776679659; cv=none;\n b=DUP/O3MZ/7fsrm/K2u2cUee3rf4Hu3pAtiwCS2HiINsdPSyKKPAiaLAOL/fkdGQbnBnlBsypJ7EtAv/Q95xzlNrygFDryMCUHnhyLjp9LvnfSAI+pLFUIUtBf4+3gNNN1Sn8G+UMSdEFfbXYzIj8DXhGyTdR4w8gERfQ59Cvi1U=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776679659; c=relaxed/simple;\n\tbh=8tDeo6TW+INo9YjRfWa3uUVdlSdJmtEHYXLa8et7eD0=;\n\th=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From:\n\t In-Reply-To:Content-Type;\n b=jCAa4g+KYc1RsFAxaCux9NgKLsP2EGiyPz20PGIZaSbKiZspuKhbwatjO8gLkQbv5dOParNEVcjvxqhG5JGC21cBiWJkZLNOHy6YISSczkc0dhbeWuzrgw/5StfH+3tL09ox5JSHwwiAM6a0BjqGaWURpSySerQASHGJtNqMoy8=","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=iqtLFLnP; arc=none smtp.client-ip=45.254.49.207","Message-ID":"<37904506-71ad-4284-67a6-32135a8265a6@rock-chips.com>","Date":"Mon, 20 Apr 2026 17:52:07 +0800","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101\n Thunderbird/102.15.1","Cc":"shawn.lin@rock-chips.com, Nirmal Patel ,\n Jonathan Derrick ,\n Kurt Schwemmer ,\n Logan Gunthorpe , linux-pci@vger.kernel.org,\n Bjorn Helgaas ","Subject":"Re: [PATCH v2 1/3] PCI/MSI: Add Devres managed IRQ vectors allocation","To":"phasta@kernel.org","References":"<1776392767-83668-1-git-send-email-shawn.lin@rock-chips.com>\n <1776392767-83668-2-git-send-email-shawn.lin@rock-chips.com>\n \n \n ","From":"Shawn Lin ","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-HM-Tid":"0a9daa4df5c809cckunm46e6cb44722d77","X-HM-MType":"1","X-HM-Spam-Status":"e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly\n\ttZV1koWUFDSUNOT01LS0k3V1ktWUFJV1kPCRoVCBIfWUFZGRhDH1YaTxlDSEkaSx5PHk1WFRQJFh\n\toXVRMBExYaEhckFA4PWVdZGBILWUFZTkNVSUlVTFVKSk9ZV1kWGg8SFR0UWUFZT0tIVUpLSU9PT0\n\thVSktLVUpCS0tZBg++","DKIM-Signature":"a=rsa-sha256;\n\tb=iqtLFLnPURgd2Rljdl9TnEUnMNgr2GnRFA/fcinWMgegYEVQsMUkLK85+fd9D5EB/EGZKIT/x0qX3hg7cL8IoGx749XQu74VIdJUEqQO/6ZXQmbtxsxEUPlgybue3DY38cHZirEySetusvtLwwONj0pO2Rh6blt9r0fwRmJuJ4s=;\n c=relaxed/relaxed; s=default; d=rock-chips.com; v=1;\n\tbh=aeH2hX/T3o4AULp7NSrL9hApAeU3fPYzglKvcRpSDPs=;\n\th=date:mime-version:subject:message-id:from;"}}]