On Wed, Dec 01, 2021 at 03:33:24PM +0100, H. Nikolaus Schaller wrote: > > Am 01.12.2021 um 15:03 schrieb Paul Cercueil <paul@xxxxxxxxxxxxxxx>: > > Please make it mandatory in DTS then, and use devm_regulator_get() in the driver. > Well, I just wonder why the elegant devm_regulator_get_optional() exists at all > and seems to be used in ca. 80 places. Frankly because half of them are broken usages like this since people seem determined to have the most fragile error handling they can :/ There are valid use cases for it, with things like SD cards where some supplies are genuinely optional and simply constrain what features are available if they're omitted from the design. You also see some devices with the ability to replace internal regulators with external ones. > And if it is not allowed, why some DTS should be forced to add not physically existing dummy-regulators. Again, if the supply can be physically absent that is a sensible use case but that means completely absent, not just not software controllable. We can represent fixed voltage regulators just fine. > AFAIR drivers should implement functionality defined by DTS but not the other way round: enforce DTS style. > BTW: there is no +5 mains dummy regulator defined in ci20.dts. It wouldn't be the first time a DTS were incomplete, and I'm sure it won't be the last. > What I fear is that if we always have to define the mains +5V (which is for example not > defined in ci20.dts), which rules stops us from asking to add a dummy-regulator from 110/230V to +5V as well. It is good practice to specify the full tree of supplies all the way to the main supply rail of the board, this ensures that if we need the information for something we've got it (even if that thing is just that we've got to the root of the tree). There's potential applications in battery supplied devices for managing very low power situations.
Attachment:
signature.asc
Description: PGP signature
