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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ac319cf8-5501-40f2-bf23-fc04a91d4f1f@socionext.com>
Date: Thu, 6 Feb 2025 16:05:39 +0900
From: Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
 Yanteng Si <si.yanteng@...ux.dev>
Cc: Jakub Kicinski <kuba@...nel.org>, Steven Price <steven.price@....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

Hi Russell,

On 2025/02/05 23:39, Russell King (Oracle) wrote:
> On Wed, Feb 05, 2025 at 10:22:00PM +0800, Yanteng Si wrote:
>>
>> 在 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.
> 
> https://lore.kernel.org/r/E1tfeyR-003YGJ-Gb@rmk-PC.armlinux.org.uk

I'm sorry to bother you. Thanks for posting revert.

There are variations in the capabilities that the hardware has, and more
hardware needs to be verified to show that they work correctly, so it had
to be handled carefully. Reports that the change patch "worked" or
"didn't work" on any hardware are helpful.

I apologize that posting this change to "-net" was inappropriate
because I added a completely new feature.

Thank you,

---
Best Regards
Kunihiko Hayashi