[GIT PULL] STM32 DT fixes for v5.10 #1

[Alexandre Torgue]

Hi guys

On 11/2/20 1:52 PM, Ahmad Fatoum wrote:
> Hello Marek,
> 
> On 10/30/20 10:04 AM, Marek Vasut wrote:
>> On 10/28/20 6:38 PM, Ahmad Fatoum wrote:
>>> Hello Alex,
>>
>> Hi,
>>
>>> On 10/28/20 4:28 PM, Alexandre Torgue wrote:
>>>> Hi Arnd, Olof and Kevin,
>>>>
>>>> On v5.10-rc1 STM32 boards cannot boot. It is linked to a change in regulator framework which highlights that our supplies are not well described. This PR fixes it for STM32 boards that I have on my desk: ED1 and DKx.
>>>
>>> Which change triggered the regression?
>>
>> I think it might be:
>> aea6cb99703e ("regulator: resolve supply after creating regulator")
>> which landed in 5.4.73 as
>> 0120ec32a777 ("regulator: resolve supply after creating regulator")
> 
> Thanks. I just replied (with a CC to the ML here) to another thread
> reporting issues to the author's patch.

Thanks Ahmad

> 
>>
>>>> I assume that same patch has to be done for other STM32 boards, but as I don't have schematics I can't provide it. So a round2 has to be done for:
>>>> - stinger96
>>>> - MC-1
>>>> - Odyssey SOM
>>>> - DHCOR /DHCOM
>>>>
>>>> Mani, Marek, Ahmad, Marcin can you please have a look on it and provide patches (then I'll provide round2). Thanks in advance.
>>>
>>> Your change doesn't look right. If I set vref_ddr-supply to a fixed regulator,
>>> the MC-1 now boots again as well, but that seems to just mask the real issue:
>>>
>>>    - vref_ddr is an _output_ of the PMIC, why should one have to specify a supply for it?
>>>
>>>    - This is actually incompatible with the binding. vref_ddr-supply isn't specified
>>>      as an allowed property (not to mention a required one)
>>>
>>>    - Isn't the kernel supposed to stay compatible to old device trees?
>>>
>>> I think the stpmic driver is at fault here and that the regulator framework change just
>>> made that apparent.
>>
>> I agree updating the DT is not the right approach.
>>
> 

I agree with you. Regulator framework change should not impose a change 
in DT (except if it explicitly mentioned in binding documentation). As I 
explained to Marek this morning, I had this patch in my backlog, and it 
allows to boot STM32 DK/EV boards for rc cycle.

Now, let's have on "regulator: resolve supply after creating regulator".

-----
ret = set_machine_constraints(rdev, constraints);
if (ret == -EPROBE_DEFER) {
	/* Regulator might be in bypass mode and so needs its supply
	 * to set the constraints */
	/* FIXME: this currently triggers a chicken-and-egg problem
	 * when creating -SUPPLY symlink in sysfs to a regulator
	 * that is just being created */
	ret = regulator_resolve_supply(rdev);
	if (!ret)
		ret = set_machine_constraints(rdev, constraints);
	else
		rdev_dbg(rdev, "unable to resolve supply early: %pe\n",
			 ERR_PTR(ret));
	}
if (ret < 0)
	goto wash;
-----


--> regulator_resolve_supply(rdev); is no longer called which seems to 
be the starting point of our issue.
Note that the "FIXME" comment could a clue.

cheers
alex