Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp248971pxu; Sun, 22 Nov 2020 06:46:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJwIcJu8zKGSqqnu5sF+FirzCh5DuO6uDNAMgU6jDtWekDOobNzGk3DDSNnJ/VVhevKJppKS X-Received: by 2002:a17:906:329a:: with SMTP id 26mr39175812ejw.227.1606056417571; Sun, 22 Nov 2020 06:46:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606056417; cv=none; d=google.com; s=arc-20160816; b=W6Hc6pyiRj0ocCIjk3OZCz+TYXkO8GecZVtyYpO9NUH+jMb09PZebHYKSSRiFxcDAG KFBvmm8lmJGP04ap2lgxyqTKc10DDUCjYSgPcasVsbcjBIuBbClX8Nji5CLNH3T+zQc9 x1BlSkP6a17XtLbFWcFt5rldiynFb+Wyuvz6yAe8YEifnnwo4TRjVBr7ju+MYpVsUQf5 lDPmza6nUaiQCqwyGAP5lkfM2C0+zEzrUFMsFkERB+KdycmdAlP/J1cHyM22lMfqi9Rd opk3NL2Rr7dma6sX2amJi+ggA1rhRMxAFmaAGGn9HEyStHSj45otpNQKgntqpbMulck+ YPmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=KiO+X9IiSQDihE8G4KfQwmEOn8kgerSHitOF45KP6yU=; b=eLTn5d+4bKgu3zWiucMNwRtToWdNAvqOpY9L7CQ1fl+U79eL28UGUV2maNuwV2hUc9 kPsu93xzyUn7mqiApoKaQEgBtenEzARlyerY0+295Dgy0oWiJgZ9C16mEQYmlltxK6cH uer9KJTOOoRkPSpof/nmC0IMFy9A1EgUf4U0lBRNaQ8C23NEtTUVg4Q46nSP1i2fpEKM 8g7xvT/mwoYtQJdqLtq12iwYieVBP3WKoJLAoTg1Bg82RGTh3csS2qiLdQQohTWwrmK7 YhpY3RTNHdZr32fX4Xd3Z+TM4hvIwF5A/2806+ryp4IAkWsIIgohTtdem8mGh5odVv/l 2FCg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t19si4925155eju.318.2020.11.22.06.46.31; Sun, 22 Nov 2020 06:46:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727728AbgKVOoR (ORCPT + 99 others); Sun, 22 Nov 2020 09:44:17 -0500 Received: from gecko.sbs.de ([194.138.37.40]:33756 "EHLO gecko.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727424AbgKVOoQ (ORCPT ); Sun, 22 Nov 2020 09:44:16 -0500 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 0AMEhYsW031561 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 22 Nov 2020 15:43:35 +0100 Received: from [167.87.38.29] ([167.87.38.29]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 0AMEhXd4007532; Sun, 22 Nov 2020 15:43:33 +0100 Subject: Re: About regression caused by commit aea6cb99703e ("regulator: resolve supply after creating regulator") To: Qu Wenruo , =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Maxime Coquelin , Alexandre Torgue Cc: Linux ARM , Linux Kernel Mailing List , broonie@kernel.org References: <20201108171811.GB10914@qmqm.qmqm.pl> <858790f6-8b22-4fe7-bb74-56904ad203bd@suse.com> From: Jan Kiszka Message-ID: Date: Sun, 22 Nov 2020 15:43:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <858790f6-8b22-4fe7-bb74-56904ad203bd@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09.11.20 00:28, Qu Wenruo wrote: > > > On 2020/11/9 上午1:18, Michał Mirosław wrote: >> On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote: >>> Hi Michał, >>> >>> Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot >>> from NVME. >>> >>> It turns out that, commit aea6cb99703e ("regulator: resolve supply after >>> creating regulator") seems to be the cause. >>> >>> In RK3399 board, vpcie1v8 and vpcie0v9 of the pcie controller is >>> provided by RK808 regulator. >>> With that commit, now RK808 regulator fails to register: >>> >>> [ 1.402500] rk808-regulator rk808-regulator: there is no dvs0 gpio >>> [ 1.403104] rk808-regulator rk808-regulator: there is no dvs1 gpio >>> [ 1.419856] rk808 0-001b: failed to register 12 regulator >>> [ 1.422801] rk808-regulator: probe of rk808-regulator failed with >>> error -22 >> >> Hi, >> >> This looks lika the problem fixed by commit cf1ad559a20d ("regulator: defer >> probe when trying to get voltage from unresolved supply") recently accepted >> to regulator tree [1]. Can you verify this? > > Thanks, tested with that commit cherry picked to v5.10-rc2 and it solves > the problem. > We are still missing some magic fix for stable trees: On the STM32MP15x, things are broken since 5.4.73 now. And 5.9.y is not booting as well on that board. Reverting the original commit make it boot again. Linus master is fine, though, but I'm tired of bisecting. Any suggestions? Or is there something queued up already? In any case: Is that board in no stable Q&A farm? It's a basic "boot fails" regression. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux