From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B9621C433EF for ; Mon, 21 Mar 2022 21:08:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tK5hyiQQWamauEugYqCwPCl0nMlNalNUxyEzPGTOgVM=; b=vmOdZbPa9q+ba5 ynJGCZOIDbfTrYOuO68+9VtNVKaqT2ULFsEtiowNsTvZ8dIFMER17ETavOWtgH3hynYX6IluqVTD7 UWRu/DRqyxY9bDLaMCHbcIXnPawY5HefUlX62V3zLG72Vzb98BXZWY+s0klRpKNQlfCCX7MaWz4cE LCeWYPFIHSzveSp8jHTtNLe4iSfrs30nhhSDRQWG13Mx7gDOKj5g466ju72yl5kofoGOYHAFJEii6 +oSKjVEeEG5LUFwRWh5aPSLa/oke2poMvq3715o1DM8u8uUto5gUEf1I6OiWbnkQ5AdHvTH9mE2fK qx27COlWub4F+DKCylTw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWPEk-00998G-52; Mon, 21 Mar 2022 21:06:46 +0000 Received: from smtp-relay-internal-1.canonical.com ([185.125.188.123]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWPEe-00997u-96 for linux-arm-kernel@lists.infradead.org; Mon, 21 Mar 2022 21:06:42 +0000 Received: from mail-il1-f199.google.com (mail-il1-f199.google.com [209.85.166.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id A52873F1CA for ; Mon, 21 Mar 2022 21:06:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1647896793; bh=PH1bVwJW+65ZSg7ht8UKbv2/JhG2Jc27AqWMKxMcUUs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=v2Pf/TMp2Bx/d966rcN7a3d+na287rj4pBvLDWaD8Xi6eU4klRJIWqdLxFhZ6WZGY MI5dKZlE5O5hdHLSuJfoFsroLDmAvcPN5jxLR/rkkSLb4uBGG0p37gOQqWMkVPlOdV MU+MwleWHIY0VI8FvXZVjGPB4lHa4Wmf7ec2zmducEMQ6JB7IC/9kh87ZSGQN0LnHu DF4VvEVvu7McCYAO4XX/WNnG6j5x5GywjF69N/5Yo+nzonSvXX3Yzs/jTUKE8aLnrd CvI5tF9+OEXeYzZ0HLiJfVEWg0FgJYQGY+wH6suo/WPSJ0ECVqyflYazq5wivkRebG NEFfU5TkdKy+g== Received: by mail-il1-f199.google.com with SMTP id m20-20020a92c534000000b002c83ed01909so508404ili.1 for ; Mon, 21 Mar 2022 14:06:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=PH1bVwJW+65ZSg7ht8UKbv2/JhG2Jc27AqWMKxMcUUs=; b=zD3NANh0wnX0VdM9UKNNvz1uj3qTAiFMirMSjMrdvbH+z9B03YJS37W0bF/dvZQVz8 VWtuAZZapzf+Uaxhq/KB8okoi5KZK1+adpalAW7QBI4+ybwamS14RjuimGNFFvR4eSQB fvtuui4BAFtSsh9tpvDlOfRfZUpAnmj0SygYxwJl8Juga48dx53MsEUgdSJvdOYAbjwR oTHKzj5h9pmlwTpqZnWCYoPGRuRHXnE67dbJtf/6AGIXoY75tsBI/wUbwX/VMRjY2Z8k MsgMOvhTLNLH40A5rcWTenzteM3LWIqzIgR90+30Hsab9LOuCqwPRMdcnJkdKcrOFTU3 XOMg== X-Gm-Message-State: AOAM533IqkzRpgAPhR5c/7qCNuix0CXutuExpPrGScKOnXM+LFQEpSDW sza3TQiyw4e3vbsjNew+rCrakuPHzMBsjB9Uk9PK8Eb6hlUvE6Gq/tvZ4NpjJpeM1BAXVzPGoa2 /E3AeieVXDwgttsBbl1amYQ19vdP7WkHuJda4Y9UfMvtyXek7ECWt X-Received: by 2002:a05:6638:dd3:b0:317:c9aa:b38f with SMTP id m19-20020a0566380dd300b00317c9aab38fmr12574955jaj.9.1647896792352; Mon, 21 Mar 2022 14:06:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzdCB1f1uWvBZbayneSeyhrKeKVm216UoVjGHBb0qaQFHuwW3HlwiAEwvBUMRl9d0SpCqZ5Gw== X-Received: by 2002:a05:6638:dd3:b0:317:c9aa:b38f with SMTP id m19-20020a0566380dd300b00317c9aab38fmr12574930jaj.9.1647896792018; Mon, 21 Mar 2022 14:06:32 -0700 (PDT) Received: from xps13.dannf (c-73-14-97-161.hsd1.co.comcast.net. [73.14.97.161]) by smtp.gmail.com with ESMTPSA id m2-20020a056e021c2200b002c837530587sm1069585ilh.60.2022.03.21.14.06.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Mar 2022 14:06:31 -0700 (PDT) Date: Mon, 21 Mar 2022 15:06:29 -0600 From: dann frazier To: Rob Herring Cc: Marc Zyngier , "linux-kernel@vger.kernel.org" , linux-arm-kernel , PCI , Toan Le , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Bjorn Helgaas , =?iso-8859-1?Q?St=E9phane?= Graber , Android Kernel Team Subject: Re: [PATCH v2 0/2] PCI: xgene: Restore working PCIe functionnality Message-ID: References: <20220321104843.949645-1-maz@kernel.org> <87h77rxnyl.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220321_140640_646454_D150C1FA X-CRM114-Status: GOOD ( 39.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Mar 21, 2022 at 01:03:27PM -0500, Rob Herring wrote: > On Mon, Mar 21, 2022 at 11:36 AM Marc Zyngier wrote: > > > > On Mon, 21 Mar 2022 15:17:34 +0000, > > Rob Herring wrote: > > > > > > On Mon, Mar 21, 2022 at 5:49 AM Marc Zyngier wrote: > > > > > > > > Since 6dce5aa59e0b ("PCI: xgene: Use inbound resources for setup") was > > > > merged in the 5.5 time frame, PCIe on the venerable XGene platform has > > > > been unusable: 6dce5aa59e0b broke both XGene-1 (Mustang and m400) and > > > > XGene-2 (Merlin), while the addition of c7a75d07827a ("PCI: xgene: Fix > > > > IB window setup") fixed XGene-2, but left the rest of the zoo > > > > unusable. > > > > > > > > It is understood that this systems come with "creative" DTs that don't > > > > match the expectations of modern kernels. However, there is little to > > > > be gained by forcing these changes on users -- the firmware is not > > > > upgradable, and the current owner of the IP will deny that these > > > > machines have ever existed. > > > > > > The gain for fixing this properly is not having drivers do their own > > > dma-ranges parsing. We've seen what happens when drivers do their own > > > parsing of standard properties (e.g. interrupt-map). > > > > We have, and we added the required exceptions for the legacy platforms > > that the code base supported until then. We didn't leave things broken > > just because we didn't like the way things were done a long time ago. > > > > > Currently, we don't have any drivers doing their own parsing: > > > > > > $ git grep of_pci_dma_range_parser_init > > > drivers/of/address.c:int of_pci_dma_range_parser_init(struct > > > of_pci_range_parser *parser, > > > drivers/of/address.c:EXPORT_SYMBOL_GPL(of_pci_dma_range_parser_init); > > > drivers/of/address.c:#define of_dma_range_parser_init > > > of_pci_dma_range_parser_init > > > drivers/of/unittest.c: if (of_pci_dma_range_parser_init(&parser, np)) { > > > drivers/pci/of.c: err = of_pci_dma_range_parser_init(&parser, dev_node); > > > include/linux/of_address.h:extern int > > > of_pci_dma_range_parser_init(struct of_pci_range_parser *parser, > > > include/linux/of_address.h:static inline int > > > of_pci_dma_range_parser_init(struct of_pci_range_parser *parser, > > > > > > And we can probably further refactor this to be private to drivers/pci/of.c. > > > > > > For XGene-2 the issue is simply that the driver depends on the order > > > of dma-ranges entries. > > > > > > For XGene-1, I'd still like to understand what the issue is. Reverting > > > the first fix and fixing 'dma-ranges' should have fixed it. I need a > > > dump of how the IB registers are initialized in both cases. I'm not > > > saying changing 'dma-ranges' in the firmware is going to be required > > > here. There's a couple of other ways we could fix that without a > > > firmware change, but first I need to understand why it broke. > > > > Reverting 6dce5aa59e0b was enough for me, without changing anything > > else. > > Meaning c7a75d07827a didn't matter for you. I'm not sure that it would. > > Can you tell me what 'dma-ranges' contains on your system? > > > m400 probably uses an even older firmware (AFAIR, it was stuck > > with an ancient version of u-boot that HP never updated, while Mustang > > had a few updates). In any case, that DT cannot be changed. > > How is Dann changing it then? I assume he's not changing the firmware, > but overriding it. That could be a possible solution. Correct, I'm just overriding it for testing. I'm using the pxelinux emulation provided by the m400's u-boot, which supports an FDT field: --------- $ cat /srv/tftp/pxelinux.cfg/default DEFAULT default LABEL default KERNEL uImage APPEND initrd=uInitrd console=ttyS0,9600n8r ro root=LABEL=cloudimg-rootfs FDT m400.dtb --------- This loads the specified file into ${fdt_addr_r}, overriding the blob that the firmware had already loaded there. > Do the DT's in the kernel tree correspond to anything anyone is > using? Upstream apm-mustang.dtb is what Ubuntu uses for Mustang boards w/ u-boot firmware. That used to work fine, but I haven't tried lately. -dann _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel