Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp707883pxa; Fri, 14 Aug 2020 16:06:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzf/obHt+18187bylD1LAjzSzCkzK21PnQY+BhP5EJxlV0ilijHoaUbKrzeEYeaiQuPqDMY X-Received: by 2002:a05:6402:304b:: with SMTP id bu11mr4449899edb.106.1597446368517; Fri, 14 Aug 2020 16:06:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597446368; cv=none; d=google.com; s=arc-20160816; b=0rYejqn4UlgWE553PaI+ZpaxQN5JqgpYvhtv7kUQ7HXd//txJk5kOdk73v5x8fZW87 w0by9SgSTrpJPP90N3kvCLeNMUuJRBUfX64/hiWpnxTHGotrvbYMEK4q3zzN1R+PxPFY XtR76SDq3vDEDuR54NqaDF7AdBVU+gEUNa+ZiHl/+031zlzx5WL9By2OLoebC9QYhrou 3SeSC9qLTmY+vf8pxgOz6qDY/4LprWT8wVgxnLrPGu5br/My9/Obj2Bld4vnE1rQdfhd tWzA7ZZZ5AHPAcB2DWkOZmqItoM9wguTO9wZkI4f981mCDzfitzXpKbEtJIrU7Z84Iek AW0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=PsNEXVoYVTPlHXVXsn/KA7U9Ce7o9CFgNbBWGhpm2a8=; b=kwDNqfDgq38Uboq/BFZEnvPvfkFFrncJ/jZdB8gRs/GVafUAcTjdRzfsDdzXuYKcQy pD7u8+5XPelNKShY5BdxMHdY5AZ+s7y0rUcA0zXHWTeWNS6MDxrQ+bHDSOCSa+MitOHy I/SG4YVGBDVqSCOiu6r0AjRNh6NbuDBIZebWPmBELeMUJLeO8l3+GvyXBW/cPk4HBsRH B1oH3d6mOuTnKPDY/nhqXMCeXwBhsAGkv0T8fER62lJBHaSkitxTMwCLl1mBueXSntC0 ilhUB65XCG9ZvUc6310PV5xmnnSjePKKqh9OSnB3ezqjrTHuCD0UUHvlDfmrIrdyAsNO 5wnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=cKqV9OFq; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lg12si5941864ejb.661.2020.08.14.16.05.43; Fri, 14 Aug 2020 16:06:08 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=default header.b=cKqV9OFq; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727093AbgHNWva (ORCPT + 99 others); Fri, 14 Aug 2020 18:51:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:37054 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726213AbgHNWva (ORCPT ); Fri, 14 Aug 2020 18:51:30 -0400 Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 675D12224D; Fri, 14 Aug 2020 22:51:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597445489; bh=htFr2L7stDcDCXIGv/hhOio3Jcl0xCNKJ2kseITjPCo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=cKqV9OFqvaHWEhTDf2LEI4Dje2q46a3LsQE+XNtXgU9lHhnBfwDHhSydghk3goqp5 UFhyl34nlPNGAqvnyd6RwtINV8kwA9W9zUoSsGdjPeUzJ59tVQsSNDb2BytyQxhw7W shAFGcjtkPU5Lwbn6ItmRCBFTY0wR187iy/U4Tdo= Received: by mail-oi1-f182.google.com with SMTP id l204so9505925oib.3; Fri, 14 Aug 2020 15:51:29 -0700 (PDT) X-Gm-Message-State: AOAM533FEPxKh+sy30/61JwmPG2SYkY8hZ4upeIVCpcfE97yQfAxvPGE jxmaToLSAuDWJ/pwXn37ahlRgDVqyu3fWBIlHg== X-Received: by 2002:aca:190c:: with SMTP id l12mr3031294oii.147.1597445488562; Fri, 14 Aug 2020 15:51:28 -0700 (PDT) MIME-Version: 1.0 References: <20200728153708.1296374-1-jiaxun.yang@flygoat.com> <20200728153708.1296374-2-jiaxun.yang@flygoat.com> <889508bae5da3c55690a7adbd101a5cd@kernel.org> In-Reply-To: <889508bae5da3c55690a7adbd101a5cd@kernel.org> From: Rob Herring Date: Fri, 14 Aug 2020 16:51:17 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 1/5] of_address: Add bus type match for pci ranges parser To: Marc Zyngier Cc: Jiaxun Yang , Frank Rowand , "open list:MIPS" , Thomas Bogendoerfer , Huacai Chen , Paul Burton , Arnd Bergmann , Nathan Chancellor , Nick Desaulniers , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , Android Kernel Team Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 14, 2020 at 12:21 PM Marc Zyngier wrote: > > Hi all, > > On 2020-07-28 16:36, Jiaxun Yang wrote: > > So the parser can be used to parse range property of ISA bus. > > > > As they're all using PCI-like method of range property, there is no > > need > > start a new parser. > > > > Signed-off-by: Jiaxun Yang > > Reviewed-by: Rob Herring > > This patch, although it looks correct, breaks the RK3399-based > systems, as they miss the (now required) 'device_type = "pci";' > property. Required since 1990 something... > We can fix the in-tree DT, but that's not really an option > if someone relies on the DT being provided by the firmware > (I for one definitely do). Perhaps time to pay attention to schema errors: arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dt.yaml: pcie@f8000000: 'device_type' is a required property (I thought dtc would also catch this, but there we look for device_type and then do PCI checks like node name. I guess we needed to check for either device_type or the node name...) > I came up with the following hack, which solves the issue for > me. Definitely not my finest hour, but I really need this box > to keep going. I will post a patch fixing the DT separately. > > Thanks, > > M. > > From ceef5fd9c4d2005eb577505c68868ebe527c098f Mon Sep 17 00:00:00 2001 > From: Marc Zyngier > Date: Fri, 14 Aug 2020 19:10:12 +0100 > Subject: [PATCH] of: address: Workaround broken DTs missing the > 'device_type = > "pci"' property > > Recent changes to the PCI bus parsing made it mandatory for > device trees nodes describing a PCI controller to have the > 'device_type = "pci"' property for the node to be matched. > > Although this is compliant with the specification, it breaks > existing device-trees that have been working fine for years > (the Rockchip rk3399-based systems being a prime example of > such breakage). > > In order to paper over the blunder, let's also match nodes > that have the "linux,pci-domain" property, as they are > pretty likely to be PCI nodes. This fixes the issue for > systems such as the above platforms. > > Fixes: 2f96593ecc37 ("of_address: Add bus type match for pci ranges > parser") > Signed-off-by: Marc Zyngier > --- > drivers/of/address.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/of/address.c b/drivers/of/address.c > index 590493e04b01..712e03781a2a 100644 > --- a/drivers/of/address.c > +++ b/drivers/of/address.c > @@ -134,9 +134,12 @@ static int of_bus_pci_match(struct device_node *np) > * "pciex" is PCI Express > * "vci" is for the /chaos bridge on 1st-gen PCI powermacs > * "ht" is hypertransport > + * "linux,pci-domain" is a workaround for broken device trees > + * lacking the required "device_type" property. I would suggest looking for 'pci' or 'pcie' node name instead. You should remove linux,pci-domain from rk3399 as it is pointless when there's a single PCI host bridge. The other option is fixup the live tree with of_add_property() in the Rockchip PCI driver. Less likely to impact anyone else. > */ > return of_node_is_type(np, "pci") || of_node_is_type(np, "pciex") || > - of_node_is_type(np, "vci") || of_node_is_type(np, "ht"); > + of_node_is_type(np, "vci") || of_node_is_type(np, "ht") || > + of_find_property(np, "linux,pci-domain", NULL); > } > > static void of_bus_pci_count_cells(struct device_node *np, > -- > 2.27.0 > > > -- > Jazz is not dead. It just smells funny...