All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Rob Herring <robh@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	PCI <linux-pci@vger.kernel.org>,
	"Toan Le" <toan@os.amperecomputing.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Stéphane Graber" <stgraber@ubuntu.com>,
	"dann frazier" <dann.frazier@canonical.com>,
	"Android Kernel Team" <kernel-team@android.com>
Subject: Re: [PATCH v2 0/2] PCI: xgene: Restore working PCIe functionnality
Date: Mon, 21 Mar 2022 16:36:02 +0000	[thread overview]
Message-ID: <87h77rxnyl.wl-maz@kernel.org> (raw)
In-Reply-To: <CAL_JsqJacC6GbNebTfYyUEScROCFN4+Fg2v1_iYFfqAvW4E9Vw@mail.gmail.com>

On Mon, 21 Mar 2022 15:17:34 +0000,
Rob Herring <robh@kernel.org> wrote:
> 
> On Mon, Mar 21, 2022 at 5:49 AM Marc Zyngier <maz@kernel.org> 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. 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.

> 
> 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? ;)

I'm not sure people on the list are representative of all the users,
and I didn't realise the plan was "let's break everything we don't
like and see if someone wakes up" either. That definitely puts things
in a different perspective.

	M.

-- 
Without deviation from the norm, progress is not possible.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Rob Herring <robh@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	PCI <linux-pci@vger.kernel.org>,
	"Toan Le" <toan@os.amperecomputing.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Stéphane Graber" <stgraber@ubuntu.com>,
	"dann frazier" <dann.frazier@canonical.com>,
	"Android Kernel Team" <kernel-team@android.com>
Subject: Re: [PATCH v2 0/2] PCI: xgene: Restore working PCIe functionnality
Date: Mon, 21 Mar 2022 16:36:02 +0000	[thread overview]
Message-ID: <87h77rxnyl.wl-maz@kernel.org> (raw)
In-Reply-To: <CAL_JsqJacC6GbNebTfYyUEScROCFN4+Fg2v1_iYFfqAvW4E9Vw@mail.gmail.com>

On Mon, 21 Mar 2022 15:17:34 +0000,
Rob Herring <robh@kernel.org> wrote:
> 
> On Mon, Mar 21, 2022 at 5:49 AM Marc Zyngier <maz@kernel.org> 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. 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.

> 
> 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? ;)

I'm not sure people on the list are representative of all the users,
and I didn't realise the plan was "let's break everything we don't
like and see if someone wakes up" either. That definitely puts things
in a different perspective.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-03-21 16:36 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21 10:48 [PATCH v2 0/2] PCI: xgene: Restore working PCIe functionnality Marc Zyngier
2022-03-21 10:48 ` Marc Zyngier
2022-03-21 10:48 ` [PATCH v2 1/2] PCI: xgene: Revert "PCI: xgene: Use inbound resources for setup" Marc Zyngier
2022-03-21 10:48   ` Marc Zyngier
2022-03-21 10:48 ` [PATCH v2 2/2] PCI: xgene: Revert "PCI: xgene: Fix IB window setup" Marc Zyngier
2022-03-21 10:48   ` Marc Zyngier
2022-03-21 10:59 ` [PATCH v2 0/2] PCI: xgene: Restore working PCIe functionnality Lorenzo Pieralisi
2022-03-21 10:59   ` Lorenzo Pieralisi
2022-03-21 15:17 ` Rob Herring
2022-03-21 15:17   ` Rob Herring
2022-03-21 15:50   ` dann frazier
2022-03-21 15:50     ` dann frazier
2022-03-21 16:08     ` Rob Herring
2022-03-21 16:08       ` Rob Herring
2022-03-21 22:32       ` dann frazier
2022-03-21 22:32         ` dann frazier
2022-03-22 21:00         ` Rob Herring
2022-03-22 21:00           ` Rob Herring
2022-03-22 22:29           ` dann frazier
2022-03-22 22:29             ` dann frazier
2022-03-21 16:36   ` Marc Zyngier [this message]
2022-03-21 16:36     ` Marc Zyngier
2022-03-21 18:03     ` Rob Herring
2022-03-21 18:03       ` Rob Herring
2022-03-21 19:21       ` Marc Zyngier
2022-03-21 19:21         ` Marc Zyngier
2022-03-21 20:06         ` Robin Murphy
2022-03-21 20:06           ` Robin Murphy
2022-03-22 13:16           ` Robin Murphy
2022-03-22 13:16             ` Robin Murphy
2022-03-22 14:39             ` Rob Herring
2022-03-22 14:39               ` Rob Herring
2022-03-22 14:56               ` Robin Murphy
2022-03-22 14:56                 ` Robin Murphy
2022-03-22 15:41               ` Marc Zyngier
2022-03-22 15:41                 ` Marc Zyngier
2022-03-21 21:06       ` dann frazier
2022-03-21 21:06         ` dann frazier
2022-03-22 22:29       ` Ard Biesheuvel
2022-03-22 22:29         ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h77rxnyl.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=dann.frazier@canonical.com \
    --cc=kernel-team@android.com \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robh@kernel.org \
    --cc=stgraber@ubuntu.com \
    --cc=toan@os.amperecomputing.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.