From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 0E6A018A943 for ; Wed, 9 Oct 2024 08:36:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728463004; cv=none; b=tTE5Dmz6Rw1b8oMoEtp++QqgndXzddUiGPeziLr/PgJiCFWMF56v0hM25PVoAKHdh5NDVD+HkL05W//fhV+3bjpHWDDfuJTFM9faeqk/0cQFzzaVpfdCFpQexeVuQCTcgvRD1W0obXF40+zKiLifCdXEIlSKgf2PCFBdbzJCNcI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728463004; c=relaxed/simple; bh=bwupmCthuGaQS+qMZ/7SrXy7Oyd/5BoNqSfbGXSX0bk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=StR6cVkM+ZBbUMEs0Z3rO8FcJ7CvtCmyzP0qhHsO0fXkMp5bbYgNWg0TeFB8jFvCLtz3pfuHpkKKiL+9MC4W0yUAFr0T9ef1zvMbSnWzmbxWcWcTEDc0UbmPkHWMEa3o5bdYFsNQmSWLMWuJv7uVi65iShme5Q5uZtZwZ9MKdhM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=dlcKQg3a; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="dlcKQg3a" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1728463001; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=mOyNV1blUkGi8SBN/l2nmGqTH8tAJ4tec1wRLOcI2Z8=; b=dlcKQg3a8m+Ov6dKMeyzaVgzv5GTg/ltRgXo6J2rEa/VbSXMTlOF36tYdo4ROEvCY6DTnH pmlsL6Ol4Q95DfEcPMvKsk4hgHB4hb+Tgt7AjwR3orCVzVmQqdlSbSC7oIE2Ll0ZJHFSiU A2cJiEeFaoC2Ro2OAOXoC43KMkpb6C4= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-620-tFbzLo45PZmMX_pkem0Hag-1; Wed, 09 Oct 2024 04:36:40 -0400 X-MC-Unique: tFbzLo45PZmMX_pkem0Hag-1 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-7afcea583caso144925085a.2 for ; Wed, 09 Oct 2024 01:36:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728462999; x=1729067799; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mOyNV1blUkGi8SBN/l2nmGqTH8tAJ4tec1wRLOcI2Z8=; b=aLnqkemD+GOv/KTwDk/w1auYZOpK0hVaucibAiQT+fjrrq8cWtVwlVt5NwcW0L/hci GN39UeBzTLnJvE+H5A9ACDtlPvnMqtiP7i2rBJ0pSkEAG8H/74hlPdBp933lZctXSL9i XZ3iCk4jtqm8RQZtf+7g+qf5qZGFmXhlQQQ07oINwaDD6eg8gwAWHra5JlG3yRoPntEU ckk26173UOpBpfpsNU9iskxz2hhzlR/NxszQfyi8z2zNuyCFk/40wA2/HvNuFxTNsj0A M25ruKlAIDsebltOr318y0K1QvnwbiCD2MTIfTS99oC02w/YZnpWCydsJ2OhkdFf5pYb /xTA== X-Gm-Message-State: AOJu0YzCio7gJ151Yekiws0OqtERMhy7Ot6HZXzyogVUdwuAlAHqnHIm xE2bpPGmZMe5U+9zYz9gLE9YtP3XMg0NJ6Fb1ODvNtrhjdE56RNFxuzkkJL5tYlSxPLuNFRJMQW hTBZZZibTYKtdsIV4uDr9cZDfxtV727j25EXtzlS9D62PgiTMG9UQuvfARg== X-Received: by 2002:a05:620a:29c7:b0:7a2:1db:e286 with SMTP id af79cd13be357-7b0874cd670mr234482385a.52.1728462999261; Wed, 09 Oct 2024 01:36:39 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFU56nfNbRn4xRa9L06f5Bja7V/qokH03xrDBZWS39o5ckdxWurQft3H7j0iSjtDvnBZDt4+Q== X-Received: by 2002:a05:620a:29c7:b0:7a2:1db:e286 with SMTP id af79cd13be357-7b0874cd670mr234479185a.52.1728462998841; Wed, 09 Oct 2024 01:36:38 -0700 (PDT) Received: from eisenberg.redhat.com (nat-pool-muc-t.redhat.com. [149.14.88.26]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7ae75615aa2sm439643585a.14.2024.10.09.01.36.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Oct 2024 01:36:38 -0700 (PDT) From: Philipp Stanner To: Damien Le Moal , Niklas Cassel , Sergey Shtylyov , Basavaraj Natikar , Jiri Kosina , Benjamin Tissoires , Arnd Bergmann , Greg Kroah-Hartman , Alex Dubov , Sudarsana Kalluru , Manish Chopra , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rasesh Mody , GR-Linux-NIC-Dev@marvell.com, Igor Mitsyanko , Sergey Matyukevich , Kalle Valo , Sanjay R Mehta , Shyam Sundar S K , Jon Mason , Dave Jiang , Allen Hubbe , Bjorn Helgaas , Alex Williamson , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Jaroslav Kysela , Takashi Iwai , Philipp Stanner , Mario Limonciello , Chen Ni , Ricky Wu , Al Viro , Breno Leitao , Kevin Tian , Thomas Gleixner , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , Mostafa Saleh , Andy Shevchenko , Hannes Reinecke , John Garry , Soumya Negi , Jason Gunthorpe , Yi Liu , "Dr. David Alan Gilbert" , Christian Brauner , Ankit Agrawal , Reinette Chatre , Eric Auger , Ye Bin , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Pierre-Louis Bossart , Maarten Lankhorst , Kai Vehmanen , Peter Ujfalusi , Rui Salvaterra , Marc Zyngier Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, ntb@lists.linux.dev, linux-pci@vger.kernel.org, linux-staging@lists.linux.dev, kvm@vger.kernel.org, xen-devel@lists.xenproject.org, linux-sound@vger.kernel.org Subject: [RFC PATCH 00/13] Remove implicit devres from pci_intx() Date: Wed, 9 Oct 2024 10:35:06 +0200 Message-ID: <20241009083519.10088-1-pstanner@redhat.com> X-Mailer: git-send-email 2.46.1 Precedence: bulk X-Mailing-List: linux-ide@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi all, this series removes a problematic feature from pci_intx(). That function sometimes implicitly uses devres for automatic cleanup. We should get rid of this implicit behavior. To do so, a pci_intx() version that is always-managed, and one that is never-managed are provided. Then, all pci_intx() users are ported to the version they need. Afterwards, pci_intx() can be cleaned up and the users of the never-managed version be ported back to pci_intx(). This way we'd get this PCI API consistent again. The last patch obviously reverts the previous patches that made drivers use pci_intx_unmanaged(). But this way it's easier to review and approve. It also makes sure that each checked out commit should provide correct behavior, not just the entire series as a whole. Merge plan for this would be to enter through the PCI tree. Please say so if you've got concerns with the general idea behind the RFC. Regards, P. Philipp Stanner (13): PCI: Prepare removing devres from pci_intx() ALSA: hda: hda_intel: Use always-managed version of pcim_intx() drivers/xen: Use never-managed version of pci_intx() net/ethernet: Use never-managed version of pci_intx() net/ntb: Use never-managed version of pci_intx() misc: Use never-managed version of pci_intx() vfio/pci: Use never-managed version of pci_intx() PCI: MSI: Use never-managed version of pci_intx() ata: Use always-managed version of pci_intx() staging: rts5280: Use always-managed version of pci_intx() wifi: qtnfmac: use always-managed version of pcim_intx() HID: amd_sfh: Use always-managed version of pcim_intx() Remove devres from pci_intx() drivers/ata/ahci.c | 2 +- drivers/ata/ata_piix.c | 2 +- drivers/ata/pata_rdc.c | 2 +- drivers/ata/sata_sil24.c | 2 +- drivers/ata/sata_sis.c | 2 +- drivers/ata/sata_uli.c | 2 +- drivers/ata/sata_vsc.c | 2 +- drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 4 ++-- drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c | 2 +- .../wireless/quantenna/qtnfmac/pcie/pcie.c | 2 +- drivers/pci/devres.c | 24 +++---------------- drivers/pci/pci.c | 14 +---------- drivers/staging/rts5208/rtsx.c | 2 +- include/linux/pci.h | 1 + sound/pci/hda/hda_intel.c | 2 +- 15 files changed, 18 insertions(+), 47 deletions(-) -- 2.46.1