linux-kernel - Re: [RFC PATCH v2 3/3] mmc: renesas_sdhi: Add support for RZ/V2H(P) SoC

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: <o7tswznmyk6gxoqfqvbvzxdndvf5ggkyc54nwafypquxjlvdrv@3ncwl5i5wyy3>
Date: Thu, 20 Jun 2024 09:39:51 +0200
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
Cc: linux-mmc@...r.kernel.org, 
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>, Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org, 
	Ulf Hansson <ulf.hansson@...aro.org>, Magnus Damm <magnus.damm@...il.com>, 
	Biju Das <biju.das.jz@...renesas.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Geert Uytterhoeven <geert+renesas@...der.be>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>, linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 3/3] mmc: renesas_sdhi: Add support for RZ/V2H(P)
 SoC

Hi Prabhakar,

> I did give it a try with platform_driver_probe() and failed.

Ok, thanks for trying nonetheless!

> - Firstly I had to move the regulator node outside the SDHI node for
> platform_driver_probe() to succeed or else it failed with -ENODEV (at
> https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L953)

This makes sense to me because it is just a "regular" regulator.

> - In Renesas SoCs we have multiple instances of SDHI, the problem
> being for each instance we are calling platform_driver_probe(). Which
> causes a problem as the regulator node will use the first device.

I see... we would need a reg property to differentiate between the
internal regulators but that is already used by the parent SDHI node.

Okay, so let's scrap that idea. However, we need to ensure that we can
still have an external regulator. Seeing the bindings, it looks like you
enable the internal regulator with the "vqmmc-r9a09g057-regulator"
property? I wonder now if we can simplify this to an
"use-internal-regulator" property because we have 'compatible' already
to differentiate? Needs advice from DT maintainers, probably.

> Let me know if I have missed something obvious here.

Nope, all good.

> > Don't we need REGULATOR_CHANGE_VOLTAGE here as well? Or is this implicit
> > because of REGULATOR_VOLTAGE? Can't find this, though.
> >
> I will investigate it.

Thank you.

And happy hacking,

   Wolfram


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