From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
linux-pci@vger.kernel.org, Sinan Kaya <okaya@kernel.org>,
"Zilberman, Zeev" <zeev@amazon.com>,
"Saidi, Ali" <alisaidi@amazon.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC] ARM64 PCI resource survey issue(s)
Date: Wed, 05 Jun 2019 06:41:16 +1000 [thread overview]
Message-ID: <e520a4269224ac54798314798a80c080832e68b1.camel@kernel.crashing.org> (raw)
In-Reply-To: <20190604124959.GF189360@google.com>
On Tue, 2019-06-04 at 07:49 -0500, Bjorn Helgaas wrote:
> > Yes... I am not personally aware of such a case but I was led to
> > believe based on prior conversations that such setups do exist,
> > especially in the non-ACPI ARM64 world. Which is why I would suggest
> > initially changing the default only on ACPI, at least until we have a
> > bit better visibility.
>
> If a resource assignment that is valid in terms of all the PCI rules
> (BARs are valid, BARs are inside upstream bridge windows, etc) doesn't
> work, we would need more information in order to fix anything. We'd
> need to know exactly *what* doesn't work and *why* so we can avoid it.
> The current blanket statement of "reassign everything and hope it
> works better" is useless.
I agree and I assume the problem stems from BIOSes creating either
invalid or incomplete assignments but as I said, I don't know for sure
as our platforms dont have that problem.
Cheers,
Ben.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-06-04 20:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-03 23:41 [RFC] ARM64 PCI resource survey issue(s) Benjamin Herrenschmidt
2019-06-04 1:49 ` Bjorn Helgaas
2019-06-04 3:32 ` Benjamin Herrenschmidt
2019-06-04 3:37 ` Benjamin Herrenschmidt
2019-06-04 6:56 ` Benjamin Herrenschmidt
2019-06-04 12:49 ` Bjorn Helgaas
2019-06-04 20:41 ` Benjamin Herrenschmidt [this message]
2019-06-06 9:00 ` [PATCH/RESEND] arm64: acpi/pci: invoke _DSM whether to preserve firmware PCI setup Benjamin Herrenschmidt
2019-06-06 9:13 ` Ard Biesheuvel
2019-06-06 10:55 ` Benjamin Herrenschmidt
2019-06-11 14:31 ` Lorenzo Pieralisi
2019-06-11 22:09 ` Benjamin Herrenschmidt
2019-06-11 22:34 ` Ard Biesheuvel
2019-06-11 22:40 ` Benjamin Herrenschmidt
2019-06-12 10:21 ` Lorenzo Pieralisi
2019-06-12 22:05 ` Benjamin Herrenschmidt
2019-06-11 14:58 ` Lorenzo Pieralisi
2019-06-11 22:19 ` Benjamin Herrenschmidt
2019-06-12 10:08 ` Lorenzo Pieralisi
2019-06-12 10:58 ` Benjamin Herrenschmidt
2019-06-11 23:39 ` Bjorn Helgaas
2019-06-12 0:06 ` Benjamin Herrenschmidt
2019-06-12 13:27 ` Bjorn Helgaas
2019-06-12 21:46 ` Benjamin Herrenschmidt
2019-06-12 23:58 ` Benjamin Herrenschmidt
2019-06-10 10:11 ` [RFC] ARM64 PCI resource survey issue(s) Lorenzo Pieralisi
2019-06-11 5:46 ` Benjamin Herrenschmidt
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=e520a4269224ac54798314798a80c080832e68b1.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=alisaidi@amazon.com \
--cc=ard.biesheuvel@linaro.org \
--cc=helgaas@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=okaya@kernel.org \
--cc=zeev@amazon.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).