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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D2ECC433EF for ; Mon, 21 Mar 2022 15:18:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349994AbiCUPTf (ORCPT ); Mon, 21 Mar 2022 11:19:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37744 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349933AbiCUPTP (ORCPT ); Mon, 21 Mar 2022 11:19:15 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B2C411174C; Mon, 21 Mar 2022 08:17:50 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E7AB2B8175E; Mon, 21 Mar 2022 15:17:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8CB8C340F4; Mon, 21 Mar 2022 15:17:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647875867; bh=9+FB8FqiPz2INA3LHeEMbXtjaqxdTmkp1xc/rbUvb8g=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=iY2kM+kk/k9XRIJpOweLDdoV0Qbbb9Le27cicZiqsTWHGuaubJxgJKDF3p7i1Lepy FYDMrEVtCCOqmoUNxkbqmfdx5AiTxkKnBIkQk6jzKZs9e9c60k0BWEr+nsvrJHumw3 SxACHAsrR+7s8jr6tN77OthE9W4ckwlNz898NvR0mYagooAamWfywmFEZMetc7qdD2 dyjCNBNWdbMZxup0DHanVr8Zw/Mhb+fo52hkPUfVWdHUTUDF7OUxwJcZCwFHSzAqfB ssLoyytLEYPe+jy6osPEQVJl6nezkF8xixnZaUIbnwR7xPDdIxNHWawg4zNJnGq2Fs vNSK5qRXUR2SA== Received: by mail-ed1-f42.google.com with SMTP id b24so18220954edu.10; Mon, 21 Mar 2022 08:17:47 -0700 (PDT) X-Gm-Message-State: AOAM530whwR1lYN3L7Ddk6yN4+veqJmt4fcslavZRsLEU6AB8XjqYxrw MsuGad9tbPxR2w6ok5zNYX7SfSOLRxYKGtscLA== X-Google-Smtp-Source: ABdhPJzVOekr/XRMAYz6o3vgNpt77YLnLfN20A1NcI85VtDGlaILC4gRTvIJUrbrtw7CiwFutMg/Nb4GAJ585vY9D/0= X-Received: by 2002:a05:6402:1d51:b0:418:bd81:78b3 with SMTP id dz17-20020a0564021d5100b00418bd8178b3mr22893313edb.46.1647875865787; Mon, 21 Mar 2022 08:17:45 -0700 (PDT) MIME-Version: 1.0 References: <20220321104843.949645-1-maz@kernel.org> In-Reply-To: <20220321104843.949645-1-maz@kernel.org> From: Rob Herring Date: Mon, 21 Mar 2022 10:17:34 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/2] PCI: xgene: Restore working PCIe functionnality To: Marc Zyngier Cc: "linux-kernel@vger.kernel.org" , linux-arm-kernel , PCI , Toan Le , Lorenzo Pieralisi , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Bjorn Helgaas , =?UTF-8?Q?St=C3=A9phane_Graber?= , dann frazier , Android Kernel Team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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). 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. Rob P.S. We're carrying ACPI and DT support for these platforms. It seems the few users are using DT, so can we drop the ACPI support? Or do I need to break it first and wait a year? ;) 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 D42CEC433F5 for ; Mon, 21 Mar 2022 15:21:34 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=EGM0rWQyQ/6sHxiz2cqQyHFsBH23HCwF1Nq2EISlMEw=; b=Mxz/aFEDsjbNxB FsoZcFHmlYqY7xrL46oyQ8RlPc1IPPAq+gIWLRGBQ4d3bb2WodSx02AdZkmwKkMsHc90453aqnyZC HY7J+np4jVrQxF6CfSYBqGGVc+UXmS/wyV0PWPsUiYFuRruUh+NCkD1wD5VOKah3uY+/0YvRahSTz NC84rqfAbFuim8B2ieEyi7rwQEjcUjn4LvZxGklaoOu05FhFDU1NMmELksTAKNCrZM94nhez7f3g9 Yu0cwK7iW0YXPhzImwB1TaC74BPtHN4tIxoKcCV9T+zPQQfTvASqxZe/+4Frc9nTnZmrPkA1Odsir /x/kdUIkFR7VZEv4WEUQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWJpK-008ABQ-B0; Mon, 21 Mar 2022 15:20:10 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWJn5-0088w4-Kl for linux-arm-kernel@lists.infradead.org; Mon, 21 Mar 2022 15:17:53 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 75F26B81761 for ; Mon, 21 Mar 2022 15:17:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF26FC340F7 for ; Mon, 21 Mar 2022 15:17:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647875867; bh=9+FB8FqiPz2INA3LHeEMbXtjaqxdTmkp1xc/rbUvb8g=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=iY2kM+kk/k9XRIJpOweLDdoV0Qbbb9Le27cicZiqsTWHGuaubJxgJKDF3p7i1Lepy FYDMrEVtCCOqmoUNxkbqmfdx5AiTxkKnBIkQk6jzKZs9e9c60k0BWEr+nsvrJHumw3 SxACHAsrR+7s8jr6tN77OthE9W4ckwlNz898NvR0mYagooAamWfywmFEZMetc7qdD2 dyjCNBNWdbMZxup0DHanVr8Zw/Mhb+fo52hkPUfVWdHUTUDF7OUxwJcZCwFHSzAqfB ssLoyytLEYPe+jy6osPEQVJl6nezkF8xixnZaUIbnwR7xPDdIxNHWawg4zNJnGq2Fs vNSK5qRXUR2SA== Received: by mail-ed1-f50.google.com with SMTP id u26so2677496eda.12 for ; Mon, 21 Mar 2022 08:17:47 -0700 (PDT) X-Gm-Message-State: AOAM530fybQ2MV9VIrfxJJ7L2ZlFL1dJetLxK0kCD8aAaE20qpM8jKlP 5yEpEqikq/xP9lzaxTEdXgHAqA64t+/81yAnDQ== X-Google-Smtp-Source: ABdhPJzVOekr/XRMAYz6o3vgNpt77YLnLfN20A1NcI85VtDGlaILC4gRTvIJUrbrtw7CiwFutMg/Nb4GAJ585vY9D/0= X-Received: by 2002:a05:6402:1d51:b0:418:bd81:78b3 with SMTP id dz17-20020a0564021d5100b00418bd8178b3mr22893313edb.46.1647875865787; Mon, 21 Mar 2022 08:17:45 -0700 (PDT) MIME-Version: 1.0 References: <20220321104843.949645-1-maz@kernel.org> In-Reply-To: <20220321104843.949645-1-maz@kernel.org> From: Rob Herring Date: Mon, 21 Mar 2022 10:17:34 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/2] PCI: xgene: Restore working PCIe functionnality To: Marc Zyngier Cc: "linux-kernel@vger.kernel.org" , linux-arm-kernel , PCI , Toan Le , Lorenzo Pieralisi , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Bjorn Helgaas , =?UTF-8?Q?St=C3=A9phane_Graber?= , dann frazier , Android Kernel Team X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220321_081752_083347_BFF3ECF6 X-CRM114-Status: GOOD ( 21.91 ) 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 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). 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. Rob P.S. We're carrying ACPI and DT support for these platforms. It seems the few users are using DT, so can we drop the ACPI support? Or do I need to break it first and wait a year? ;) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel