linux-kernel - Re: [PATCH] net: stmmac: Allow zero for [tr]x_fifo

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: <f728a006-e588-4eab-b667-b1ff7dfd66c5@linux.dev>
Date: Wed, 5 Feb 2025 22:22:00 +0800
From: Yanteng Si <si.yanteng@...ux.dev>
To: Jakub Kicinski <kuba@...nel.org>,
 "Russell King (Oracle)" <linux@...linux.org.uk>,
 Steven Price <steven.price@....com>
Cc: Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
 "David S. Miller" <davem@...emloft.net>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Andrew Lunn <andrew+netdev@...n.ch>, Eric Dumazet <edumazet@...gle.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Jose Abreu <joabreu@...opsys.com>, Paolo Abeni <pabeni@...hat.com>,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com, netdev@...r.kernel.org,
 Furong Xu <0x1207@...il.com>, Petr Tesarik <petr@...arici.cz>,
 Serge Semin <fancer.lancer@...il.com>, Xi Ruoyao <xry111@...111.site>
Subject: Re: [PATCH] net: stmmac: Allow zero for [tr]x_fifo_size

在 2/4/25 06:23, Jakub Kicinski 写道:
> On Mon, 3 Feb 2025 11:16:34 +0000 Russell King (Oracle) wrote:
>>> I've no opinion whether the original series "had value" - I'm just
>>> trying to fix the breakage that entailed. My first attempt at a patch
>>> was indeed a (partial) revert, but Andrew was keen to find a better
>>> solution[1].
>> There are two ways to fix the breakage - either revert the original
>> patches (which if they have little value now would be the sensible
>> approach IMHO)
> +1, I also vote revert FWIW

+1, same here.

For a driver that runs on so much hardware, we need to act

cautiously. A crucial prerequisite is that code changes must

never cause some hardware to malfunction. I was too simplistic

in my thinking when reviewing this before, and I sincerely

apologize for that.

Steven, thank you for your tests, Let's revert it.

Thanks,

Yanteng