From: Daniel Palmer daniel@thingy.jp
[ Upstream commit 43adad382e1fdecabd2c4cd2bea777ef4ce4109e ]
When 8139too is probing and 8139TOO_PIO=y it will call pci_iomap_range() and from there __pci_ioport_map() for the PCI IO space. If HAS_IOPORT_MAP=n and NO_GENERIC_PCI_IOPORT_MAP=n, like it is on my m68k config, __pci_ioport_map() becomes NULL, pci_iomap_range() will always fail and the driver will complain it couldn't map the PIO space and return an error.
NO_IOPORT_MAP seems to cover the case where what 8139too is trying to do cannot ever work so make 8139TOO_PIO depend on being it false and avoid creating an unusable driver.
Signed-off-by: Daniel Palmer daniel@thingy.jp Link: https://patch.msgid.link/20250907064349.3427600-1-daniel@thingy.jp Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES
- What it fixes - With `CONFIG_8139TOO_PIO=y`, the driver prefers mapping the I/O port BAR via `pci_iomap()` in `rtl8139_init_board()` and errors out if it fails, without falling back from a PIO failure: - Mapping call and failure path: drivers/net/ethernet/realtek/8139too.c:754 - `pci_iomap()` delegates to `pci_iomap_range()` which uses `__pci_ioport_map()` for IO BARs: drivers/pci/iomap.c:29 and drivers/pci/iomap.c:51 - On architectures where `CONFIG_HAS_IOPORT_MAP=n` and `CONFIG_NO_GENERIC_PCI_IOPORT_MAP=n`, `__pci_ioport_map()` is a NULL macro, making IO BAR mapping always fail: include/asm- generic/pci_iomap.h:28 - Result: driver logs “cannot map PIO” and returns `-ENODEV` when PIO is selected (no fallback from a PIO failure), making the driver unusable on those platforms.
- What the change does - Kconfig change: `8139TOO_PIO` now depends on `!NO_IOPORT_MAP` so the PIO option is hidden when the architecture declares no I/O-port mapping at all: - Changed line: drivers/net/ethernet/realtek/Kconfig:61 - This avoids creating an impossible configuration (PIO on platforms that cannot map PCI IO space), ensuring the driver uses the MMIO path instead (which is the default when `CONFIG_8139TOO_PIO` is not set).
- Why it’s a good stable candidate - Bug impact: Prevents a user-facing driver init failure (unusable NIC) on several architectures (e.g., m68k, arm64, etc.) that set `NO_IOPORT_MAP` or otherwise disable I/O port mapping. - Scope: One-line Kconfig dependency change; no code or architectural changes. - Risk: Minimal. On platforms with I/O port mapping, behavior is unchanged. On platforms without it, the broken PIO option is simply not selectable, and the driver will use MMIO. - Compatibility: On older stable trees lacking `NO_IOPORT_MAP`, the dependency becomes a no-op (`!NO_IOPORT_MAP` evaluates true if undefined), so it won’t break Kconfig.
- Technical linkage to the failure - `pci_iomap_range()` returns `__pci_ioport_map()` for IO BARs: drivers/pci/iomap.c:51 - `__pci_ioport_map()` is NULL when `!CONFIG_HAS_IOPORT_MAP && !CONFIG_NO_GENERIC_PCI_IOPORT_MAP`: include/asm- generic/pci_iomap.h:28 - 8139too sets `bar = !use_io;` so when PIO is selected it maps the IO BAR first and fails without PIO→MMIO fallback: drivers/net/ethernet/realtek/8139too.c:754
Given this is a small, contained Kconfig fix preventing an unusable configuration and enabling a working MMIO fallback, it fits stable backport criteria.
drivers/net/ethernet/realtek/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/Kconfig b/drivers/net/ethernet/realtek/Kconfig index fe136f61586fe..272c83bfdc6ce 100644 --- a/drivers/net/ethernet/realtek/Kconfig +++ b/drivers/net/ethernet/realtek/Kconfig @@ -58,7 +58,7 @@ config 8139TOO config 8139TOO_PIO bool "Use PIO instead of MMIO" default y - depends on 8139TOO + depends on 8139TOO && !NO_IOPORT_MAP help This instructs the driver to use programmed I/O ports (PIO) instead of PCI shared memory (MMIO). This can possibly solve some problems