Re: [RFC PATCH 08/11] PCI: Move CardBus device setup to setup-cardbus.c

[sashiko-bot@kernel.org]

> 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>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109210714.3862-1-ilpo.jarvinen@linux.intel.com?part=8