linux-kernel - Re: [PATCH] eth: 8139too: Make 8139TOO_PIO depend on !NO_IOPORT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250909181322.04dc2fed@kernel.org>
Date: Tue, 9 Sep 2025 18:13:22 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Daniel Palmer <daniel@...ngy.jp>
Cc: andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
 pabeni@...hat.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] eth: 8139too: Make 8139TOO_PIO depend on !NO_IOPORT_MAP

On Sun,  7 Sep 2025 15:43:49 +0900 Daniel Palmer wrote:
> 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.

Any idea if this is a regression, or the driver would have never worked
on your platform / config?