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

- From: Vladimir Oltean \<vladimir.oltean@nxp.com\>
- Date: 2026-01-23 15:10:55 
- List: netdev
- Page: https://ratatoskr.run/netdev/2026/01/3384584
- Thread: https://ratatoskr.run/netdev/2026/01/3381930/t.md

```text
On Fri, Jan 23, 2026 at 04:31:25PM +0200, Andy Shevchenko wrote:
> 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.

It is defined as

struct range {
	u64   start;
	u64   end;
};

So it could be used, but it still doesn't properly express the fact that
regmap takes unsigned int register offsets (which struct regmap_range does).
Furthermore, by using struct range you are coupling unrelated data types,
whereas by using struct regmap_range you are not (if the regmap_read()
prototype changes, the regmap_range field data types immediately follow
suit).
```