Hi Wolfram, Prabhakar, > -----Original Message----- > From: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> > Sent: Thursday, June 20, 2024 8:40 AM > 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. Why this cannot be modelled as a regular "regulator" as a child device of SDHI device? See [1] and [2] [1] https://lore.kernel.org/linux-renesas-soc/20240616105402.45211-1-biju.das.jz@xxxxxxxxxxxxxx/ [2] https://elixir.bootlin.com/linux/latest/source/drivers/regulator/vqmmc-ipq4019-regulator.c Cheers, Biju