netdev - Re: [PATCHv3 net-next] net: modernize ioremap in probe

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Zz0h4pMXn6KzRViL@shell.armlinux.org.uk>
Date: Tue, 19 Nov 2024 23:40:18 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Niklas Söderlund <niklas.soderlund@...natech.se>
Cc: Rosen Penev <rosenp@...il.com>, netdev@...r.kernel.org,
	Kurt Kanzenbach <kurt@...utronix.de>, Andrew Lunn <andrew@...n.ch>,
	Vladimir Oltean <olteanv@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Chris Snook <chris.snook@...il.com>,
	Marcin Wojtas <marcin.s.wojtas@...il.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Richard Cochran <richardcochran@...il.com>,
	open list <linux-kernel@...r.kernel.org>,
	"open list:RENESAS ETHERNET SWITCH DRIVER" <linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCHv3 net-next] net: modernize ioremap in probe

On Tue, Nov 19, 2024 at 09:39:16PM +0100, Niklas Söderlund wrote:
> On 2024-11-17 15:07:53 -0800, Rosen Penev wrote:
> > devm_platform_ioremap_resource_byname has no res parameter, which is a
> > problem as there's this lovely line below it.
> > 
> > ndev->base_addr = res->start;
> 
> I see, maybe we can refactor that too? I see not all drivers set 
> base_addr, and some even set it to the remapped memory returned by 
> devm_platform_ioremap_resource_byname() or such.

base_addr carries with it an issue that setting it on every driver is
likely not a good idea.

Namely, that it's "unsigned long", it's reported to userspace, and
on PAE systems, unsigned long is 32-bit but the device address may
be >32-bit.

I haven't checked the user APIs, whether that restricts it to 32-bit
on 32-bit systems.

In any case, whether base_addr is set or not is probably best left
as-is and not have some "we must always / never set base_addr" rule
applied to it.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!