netdev - Re: [PATCH net-next 01/10] net: pcs: xpcs: move PCS reset to .pcs_pre

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: <68bc05c2-6904-4d33-866f-c828dde43dff@lunn.ch>
Date: Wed, 2 Oct 2024 00:09:22 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Serge Semin <fancer.lancer@...il.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Jiawen Wu <jiawenwu@...stnetic.com>,
	Jose Abreu <joabreu@...opsys.com>,
	Jose Abreu <Jose.Abreu@...opsys.com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-stm32@...md-mailman.stormreply.com,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Mengyuan Lou <mengyuanlou@...-swift.com>, netdev@...r.kernel.org,
	Paolo Abeni <pabeni@...hat.com>,
	Vladimir Oltean <olteanv@...il.com>
Subject: Re: [PATCH net-next 01/10] net: pcs: xpcs: move PCS reset to
 .pcs_pre_config()

> I'm wondering why we seem to be having a communication issue here.
> 
> I'm not sure which part of "keeping the functional changes to a
> minimum for a cleanup series" you're not understanding. This is
> one of the basics for kernel development... and given that you're
> effectively maintaining stmmac, it's something you _should_ know.
> 
> So no, I'm going to outright refuse to merge your patch in to this
> series, because as I see it, it would be wrong to do so. This is
> a _cleanup_ series, not a functional change series, and what you're
> proposing _changes_ the _way_ reset happens in this driver beyond
> the minimum that is required for this cleanup. It's introducing a
> completely _new_ way of writing to the devices registers to do
> the reset that's different.

I have to agree with Russell. Cleanups should be as simple as
possible, and hopefully obviously correct. They should be low risk.

Lets do all the simple cleanups first. Later we can consider more
invasive and risky changes.

	Andrew