netdev - Re: [PATCH net-next 3/4] net: dsa: realtek: do not assert reset on remove

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: <CACRpkda0pPwW34QyrKYBOsztPhTdCiZ5cop0T9TP7DFTn8d6cg@mail.gmail.com>
Date: Sun, 10 Mar 2024 19:33:26 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Luiz Angelo Daros de Luca <luizluca@...il.com>
Cc: Alvin Šipraga <alsi@...g-olufsen.dk>, 
	Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, 
	Vladimir Oltean <olteanv@...il.com>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 3/4] net: dsa: realtek: do not assert reset on remove

On Sun, Mar 10, 2024 at 5:52 AM Luiz Angelo Daros de Luca
<luizluca@...il.com> wrote:

> The necessity of asserting the reset on removal was previously questioned, as DSA's own cleanup methods should suffice to prevent traffic leakage[1].
>
> When a driver has subdrivers controlled by devres, they will be unregistered after the main driver's .remove is executed. If it asserts a reset, the subdrivers will be unable to communicate with the hardware during their cleanup. For LEDs, this means that they will fail to turn off, resulting in a timeout error.
>
> [1] https://lore.kernel.org/r/20240123215606.26716-9-luizluca@gmail.com/
>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@...il.com>

The commit message needs some linebreaks :D

Other than that:
Reviewed-by: Linus Walleij <linus.walleij@...aro.org>

Yours,
Linus Walleij