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: <289fa600-c722-48d7-bfb9-80ff31256cb5@lunn.ch>
Date: Mon, 16 Dec 2024 10:50:47 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <olteanv@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Mattias Forsblad <mattias.forsblad@...il.com>
Subject: Re: [PATCH 0/3] dsa: mv88e6xxx: Add RMU enable/disable ops

On Mon, Dec 16, 2024 at 12:59:10AM +0200, Vladimir Oltean wrote:
> Hi Andrew,
> 
> On Sun, Dec 15, 2024 at 05:30:02PM +0000, Andrew Lunn wrote:
> > Add internal APIs for enabling the Remote Management Unit, and
> > extending the existing implementation to other families. Actually
> > making use of the RMU is not included here, that will be part of a
> > later big patch set, which without this preliminary patchset would be
> > too big.
> > 
> > Signed-off-by: Andrew Lunn <andrew@...n.ch>
> > ---
> 
> How big is the later patch set? Too big to accept even one more patch?

The patchset is 21 patches, if i only support one switch family.

I can remove a couple of patches, getting statistics via RMU, and
timing the RMU vs MDIO and disabling RMU if it is slower.

The other way i can slice it is split it into two patchsets:

1) incremental modifications to qca8k to centralise code
2) implement the mv88e6xxx changes to add RMU to it.

I did not really want to slice it like this, because the central API
is designed around what both QCA8K and Marvell needs, and hopefully is
generic enough for other devices. But there might be questions asked
when you can only see the qca8k refactor without the Marvell parts.

I can maybe squash some of the QCA patches together. Previously i was
doing lots of simple changes because i did not have hardware to test
on. I do have a QCA8K test system now.

> There is a risk that the RMU effort gets abandoned before it becomes
> functional. And in that case, we will have a newly introduced rmu_enable()
> operation which does nothing.

True, but i'm more motivated this time, i'm getting paid for the work :-)

And there is one other interested party as well that i know of.

This patch series is fully self contained, so it easy to revert, if
this ends up going nowhere.

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ