linux-kernel - Re: [PATCH v2 2/2] reset: always include 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]

Message-ID: <aPnz6U-fcodRoobU@shikoro>
Date: Thu, 23 Oct 2025 11:22:49 +0200
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Philipp Zabel <p.zabel@...gutronix.de>
Cc: Bartosz Golaszewski <brgl@...ev.pl>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	linux-renesas-soc@...r.kernel.org,
	Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] reset: always include RESET_GPIO driver if
 possible

Hi Philipp,

> > > I dunno for how many drivers this is really applicable, but I really
> > > liked the cleanup of the pca954x driver.
> 
> That cleanup might have been a little premature, given that the reset-
> gpio driver currently only works on OF-based platforms, and even there
> only with gpio controllers with #gpio-cells = <2>.

I see. That kind of spoils my assumption that it is a fallback supported
by the core. Darn, I would still like to have it, but it seems more
complicated than I have time for it :(

> How about selecting RESET_GPIO from I2C_MUX_PCA954x? It already depends
> on GPIOLIB. Although I don't like the idea of drivers being converted
> en masse, all selecting RESET_GPIO ...

Well, on top of that, reset is optional with this driver, so selecting
it doesn't feel proper.

> To be honest, I don't like either very much.
> 
> Yes, the reset-gpio driver is only about three pages in size, but
> force-enabling it for nearly everyone, just because some hardware
> designs like to share resets a little too much, feels wrong to me,
> especially in its current state.

I understand the argument of 'too limited in the current state'. I don't
get the 'share too much' argument? The fallback would remove open-coded
"reset-gpios" handling and sync it with generic reset handling?

> And just default-enabling it doesn't solve the regression problem when
> updating preexisting configs.

Yes.

Well, at least patch 1 seems okay, so users at least get notified of the
problem...

All the best,

   Wolfram


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)