Hi Mark, Liam, (and other Renesas multimedia-devs)... I have an issue with a circular dependency on regulators and I'm wondering if you could offer some guidance before I go down a rabbit hole. Descriptions first, and a couple of questions down at the bottom: I have a GMSL deserializer (MAX9286) [0] which connects 4 cameras over a GMSL bus. These are currently expressed as an I2C Mux (each GMSL connector provides a channel to communicate over I2C). The MAX9286 also exposes 2 GPIO pins, as such I have configured the MAX9286 driver [1] to expose a gpio-chip [2]. Before we communicate with the cameras, we must make sure that they are powered up, which we do by specifying a 'poc' (power-over-coax) regulator, and we enable it accordingly. This works fine when the regulator is not directly tied to the max9286. But alas we've got a board (the eagle-v3m) which uses the gpio-line on the max9286 to enable power to the cameras. You'll hopefully be able to see in patch [2], that the gpio-chip is created before the call to get the regulator: ret = max9286_gpio(priv); if (ret) return ret; priv->regulator = regulator_get(&client->dev, "poc"); And thus at that point the GPIO chip 'exists'. I have updated the DT for our 'eagle' board to create a regulator-fixed [3], connected to the GPIO line on the max9286, including the required delays we must wait for the cameras to come up. Alas, here-in is where we have our circular dependency. The regulator-fixed device can not be probed until the GPIO controller is created during the max9286_probe(). And now I can't get the regulator, because of course it doesn't yet exist. I can not return -EPROBE_DEFER from max9286, as that would destroy the gpio_chip already created, and thus the regulator-fixed would still not be able to probe anyway, (and also there is a further issue in V4L2 which prevents us from probe-deferring this driver). So - my diving into the code shows that the regulator_dev_lookup() at drivers/regulator/core.c tries to identify the regulator from the of_node (r = of_find_regulator_by_node(node);) but this returns empty and thus returns -EPROBE_DEFER as highlighted by the comment : "We have a node, but there is no device. assume it has not registered yet." [0] https://www.maximintegrated.com/en/products/interface/high-speed-signaling/MAX9286.html [1] media: i2c: Add MAX9286 driver https://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git/commit/?id=210913146496a0b7661a7b1af03fa8596ef42303 [2] media: i2c: max9286: Add GPIO chip controller https://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git/commit/?id=896d77990562068d46749867b5c73b5e62815d47 [3] dts: eagle: Create a regulator-gpio https://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git/commit/?id=3b49a32cfc83918eba2dd6936bd9bce03e7cb367 (That commit title should really read "create a regulator-fixed") So - after that long description, my questions are - - is there anything I can do here within regulator_dev_lookup() to attempt creating the regulator_dev 'on-demand' when of_find_regulator_by_node(node) returns empty? (or is that crazy, and just a rabbit-hole?) [2] Ensures that the gpio_chip that it is connected to has already been created. (and if it had not we certainly couldn't do anything else except a -EPROBE_DEFER) - My current workaround is to use a gpio-hog, but that doesn't allow me to provide a startup-delay-us which we require, thus I've had to hard code a *large* delay into the driver for testing. Is there anything 'else' I could do to construct this appropriately and define the required delay (which is camera specific) in DT? I'd rather not code some table of camera specific delays into the max9286 driver... Note that we can't make any assumptions within the max9286 driver to always use the gpio-line to enable the cameras. It's just a generic line, which hardware designers can 'choose' to utilise. Indeed on another board we have, the 'PoC' regulator is connected to an entirely separate GPIO (not on the max9286), and thus we don't have this issue. I sort of hope it might be possible to 'probe' the regulator when it is needed rather than having to defer, but I fear how that would tie into the driver core, so this e-mail is really to collect my thoughts on the current issue before I jump into what could be a horrible dead-end, and see if anyone has any ideas or comments on this topic. Thanks for reading this far! And I look forward to any comments... -- Regards -- Kieran
