mbox series

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

Message ID 4ac236b3-b980-f653-f644-53e586570724@st.com
State New
Headers show
Series [GIT,PULL] STM32 DT fixes for v5.10 #1 | expand

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git tags/stm32-dt-for-v5.10-fixes-1

Message

Alexandre Torgue Oct. 28, 2020, 3:28 p.m. UTC
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.

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.


Regards
Alex


The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:

   Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)

are available in the Git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git 
tags/stm32-dt-for-v5.10-fixes-1

for you to fetch changes up to 728a7e225ad807b4b4de3be3fb653424199f8a76:

   ARM: dts: stm32: Describe Vin power supply on stm32mp157c-edx board 
(2020-10-28 15:08:24 +0100)

----------------------------------------------------------------
STM32 DT fixes for v5.10, round 1

Highlights:
-----------

  -On STM32MP157 DK & ED boards: Add Vin supply description to avoid
   random kernel crash due to vref_ddr regulator issue.

----------------------------------------------------------------
Pascal Paillet (2):
       ARM: dts: stm32: Describe Vin power supply on stm32mp15xx-dkx board
       ARM: dts: stm32: Describe Vin power supply on stm32mp157c-edx board

  arch/arm/boot/dts/stm32mp157c-ed1.dts  | 15 +++++++++++++++
  arch/arm/boot/dts/stm32mp15xx-dkx.dtsi | 17 +++++++++++++++++
  2 files changed, 32 insertions(+)

Comments

Arnd Bergmann Oct. 28, 2020, 4:11 p.m. UTC | #1
From: Arnd Bergmann <arnd@arndb.de>

On Wed, 28 Oct 2020 16:28:33 +0100, Alexandre Torgue wrote:
> 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.
> 
> 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
> 
> [...]

Merged into arm/fixes, thanks!

merge commit: 01eea23687ed0aa4e251f80ae795fc586e68343a

       Arnd
Ahmad Fatoum Oct. 28, 2020, 5:38 p.m. UTC | #2
Hello Alex,

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 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.

Cheers,
Ahmad

> 
> 
> Regards
> Alex
> 
> 
> The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
> 
>   Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git tags/stm32-dt-for-v5.10-fixes-1
> 
> for you to fetch changes up to 728a7e225ad807b4b4de3be3fb653424199f8a76:
> 
>   ARM: dts: stm32: Describe Vin power supply on stm32mp157c-edx board (2020-10-28 15:08:24 +0100)
> 
> ----------------------------------------------------------------
> STM32 DT fixes for v5.10, round 1
> 
> Highlights:
> -----------
> 
>  -On STM32MP157 DK & ED boards: Add Vin supply description to avoid
>   random kernel crash due to vref_ddr regulator issue.
> 
> ----------------------------------------------------------------
> Pascal Paillet (2):
>       ARM: dts: stm32: Describe Vin power supply on stm32mp15xx-dkx board
>       ARM: dts: stm32: Describe Vin power supply on stm32mp157c-edx board
> 
>  arch/arm/boot/dts/stm32mp157c-ed1.dts  | 15 +++++++++++++++
>  arch/arm/boot/dts/stm32mp15xx-dkx.dtsi | 17 +++++++++++++++++
>  2 files changed, 32 insertions(+)
>
Marek Vasut Oct. 30, 2020, 9:04 a.m. UTC | #3
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")

>> 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.
Ahmad Fatoum Nov. 2, 2020, 12:52 p.m. UTC | #4
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.

> 
>>> 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.
>
Alexandre Torgue Nov. 2, 2020, 1:02 p.m. UTC | #5
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