Hi, MarkOn 26.11.2014 19:53, Mark Brown wrote: > On Wed, Nov 26, 2014 at 07:27:06PM +0200, Vladimir Zapolskiy wrote: >> On 25.11.2014 14:17, Mark Brown wrote: > >> b) "regulator-boot-on" does not mean that the regulator is controlled by >> bootloader or firmware exclusively. > > That's correct... > >>>>> Should documentation be updated to reflect "regulator-boot-on" role that >>>>> a regulator is re-enabled by the kernel? > >>> I'm confused about this. That's the sole purpose of the flag and as far >>> as I can tell it's what the documentation says. > >> Documentation/devicetree/bindings/regulator/regulator.txt says: > >> - regulator-boot-on: bootloader/firmware enabled regulator > >> I would suggest to add Linux kernel to that list of regulator >> controllers, if it is the intention. In its current state the >> documentation makes an impression that "regulator-boot-on" property >> instructs the kernel to ignore regulator setup, since it is already >> controlled by bootloader or firmware. > > No, not at all. It's referring to the state when Linux starts. > thank you for clarification, to grasp the underlying policy let me ask for some more information. If I want to enable a fixed regulator (not controlled by bootloader/firmware) by Linux on boot or when fixed.ko module is bound, shall I specify the same "regulator-boot-on" property? At least this is the practical way to enable a fixed and/or gpio regulator right now, but is it correct? Or should the regulator always be enabled externally (assuming "regulator-always-on" is omitted) after registration independently on "regulator-boot-on" property? -- With best wishes, Vladimir -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
