linux-kernel - RE: [PATCH] mmc: renesas_sdhi: add regulator dependency

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] [day] [month] [year] [list]

Message-ID:
 <TY3PR01MB11346D37C0C25E66DF33ECB2086A32@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Sat, 29 Mar 2025 12:49:54 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>, Arnd Bergmann
	<arnd@...db.de>
CC: Arnd Bergmann <arnd@...nel.org>, Ulf Hansson <ulf.hansson@...aro.org>,
	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"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] mmc: renesas_sdhi: add regulator dependency

Hi All,

> -----Original Message-----
> From: Wolfram Sang <wsa+renesas@...g-engineering.com>
> Sent: 29 March 2025 11:47
> 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' instean
d of 'vqmmc-
> regulator'.

Yes, Only few SoCs has internal regulator support and is based on
of_device_is_available().


> 
> > 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.

Tested-by: Biju Das <biju.das.jz@...renesas.com>

Cheers,
Biju