From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0CD01F30A9; Tue, 24 Feb 2026 07:47:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771919278; cv=none; b=i/4pPouWo2soaLs0W/QfuACS9Hupqu4zFOkX3kkP3Tuzubct7tv5LgAq+U4k8T6RToeorjT0kMv4lP/28Rz85DtYEFBUlzugwStsQFRkOWoiSSr4wErgN/Xovn+QKPKHV0rdMhWyqGtjSjeoMPL6BHT88d/XamQAePULZ0jrbUo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771919278; c=relaxed/simple; bh=koOgKiE+v7OPLi9LKEtxHOf7GhOtRTctPuVlHDgVeRI=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=PqmP0Y9dxuV5Lr8RtLlQLvTftOa4Fwx19gfjN2jonzSC50Mf/G9iROw5aoNZZReWFAsrDRm+zvV//cBM1G0NmznJ7YH5//Sgi1x/JNJFZgXY88HIjJW7G6OEH7cv7b5a3tULIyGdqtGuqfx8OAy/gj+DFbvrHY+PU79kDBD9Jow= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=LlmbFV5R; arc=none smtp.client-ip=80.241.56.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="LlmbFV5R" Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4fKqZd0j7Gz9vf0; Tue, 24 Feb 2026 08:47:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1771919273; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YiLc2etffytjGPdDT50TNZbMLgAeU88xmrhfRIsoAkA=; b=LlmbFV5RBp7xLppev4EyLfGR9yk3NSgp4k97/ZE38v/+7SN+fag4e2NPTVd6MywwYB3JoR aECvO9Fv8AwXWQahEcQFmBMMy4oTTqbdSF7jsj3F9M1UASa8aCOGylBQ8PbGmnx3sEXV/X xDlA0T3Yg9VbnOrGzG3Cu09qiMv5luZknnr33IhnpKKS7SEYP5J27eOqGJ+BMoxD7b2D7e Wt4vHbFXLlArdA5ZAkztt7B6Zdjf3OctDzSWL+lDFIhoAe+dqsoo1LXHEJMGvF4BGO1wuN FQvXuKvtRw6f680NUsqMBFFFC2kPPw/EMsvBpkdP95ooRBk0Xv0qmfZ7x7GZHA== Message-ID: <07fc896007d86b731cbfb3cf6bbdf4e5315d7a77.camel@mailbox.org> Subject: Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation From: Philipp Stanner Reply-To: phasta@kernel.org To: Shawn Lin , Jakub Kicinski Cc: Bjorn Helgaas , "Vaibhaav Ram T . L" , Kumaravel Thiagarajan , Even Xu , Xinpeng Sun , Srinivas Pandruvada , Jiri Kosina , Alexandre Belloni , Zhou Wang , Longfang Liu , Vinod Koul , Lee Jones , Jijie Shao , Jian Shen , Sunil Goutham , Andrew Lunn , Heiner Kallweit , "David S . Miller" , Jeff Hugo , Oded Gabbay , Maciej Falkowski , Karol Wachowski , Min Ma , Lizhi Hou , Andreas Noever , Mika Westerberg , Tomasz Jeznach , Will Deacon , Xinliang Liu , Tian Tao , Davidlohr Bueso , Jonathan Cameron , Srujana Challa , Bharat Bhushan , Antoine Tenart , Herbert Xu , Raag Jadav , Hans de Goede , Greg Kroah-Hartman , Jiri Slaby , Andy Shevchenko , Manivannan Sadhasivam , Mika Westerberg , Andi Shyti , Robert Richter , Mark Brown , Nirmal Patel , Kurt Schwemmer , Logan Gunthorpe , Linus Walleij , Bartosz Golaszewski , Sakari Ailus , Bingbu Cao , Ulf Hansson , Arnd Bergmann , Benjamin Tissoires , linux-input@vger.kernel.org, linux-i3c@lists.infradead.org, dmaengine@vger.kernel.org, Philipp Stanner , netdev@vger.kernel.org, nic_swsd@realtek.com, linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-usb@vger.kernel.org, iommu@lists.linux.dev, linux-riscv@lists.infradead.org, David Airlie , Simona Vetter , linux-cxl@vger.kernel.org, linux-crypto@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-serial@vger.kernel.org, mhi@lists.linux.dev, Andy Shevchenko , Jan Dabros , linux-i2c@vger.kernel.org, Daniel Mack , Haojian Zhuang , linux-spi@vger.kernel.org, Jonathan Derrick , linux-pci@vger.kernel.org, linux-gpio@vger.kernel.org, Mauro Carvalho Chehab , linux-media@vger.kernel.org, linux-mmc@vger.kernel.org Date: Tue, 24 Feb 2026 08:47:28 +0100 In-Reply-To: References: <1771860581-82092-1-git-send-email-shawn.lin@rock-chips.com> <1771860581-82092-2-git-send-email-shawn.lin@rock-chips.com> <20260223160402.3ad8f079@kernel.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MBO-RS-ID: e66ae4685546ea4d94e X-MBO-RS-META: 6frywx3ts6ez4nj3bodhgna5o111q4gn On Tue, 2026-02-24 at 10:08 +0800, Shawn Lin wrote: > =E5=9C=A8 2026/02/24 =E6=98=9F=E6=9C=9F=E4=BA=8C 8:04, Jakub Kicinski =E5= =86=99=E9=81=93: > > On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote: > > > pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are cr= eated for > > > pci device drivers which rely on the devres machinery to help cleanup= the IRQ > > > vectors. > >=20 > > If you can please add this API with just a few users, and then convert > > remaining users via the subsystem trees in the next cycle. > > There's no need to risk wasting maintainer time on conflicts with > > conversions like this. >=20 > Thanks for the suggestion, Jakub. I have little experience with=20 > cross-subsystem cleanups like this, so your suggestion is very helpful. When I removed the hybrid nature of pci_request_region() et al., I concluded that there were so few users that doing them all in one run was sufficient. For larger reworks, like removing pcim_iomap_table(), a slower step-by- step strategy is necessary for the reasons that Jakub details. It is then smart to omit an easy to port subsystem / driver for the ultimate patch series where one then removes the hybrid behavior from PCI itself, after porting the last driver. In general, as Jakub details, those step-by-step cleanups are a bit safer, since you can proof valid behavior early on and in case of an explosion they are very easy to revert. P.