public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/3] drivers: pci: host-generic: claim bus resources on PCI_PROBE_ONLY set-ups
Date: Mon, 18 Apr 2016 16:49:43 +0200	[thread overview]
Message-ID: <5357164.ryYLtkY3PQ@wuerfel> (raw)
In-Reply-To: <20160418100154.GB2427@red-moon>

On Monday 18 April 2016 11:01:54 Lorenzo Pieralisi wrote:
> On Fri, Apr 15, 2016 at 08:08:03AM -0500, Bjorn Helgaas wrote:
> > On Tue, Apr 12, 2016 at 04:48:10PM +0100, Lorenzo Pieralisi wrote:

> > This last case 3) is the problem.  I'm guessing this case doesn't
> > currently occur on arm/arm64, but it's the normal case on x86, and it
> > seems perverse that things work if firmware does nothing, but they
> > don't work if firmware does more setup.
> 
> IIUC X86 claim resources as programmed by FW so it is not really the
> same situation as arm64, that claims nothing. Claimed resources are not
> reassigned, they are skipped by resource allocation/sizing code
> (because their parent pointer is set).
> 
> And as I said above even if FW does some set-up that will still work
> on ARM/ARM64, otherwise this means that on ALL ARM/ARM64 systems out there
> PCI set-up at kernel handover is non-existent, otherwise we would
> have resource enablement failures NOW, right ?

The embedded systems (in which I would count all arm32 machines) tend
to not do proper bus probing in their bootloaders, so we have to do it
ourselves in the kernel.

For server systems (all UEFI based ones), I'd argue that we should
rely on the firmware to do it just like we do on x86, possibly with
a blacklist of known-broken machines on which we have to do it
manually as well. Once ACPI spreads, we will likely see an increasing
number of machines on which we must not reassign the resources or
bad things happen to stuff that is owned by the BIOS.

	Arnd

  reply	other threads:[~2016-04-18 14:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-01 14:44 [PATCH v2 0/3] arm/arm64: pci: PCI_PROBE_ONLY clean-up Lorenzo Pieralisi
2016-03-01 14:44 ` [PATCH v2 1/3] drivers: pci: add generic code to claim bus resources Lorenzo Pieralisi
2016-04-26 12:47   ` Lorenzo Pieralisi
2016-03-01 14:44 ` [PATCH v2 2/3] drivers: pci: host-generic: claim bus resources on PCI_PROBE_ONLY set-ups Lorenzo Pieralisi
2016-04-12  4:43   ` Bjorn Helgaas
2016-04-12 15:48     ` Lorenzo Pieralisi
2016-04-15 13:08       ` Bjorn Helgaas
2016-04-18 10:01         ` Lorenzo Pieralisi
2016-04-18 14:49           ` Arnd Bergmann [this message]
2016-04-18 17:31             ` Lorenzo Pieralisi
2016-04-19 21:03           ` Bjorn Helgaas
2016-03-01 14:44 ` [PATCH v2 3/3] arm/arm64: pci: remove arch specific pcibios_enable_device() Lorenzo Pieralisi

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=5357164.ryYLtkY3PQ@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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