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

From: Alexandre Torgue <alexandre.torgue@st.com>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>,
	Marek Vasut <marex@denx.de>, Arnd Bergmann <arnd@arndb.de>,
	Olof Johansson <olof@lixom.net>,
	Kevin Hilman <khilman@baylibre.com>, SoC Team <soc@kernel.org>,
	arm-soc <arm@kernel.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
	Marcin Sloniewski <marcin.sloniewski@gmail.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: "linux-stm32@st-md-mailman.stormreply.com"
	<linux-stm32@st-md-mailman.stormreply.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [GIT PULL] STM32 DT fixes for v5.10 #1
Date: Mon, 2 Nov 2020 14:02:53 +0100	[thread overview]
Message-ID: <6889e344-00b7-9b1c-8048-e9c5adaf53c6@st.com> (raw)
In-Reply-To: <61a89fe2-639d-32b9-be66-9f51b73d579f@pengutronix.de>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel