netdev - Re: [PATCH v2 net-next 01/15] net: mdio-regmap: permit working with non-MMIO regmaps

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: <aXOGPUP5pfGeAQKN@smile.fi.intel.com>
Date: Fri, 23 Jan 2026 16:31:25 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	linux-kernel@...r.kernel.org,
	Herve Codina <herve.codina@...tlin.com>,
	Mark Brown <broonie@...nel.org>,
	Serge Semin <fancer.lancer@...il.com>,
	Maxime Chevallier <maxime.chevallier@...tlin.com>,
	Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org,
	Jiawen Wu <jiawenwu@...stnetic.com>
Subject: Re: [PATCH v2 net-next 01/15] net: mdio-regmap: permit working with
 non-MMIO regmaps

On Fri, Jan 23, 2026 at 03:55:01PM +0200, Vladimir Oltean wrote:
> On Fri, Jan 23, 2026 at 02:15:29PM +0200, Vladimir Oltean wrote:

...

> A data structure which I find a bit under-utilized in the kernel is
> 
> /**
>  * struct regmap_range - A register range, used for access related checks
>  *                       (readable/writeable/volatile/precious checks)
>  *
>  * @range_min: address of first register
>  * @range_max: address of last register
>  */
> struct regmap_range {
> 	unsigned int range_min;
> 	unsigned int range_max;
> };

Not sure. See below.

> I could imagine a helper like:
> 
> /* Type adaptation between phy_addr_t and unsigned int */
> static inline int __must_check regmap_range_from_resource(const struct resource *res,
> 							  struct regmap_range *range)
> {
> 	struct resource r4g = DEFINE_RES(0, SZ_4G, res->flags);
> 
> 	if (res->flags != IORESOURCE_REG) {
> 		pr_err("%s should be used only with IORESOURCE_REG resources\n");
> 		return -EINVAL;
> 	}
> 
> 	if (!resource_contains(&r4g, res)) {
> 		pr_err("Resource exceeds regmap API addressing possibilities\n");

%pR

> 		return -EINVAL;
> 	}
> 
> 	range->range_min = res->start;
> 	range->range_max = res->end;
> 
> 	return 0;
> }
> 
> and then proceed to use the simpler and validated regmap_range structure in the driver.
> Too bad such use is not an established coding pattern...

Dunno about semantics, as I only saw the use of that in regard to the special
slices of regmap.

Also we have struct range in range.h. Maybe that one suits better? It has also
some interesting APIs.

-- 
With Best Regards,
Andy Shevchenko