linux-kernel - Re: [PATCH net-next 02/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: <942f62f9-4c79-4c35-ad03-40bf7c6111b4@bootlin.com>
Date: Thu, 20 Nov 2025 15:35:07 +0100
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org
Cc: 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, Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH net-next 02/15] net: mdio-regmap: permit working with
 non-MMIO regmaps

Hi Vladimir,

On 18/11/2025 20:05, Vladimir Oltean wrote:
> The regmap world is seemingly split into two groups which attempt to
> solve different problems. Effectively, this means that not all regmap
> providers are compatible with all regmap consumers.
> 
> First, we have the group where the current mdio-regmap users fit:
> altera_tse_main.c and dwmac-socfpga.c use devm_regmap_init_mmio() to
> ioremap their pcs_base and obtain a regmap where address zero is the
> first PCS register.
> 
> Second, we have the group where MFD parent drivers call
> mfd_add_devices(), having previously initialized a non-MMIO (SPI, I2C)
> regmap and added it to their devres list, and MFD child drivers use
> dev_get_regmap(dev->parent, NULL) in their probe function, to find the
> first (and single) regmap of the MFD parent. The address zero of this
> regmap is global to the entire parent, so the children need to be
> parent-aware and add their own offsets for the registers that they
> should manage.
> 
> This is essentially because MFD is seemingly coming from a world where
> peripheral registers are all entangled with each other, but what I'm
> trying to support via MFD are potentially multiple instances of the same
> kind of device, at well separated address space regions.
> 
> To use MFD but provide isolated regmaps for each child device would
> essentially mean to fight against the system. The problem that needs to
> be now solved is that each child device needs to find the correct
> regmap, which means that "dev_get_regmap(dev->parent, NULL)" transforms
> either in:
> - dev_get_regmap(dev, NULL): search in the child device's devres list,
>   not in the parent's. But MFD does not give us a hook in between
>   platform_device_alloc() and platform_device_add() where we could make
>   the devm_regmap_init_spi() call for the child device. We have to make
>   it for the parent.
> - dev_get_regmap(dev->parent, "unique-regmap-name"): now the child
>   device needs to know, in case there are multiple instances of it,
>   which one is it, to ask for the right one. I've seen
>   drivers/mfd/ocelot-core.c work around this rather elegantly, providing
>   a resource to the child, and then the child uses resource->name to
>   find the regmap of the same name in the parent. But then I also
>   stumbled upon drivers/net/pcs/pcs-xpcs-plat.c which I need to support
>   as an MFD child, and that superimposes its own naming scheme for the
>   resources: "direct" or "indirect" - scheme which is obviously
>   incompatible with namespacing per instance.
> 
> So a MFD parent needs to decide whether it is in the boat that provides
> one isolated regmap for each child, or one big regmap for all. The "one
> big regmap" is the lowest common denominator when considering children
> like pcs-xpcs-plat.c.
> 
> This means that from mdio-regmap's perspective, it needs to deal with
> regmaps coming from both kinds of providers, as neither of them is going
> away.
> 
> Users who provide a big regmap but want to access only a window into it
> should provide as a struct mdio_regmap_config field a resource that
> describes the start and end of that window. Currently we only use the
> start as an offset into the regmap, and hope that MDIO reads and writes
> won't go past the end.
> 
> Cc: Mark Brown <broonie@...nel.org>
> Cc: Maxime Chevallier <maxime.chevallier@...tlin.com>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

That sounds good to me ! Thanks for expanding this driver :) I agree
with keeping the entire resource instead of just 'start'.

Reviewed-by: Maxime Chevallier <maxime.chevallier@...tlin.com>

Maxime