On 5/2/23 13:53, Marek Vasut wrote:
On 5/2/23 12:41, Eugen Hristev wrote:
On 5/2/23 12:18, Marek Vasut wrote:
On 5/2/23 08:51, Eugen Hristev wrote:
regulator_set_enable_if_allowed already handles cases when the regulator is already enabled, or already disabled, and does not treat these as errors. With this change, the driver can work correctly even if the regulator is already taken or already disabled by another consumer.
Can that ever happen for Vbus supply (the 5V coming out of USB port) ? Can you elaborate how ?
Hi Marek,
Hi,
Recently I developed a series of patches to add a reference counter for regulators :
Ah yes, this is super cool stuff, thanks !
But with this series, having a regulator already enabled or already disabled results in an error returned by regulator_set_enable
Hence, one option is to replace calls with regulator_set_enable_if_allowed
There is a discussion ongoing here:
Pardon my ignorance, but uh ... how does Linux deal with regulators which are enabled by prior stage, like U-Boot ? Does it set their enable refcount to =1 or =0 ?
Please correct me if I am wrong, I did not dig too much into regulators, but , from my understanding :
Normally software(in this case Linux) reads the state of the regulator when it's probed, and sets the refcount accordingly. If the state cannot be read then regulator-boot-on tells Linux that it should have been left enabled by prior stage In Uboot I believe that regulators that have 'regulator-boot-on' are added to a list and set to enable during probe, and the probe is forced even if Uboot normally uses lazy probing (should have the same behavior for regulator-always-on property)
So if a regulator is enabled by an initial stage but it's not described with 'regulator-boot-on' , appears to be a bad hardware description in DT.