linux-kernel - Re: [PATCH] net: dsa: mt7530: disable LEDs before reset

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]

Date: Tue, 12 Mar 2024 14:21:37 +0300
From: Arınç ÜNAL <arinc.unal@...nc9.com>
To: Paolo Abeni <pabeni@...hat.com>, patchwork-bot+netdevbpf@...nel.org,
 Justin Swartz <justin.swartz@...ingedge.co.za>
Cc: daniel@...rotopia.org, dqfext@...il.com, sean.wang@...iatek.com,
 andrew@...n.ch, f.fainelli@...il.com, olteanv@...il.com,
 davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 matthias.bgg@...il.com, angelogioacchino.delregno@...labora.com,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH] net: dsa: mt7530: disable LEDs before reset

On 12.03.2024 13:46, Paolo Abeni wrote:
> On Tue, 2024-03-12 at 11:38 +0300, Arınç ÜNAL wrote:
>> I am once again calling for this patch to be reverted on the net-next tree
>> on the basis of:
>>
>> - This patch did not go through a proper reviewing process. There are
>>     proposed changes on the code it changes regarding the scope and the
>>     method of the patch, and improvements to be made on the patch log.
>>
>> - This patch should be backported to stable releases, therefore it
>>     shouldn't be on the net-next tree and should be submitted to the net tree
>>     instead.
> 
> The net-next pull request is out:
> 
> https://lore.kernel.org/netdev/20240312042504.1835743-1-kuba@kernel.org/
> 
> at this point I believe we can't retract it unless there is a very
> serious regression affecting most/all users. This does not look such
> case.

It seems so. This patch was not tested on standalone MT7530 at submission.
Whilst the patch is useless for standalone MT7530, it doesn't seem to break
anything either, from my simple test on a board with it.

> 
> I think the better option is follow-up on net with follow-up fixes if
> any.
> 
> All the relevant patches could be sent to the stable tree later:
> 
> https://elixir.bootlin.com/linux/latest/source/Documentation/process/stable-kernel-rules.rst#L47
> 
> To try to reduce the possibilities of this kind of situation in the
> future, may I kindly ask you to invest some more little time to help
> the reviewers and the maintainers? e.g. trimming the replies explicitly
> cutting all the unneeded parts in the quoted code/text would make the
> whole conversation much easier to follow (at least to me). The netdev
> volume is insane, it's very easy to get lost in a given thread and miss
> relevant part of it.

I already try to do this. Here's my proposal that would not reduce but
completely avoid this kind of situation in the future, and at the same time
reduce the workload of the netdev maintainers. Do not apply patches without
ACKs. Ask for reviews at least once if the patch had been stale for a
while, and wait a bit for reviews. Only then apply the patch with/without
ACKs.

Arınç