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: <Z-fdsBZgcO6bruIN@shikoro>
Date: Sat, 29 Mar 2025 12:46:56 +0100
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Arnd Bergmann <arnd@...nel.org>, Ulf Hansson <ulf.hansson@...aro.org>,
	Biju Das <biju.das.jz@...renesas.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	"linux-mmc @ vger . kernel . org" <linux-mmc@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mmc: renesas_sdhi: add regulator dependency

On Sat, Mar 29, 2025 at 11:46:10AM +0100, Arnd Bergmann wrote:
> On Sat, Mar 29, 2025, at 10:46, Wolfram Sang wrote:
> > On Sat, Mar 29, 2025 at 09:20:52AM +0100, Arnd Bergmann wrote:
> >
> >>  config MMC_SDHI
> >>  	tristate "Renesas SDHI SD/SDIO controller support"
> >> -	depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
> >> +	depends on SUPERH || (ARCH_RENESAS && RESET_CONTROLLER) || COMPILE_TEST
> >> +	depends on REGULATOR
> >
> > Hmm, this is too strict IMO. SuperH does not need REGULATOR.
> 
> I haven't tried building on sh, but I don't see why it wouldn't
> need the regulator dependency. The code that calls it is
> 
>         rcfg.of_node = of_get_child_by_name(dev->of_node, "vqmmc-regulator");
>         if (!of_device_is_available(rcfg.of_node)) {
>                 of_node_put(rcfg.of_node);
>                 rcfg.of_node = NULL;
>         }
> 
>         if (rcfg.of_node) {
>                 rcfg.driver_data = priv->host;
>                 rdev = devm_regulator_register(dev, &renesas_sdhi_vqmmc_regulator, &rcfg);
>         ...
> 
> which sounds like regulators are always needed when
> of_get_child_by_name() may return a non-NULL pointer, i.e.
> when CONFIG_OF is enabled.

rcfg.of_node will be NULLed when the regulator device is not available.
Which is only true for a few SoC variants. Most other SoCs use
'vmmc-supply' insteand of 'vqmmc-regulator'.

> If this is correct, maybe this is the best variant:
> 
> config MMC_SDHI
>   	tristate "Renesas SDHI SD/SDIO controller support"
> 	depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
>         depends on (REGULATOR && RESET_CONTROLLER) || !OF
> 
> CONFIG_ARCH_RENESAS is only set when CONFIG_OF is also set,
> so both subsystem dependencies are covered by that, while
> SUPERH doesn't currently enable OF, but will need the
> regulator and reset controller if that patch is ever merged.

Even given the above, I like this approach and think it still works.
But Biju is the SDHI regulator expert here.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ