[PATCH] usb: ehci-mx6: replace regulator_set_enable with *_if_allowed

[Marek Vasut]

On 5/2/23 13:18, Eugen Hristev wrote:
> 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 :
>>>
>>> https://marc.info/?l=u-boot&m=168191189309879&w=2
>>
>> 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:
>>>
>>> https://marc.info/?l=u-boot&m=168295920316621&w=2
>>
>> 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.

Thanks for checking this. It seems like Tim found the root cause of the 
problem in the meantime, so let's see where that discussion moves on to.