On Thu, Oct 17, 2024 at 2:01 PM Mark Brown <broonie@xxxxxxxxxx> wrote: > > On Thu, Oct 17, 2024 at 01:28:00PM +0200, Bartosz Golaszewski wrote: > > On Thu, Oct 17, 2024 at 12:59 PM Mark Brown <broonie@xxxxxxxxxx> wrote: > > > > Fix your driver to request the supplies that actually exist on the > > > device rather than just some random supplies you hope will work? > > > Let me rephrase: the device has this supply but on this particular > > board nothing is connected to it. It does sound to me like an example > > of an "optional" supply. Do you have anything against making it > > possible to define optional supplies when using the bulk regulator > > APIs? > > Oh, right - please if asking questions ask a complete question rather Sure, sorry. > than having a long email thread and adding an "any thoughts" at the end > which makes it unclear what the actual question is. In general the > expectation for optional supplies is that you will need to do something > different depending on if the supply is there, that will tend to mean > that it's fairly natural to do a separate request for it as well. > What's the concrete use case here? A device is wired differently on different platforms. It requests a bunch of supplies using devm_regulator_bulk_get(). One of them is unconnected on one of the platforms resulting in the "using dummy regulator" warning. Concrete use-case is: make all but one regulator mandatory when calling regulator_bulk_get(). My proposal is extending struct regulator_bulk_data with a boolean flag called "optional" which would result in the underlying _regulator_get() receiving the OPTIONAL_GET flag only for the regulators that are marked as such. Bartosz
