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

- From: Andy Shevchenko \<andriy.shevchenko@linux.intel.com\>
- Date: 2026-01-23 15:39:13 
- List: netdev
- Page: https://ratatoskr.run/netdev/2026/01/3384622
- Thread: https://ratatoskr.run/netdev/2026/01/3381930/t.md

```text
On Fri, Jan 23, 2026 at 05:10:49PM +0200, Vladimir Oltean wrote:
> 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).

I'm fine with regmap_range, but I'm not a regmap maintainer.

-- 
With Best Regards,
Andy Shevchenko


```