mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	"Maciej W. Rozycki" <macro@orcam.me.uk>,
	linux-kernel@vger.kernel.org
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Dominik Brodowski" <linux@dominikbrodowski.net>,
	"Ulf Hansson" <ulfh@kernel.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	"Takashi Sakamoto" <o-takashi@sakamocchi.jp>,
	"Alex Dubov" <oakad@yahoo.com>,
	"Maxim Levitsky" <maximlevitsky@gmail.com>,
	linux-mmc@vger.kernel.org, linux1394-devel@lists.sourceforge.net
Subject: [RFC PATCH 08/11] PCI: Move CardBus device setup to setup-cardbus.c
Date: Mon,  9 Nov 2026 23:07:08 +0200	[thread overview]
Message-ID: <20261109210714.3862-9-ilpo.jarvinen@linux.intel.com> (raw)
In-Reply-To: <20261109210714.3862-1-ilpo.jarvinen@linux.intel.com>

CardBus support can be disabled with CONFIG_CARDBUS, but
pci_setup_device() still sets up CardBus bridges regardless of it. This
inconsistency leads to a few corner cases in the resource sizing and
assignment algorithm where CardBus bridges are treated like normal PCI
devices.

Move the CardBus-specific part of pci_setup_device() into
pci_setup_cardbus_device() in setup-cardbus.c and ignore CardBus bridges
when CARDBUS is not set.

If a CardBus bridge that is Function 0 of a Multi-Function Device is
ignored, pci_scan_slot() does not enumerate the other Functions either.
Without CARDBUS, this makes the other Functions of CardBus combo chips
unusable, e.g., the SD controller of the Ricoh RL5C476 (sdhci-pci), and
the FireWire (firewire-ohci), Flash Media (tifm_7xx1), and SD
(sdhci-pci) controllers of the TI PCIxx21. Making those drivers depend
on CARDBUS would force CardBus also on users of chips without CardBus,
e.g., the SD controller of the Ricoh R5C832 family, where Function 0 is
a FireWire controller.

CARDBUS defaults to y if CONFIG_PCCARD is enabled and the yenta_socket
driver (CONFIG_YENTA) selects it, so CARDBUS=n on hardware with a
CardBus slot is most likely an intentional choice. It seems reasonable
to require users with such an exceptional config to enable CARDBUS to
keep using the drivers above with this legacy hardware.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---

Cc: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Ulf Hansson <ulfh@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: Alex Dubov <oakad@yahoo.com>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: linux-mmc@vger.kernel.org
Cc: linux1394-devel@lists.sourceforge.net

 drivers/pci/pci.h           |  6 ++++++
 drivers/pci/probe.c         | 13 +++++++------
 drivers/pci/setup-cardbus.c | 13 +++++++++++++
 3 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 798b31c31ae4..057c8a2c7ee7 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -425,6 +425,7 @@ static inline bool pci_is_cardbus_bridge(const struct pci_dev *dev)
 }
 #ifdef CONFIG_CARDBUS
 unsigned long pci_cardbus_resource_alignment(const struct resource *res);
+int pci_setup_cardbus_device(struct pci_dev *dev);
 int pci_bus_size_cardbus_bridge(struct pci_bus *bus,
 				struct list_head *realloc_head);
 int pci_cardbus_scan_bridge_extend(struct pci_bus *bus, struct pci_dev *dev,
@@ -437,6 +438,10 @@ static inline unsigned long pci_cardbus_resource_alignment(const struct resource
 {
 	return 0;
 }
+static inline int pci_setup_cardbus_device(struct pci_dev *dev)
+{
+	return -EOPNOTSUPP;
+}
 static inline int pci_bus_size_cardbus_bridge(struct pci_bus *bus,
 					      struct list_head *realloc_head)
 {
@@ -528,6 +533,7 @@ bool pci_bus_generic_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *pl,
 					int rrs_timeout);
 
 int pci_setup_device(struct pci_dev *dev);
+void pci_read_irq(struct pci_dev *dev);
 void __pci_size_stdbars(struct pci_dev *dev, int count,
 			unsigned int pos, u32 *sizes);
 int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type,
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index a20ceaf7307a..f7afbaac723d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1599,7 +1599,7 @@ EXPORT_SYMBOL(pci_scan_bridge);
  * Read interrupt line and base address registers.
  * The architecture-dependent code can tweak these, of course.
  */
-static void pci_read_irq(struct pci_dev *dev)
+void pci_read_irq(struct pci_dev *dev)
 {
 	unsigned char irq;
 
@@ -2180,12 +2180,13 @@ int pci_setup_device(struct pci_dev *dev)
 		break;
 
 	case PCI_HEADER_TYPE_CARDBUS:		    /* CardBus bridge header */
-		if (class != PCI_CLASS_BRIDGE_CARDBUS)
+		err = pci_setup_cardbus_device(dev);
+		if (err == -EOPNOTSUPP) {
+			pci_err(dev, "CONFIG_CARDBUS not set, ignoring CardBus bridge\n");
+			goto free_name;
+		}
+		if (err)
 			goto bad;
-		pci_read_irq(dev);
-		pci_read_bases(dev, 1, 0);
-		pci_read_config_word(dev, PCI_CB_SUBSYSTEM_VENDOR_ID, &dev->subsystem_vendor);
-		pci_read_config_word(dev, PCI_CB_SUBSYSTEM_ID, &dev->subsystem_device);
 		break;
 
 	default:				    /* unknown header */
diff --git a/drivers/pci/setup-cardbus.c b/drivers/pci/setup-cardbus.c
index dcb8e2b3f73b..0de82d7fde68 100644
--- a/drivers/pci/setup-cardbus.c
+++ b/drivers/pci/setup-cardbus.c
@@ -31,6 +31,19 @@ unsigned long pci_cardbus_resource_alignment(const struct resource *res)
 	return 0;
 }
 
+int pci_setup_cardbus_device(struct pci_dev *dev)
+{
+	if (dev->class >> 8 != PCI_CLASS_BRIDGE_CARDBUS)
+		return -EIO;
+
+	pci_read_irq(dev);
+	pci_read_bases(dev, 1, 0);
+	pci_read_config_word(dev, PCI_CB_SUBSYSTEM_VENDOR_ID, &dev->subsystem_vendor);
+	pci_read_config_word(dev, PCI_CB_SUBSYSTEM_ID, &dev->subsystem_device);
+
+	return 0;
+}
+
 int pci_bus_size_cardbus_bridge(struct pci_bus *bus,
 				struct list_head *realloc_head)
 {
-- 
2.47.3


  parent reply	other threads:[~2026-11-09 21:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09 21:07 [PATCH 00/11] PCI/CardBus: Disable properly when CARDBUS=n & fix some issues along the way Ilpo Järvinen
2026-11-09 21:07 ` [PATCH 01/11] PCI: Free device name when pci_setup_device() fails Ilpo Järvinen
2026-11-09 21:07 ` [PATCH 02/11] PCI: Use Header Type in __pci_bridge_assign_resources() Ilpo Järvinen
2026-11-09 21:07 ` [PATCH 03/11] PCI: Use Header Type to detect CardBus bridges in pci_resource_alignment() Ilpo Järvinen
2026-11-09 21:07 ` [PATCH 04/11] PCI: Fix off-by-one in CardBus resource names Ilpo Järvinen
2026-11-09 21:07 ` [PATCH 05/11] PCI: Move pci_read_bases() wrapper with BUILD_BUG_ON() to pci.h Ilpo Järvinen
2026-11-09 21:07 ` [PATCH 06/11] mmc: sdricoh_cs: Depend on CARDBUS Ilpo Järvinen
2026-11-09 21:07 ` [RFC PATCH 07/11] pcmcia: yenta_socket: Always select CARDBUS Ilpo Järvinen
2026-11-09 21:07 ` Ilpo Järvinen [this message]
2026-11-09 21:07 ` [PATCH 09/11] PCI: Move CardBus legacy mode quirk to setup-cardbus.c Ilpo Järvinen
2026-11-09 21:07 ` [RFC PATCH 10/11] PCI: Move Ricoh RL5C476 MMC " Ilpo Järvinen
2026-11-09 21:07 ` [PATCH 11/11] PCI: Move CardBus resource names " Ilpo Järvinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261109210714.3862-9-ilpo.jarvinen@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=adrian.hunter@intel.com \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=linux@dominikbrodowski.net \
    --cc=macro@orcam.me.uk \
    --cc=maximlevitsky@gmail.com \
    --cc=o-takashi@sakamocchi.jp \
    --cc=oakad@yahoo.com \
    --cc=ulfh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®