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;
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Sun, 30 Aug 2020 10:41:42 +0100
From:   Marc Zyngier <maz@kernel.org>
To:     Samuel Dionne-Riel <samuel@dionne-riel.com>
Cc:     devicetree@vger.kernel.org, Frank Rowand <frowand.list@gmail.com>,
        Rob Herring <robh+dt@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: Boot failure on gru-scarlet-inx with 5.9-rc2
In-Reply-To: <20200829164920.7d28e01a@DUFFMAN>
References: <20200829164920.7d28e01a@DUFFMAN>
User-Agent: Roundcube Webmail/1.4.8
Message-ID: <65d88bdd0888a69849327501a2aad186@kernel.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Samuel,

On 2020-08-29 21:54, Samuel Dionne-Riel wrote:
> Hi,
> 
> The patch "of: address: Work around missing device_type property in
> pcie nodes" by Marc Zyngier, d1ac0002dd297069bb8448c2764c9c31c4668441,
> causes the "DUMO" variant of the gru-scarlet-inx, at the very least,
> to not boot. A gru-kevin reportedly had no issues booting (further),
> though it most likely had a different kernel configuration.

Do you have a pointer to the device-tree for this system? I couldn't
spot anything amiss in the scarlet-inx DT, but I'm not sure the
system you have is that exact one. Even a DTB would help.

The fact that Kevin still boots is a good indication that the issue
could be with with the board-specific changes layered on top of the
GRU base. My own rk3399 systems are running with this patch.

> Using a SuzyQ cable, there is absolutely no serial output at boot,
> while reverting the commit (and this commit alone) on top of v5.9-rc2
> works just as it did with v5.9-rc1.

Do you have "earlycon" on the kernel command-line?

> From this point on, I don't know what's the usual process, so bear with
> me if I forgot to provide relevant information, or made a faux-pas by
> CC-ing too many people or not enough.

No need to worry, and thank you for reporting the issue.

Could you try replacing the problematic patch with [1], and let me
know whether this changes anything on your end? This patch probably
isn't the right approach, but it would certainly help pointing me
in the right direction.

Thanks,

         M.

[1] https://lore.kernel.org/lkml/20200815125112.462652-2-maz@kernel.org/
-- 
Jazz is not dead. It just smells funny...