From: Bjorn Helgaas <helgaas@kernel.org>
To: Sinan Kaya <okaya@codeaurora.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
linux-pci@vger.kernel.org, Zhou Wang <wangzhou1@hisilicon.com>,
Phil Edworthy <phil.edworthy@renesas.com>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [RFC] ARM/ARM64 PCI_PROBE_ONLY platforms
Date: Sat, 30 Jan 2016 07:30:27 -0600 [thread overview]
Message-ID: <20160130133027.GA16394@localhost> (raw)
In-Reply-To: <56AC0065.5030909@codeaurora.org>
On Fri, Jan 29, 2016 at 07:14:29PM -0500, Sinan Kaya wrote:
> On 1/29/2016 6:06 PM, Bjorn Helgaas wrote:
> > On Wed, Jan 20, 2016 at 11:13:04AM -0500, Sinan Kaya wrote:
> >> On 1/20/2016 11:04 AM, Lorenzo Pieralisi wrote:
> >>>
> >>> We want to get rid of PCI_PROBE_ONLY on ARM/ARM64:
> >>
> >> For platforms that does not have UEFI BIOS, it makes sense to remove the probe only
> >> option as the firmware is not doing anything.
> >
> > I don't understand this statement. It sounds like you mean "non-UEFI
> > BIOS firmware doesn't assign PCI BARs", but that's not true, so you
> > must mean something else.
>
> It depends on the firmware flavor. I know u-boot does some PCI
> assignment but it does minimum to use PCI itself not for OS
> consumption. It may not deal with with switches/bridges etc. or will
> only assign mem32 resources and not touch prefetchable.
Ah, I see the problem. When you wrote "non-UEFI BIOS," I thought
"old-fashioned x86 BIOS," which generally do assign resources. But I
don't have much experience with other firmware like U-boot. There are
good reasons, e.g., portability and boot-time optimization, why
firmware might not touch things it doesn't need. That's especially
true for PCI resource assignment, where we know the OS must do it
itself anyway, and there's little point in doing it twice.
> Most non-UEFI firmwares I have seen on ARM rely on device specific
> driver like synopsys etc. to do the device initialization and ask
> kernel to do the enumeration.
>
> ACPI systems on the other hand handle the resource assignment before
> the OS starts.
My guess is that this is more of a tradition than anything actually
required by the spec.
The bottom line is that Linux can't rely on much consistency across
the universe of architectures and firmwares. I think the only thing
that really makes sense for us to do is:
- Read whatever assignments the firmware may have made
- Keep them unchanged if they seem sensible
- Reassign them if they aren't sensible
- Use quirks to handle exceptions
Bjorn
next prev parent reply other threads:[~2016-01-30 13:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-20 16:04 [RFC] ARM/ARM64 PCI_PROBE_ONLY platforms Lorenzo Pieralisi
2016-01-20 16:13 ` Sinan Kaya
2016-01-20 18:10 ` Lorenzo Pieralisi
2016-01-20 18:15 ` Sinan Kaya
2016-01-29 23:26 ` Bjorn Helgaas
2016-01-22 16:28 ` Phil Edworthy
2016-01-25 17:51 ` Lorenzo Pieralisi
2016-01-28 17:27 ` Lorenzo Pieralisi
2016-01-29 12:02 ` Gabriele Paoloni
2016-01-29 6:32 ` Pratyush Anand
2016-01-29 23:25 ` Bjorn Helgaas
2016-02-01 16:28 ` Lorenzo Pieralisi
2016-02-01 21:19 ` Bjorn Helgaas
2016-01-29 23:06 ` Bjorn Helgaas
2016-01-30 0:14 ` Sinan Kaya
2016-01-30 13:30 ` Bjorn Helgaas [this message]
2016-01-30 17:51 ` Okaya
2016-02-01 15:25 ` Lorenzo Pieralisi
2016-02-01 21:12 ` Bjorn Helgaas
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=20160130133027.GA16394@localhost \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=okaya@codeaurora.org \
--cc=phil.edworthy@renesas.com \
--cc=wangzhou1@hisilicon.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).