Re: [PATCH v2 1/7] soc: rockchip: add driver for rockchip io domains

[Sascha Hauer <sha@pengutronix.de>]

On Thu, Sep 22, 2022 at 09:13:35AM +0100, Ahmad Fatoum wrote:
> Hi,
> 
> On 22.09.22 09:03, Sascha Hauer wrote:
> > On Wed, Sep 21, 2022 at 01:49:49PM +0200, Michael Riesch wrote:
> >> Hi Sascha,
> >>
> >> On 9/21/22 11:46, Sascha Hauer wrote:
> >>> On Mon, Sep 19, 2022 at 01:39:42PM +0200, Michael Riesch wrote:
> >>>> The IO domains in Rockchip SoCs need to be configured to match the
> >>>> corresponding bank voltage. In Linux this is achieved by means of a
> >>>> platform driver that reads the voltage value of the supplies and
> >>>> configures the bits in the general register file (GRF) accordingly.
> >>>> Port this driver to barebox to provide support for the Rockchip
> >>>> RK356x SoCs.
> >>>>
> >>>> Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
> >>>> ---
> >>>>  drivers/soc/Kconfig              |   1 +
> >>>>  drivers/soc/Makefile             |   1 +
> >>>>  drivers/soc/rockchip/Kconfig     |  17 +++
> >>>>  drivers/soc/rockchip/Makefile    |   6 +
> >>>>  drivers/soc/rockchip/io-domain.c | 223 +++++++++++++++++++++++++++++++
> >>>>  5 files changed, 248 insertions(+)
> >>>>  create mode 100644 drivers/soc/rockchip/Kconfig
> >>>>  create mode 100644 drivers/soc/rockchip/Makefile
> >>>>  create mode 100644 drivers/soc/rockchip/io-domain.c
> >>>
> >>> There's nothing in this driver that makes sure it is probed before the
> >>> users of the io domains. What happens when the users are probed before
> >>> the io domain driver?
> >>
> >> Correct. Unfortunately, the situation is quite the same in the kernel.
> >> Only recently there was a discussion as to how to resolve this issue
> >> [0]. While the RFC in [0] was received well there is no mainline
> >> solution to this problem. I would suggest that the mainline kernel
> >> solution is adopted once there is one.
> >>
> >> In the mean time we could
> >>  - accept that it just works for some reason (TM)
> >>  - leave the magic bits in the low-level initialization to be on the
> >>    safe side
> > 
> > Decided for this solution for now.
> > 
> > I added the following as a reminder that there's still something
> > to do.
> 
> Why not do an of_device_ensure_probed for the I/O domain driver in
> rk3568_init()?

We can't do a of_device_ensure_probed() properly from plain initcalls.
For example rk3568_init() is called at postcore level, at that time the
io-domain driver is not yet registered.

We would have to find an initcall level where the io-domain driver and
all its dependencies (i2c bus driver, PMIC driver) is registered, but
none of its consumers are probed. While we could probably find the right
initcall level this defeats the purpose of deep probe.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |