linux-kernel - Re: [net-next PATCH v11 5/9] mfd: an8855: Add support for Airoha AN8855 Switch MFD

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: <20241210234803.pzm7fxrve4dastth@skbuf>
Date: Wed, 11 Dec 2024 01:48:03 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	upstream@...oha.com
Subject: Re: [net-next PATCH v11 5/9] mfd: an8855: Add support for Airoha
 AN8855 Switch MFD

On Tue, Dec 10, 2024 at 11:32:17PM +0100, Christian Marangi wrote:
> Doesn't regmap add lots of overhead tho? Maybe I should really change
> the switch regmap to apply a save/restore logic?
> 
> With an implementation like that current_page is not needed anymore.
> And I feel additional read/write are ok for switch OP.
> 
> On mdio I can use the parent-mdio-bus property to get the bus directly
> without using MFD priv.
> 
> What do you think?

If performance is a relevant factor at all, it will be hard to measure it, other
than with synthetic tests (various mixes of switch and PHY register access).
Though since you mention it, it would be interesting to see a comparison of the
3 arbitration methods. This could probably be all done from the an8855_mfd_probe()
calling context: read a switch register and a PHY register 100K times and see how
long it took, then read 2 switch registers and a PHY register 100K times, then
3 switch registers.... At some point, we should start seeing the penalty of the
page restoration in Andrew's proposal, because that will be done after each switch
register read. Just curious to put it into perspective and see how soon it starts
to make a difference. And this test will also answer the regmap overhead issue.