linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Christoph Hellwig <hch@lst.de>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	"Wesley W. Terpstra" <wesley@sifive.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH 1/3] PCI: add a callback to struct pci_host_bridge for adding a new device
Date: Thu, 16 Aug 2018 23:04:53 +0200	[thread overview]
Message-ID: <CAK8P3a02StKtvE+dfESGdeB_zvLbqy9jYwWWgzV6AaeAwyNu=Q@mail.gmail.com> (raw)
In-Reply-To: <20180816205901.GA15085@bhelgaas-glaptop.roam.corp.google.com>

On Thu, Aug 16, 2018 at 10:59 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, Aug 15, 2018 at 02:52:28PM -0500, Bjorn Helgaas wrote:
> > On Thu, Aug 02, 2018 at 05:54:30PM +0100, Lorenzo Pieralisi wrote:

> > This patch seems OK to me.
> >
> > I don't really care about the prototype.  There's only one
> > pcibios_add_device() implementation (x86) that returns anything other
> > than 0, and that's a pretty obscure error case related to f9a37be0f02a
> > ("x86: Use PCI setup data"), which lets us use ROM data from boot
> > services.  Even then the only thing that happens is a WARN_ON().  A
> > more descriptive printk would be a lot more useful.
>
> Thinking about this some more, I'm not so sure about the connection
> with removing pcibios_add_device().  This host_bridge->add_dev() hook
> would be for host bridge-specific things, while pcibios_add_device()
> is for arch-specific things.
>
> I'd still love to get rid of pcibios_add_device() (especially the
> non-arch-specific things like the pci_claim_resource() in s390); I'm
> just not sure yet whether this particular patch is the vehicle.

I think most of the arch-specific pcibios_* calls are actually
host bridge specific after all, it just so happens that they are
implemented on architectures that only have one specific
host bridge implementation, or that they are used on an
architecture that does something odd in one place and needs
to do something else in another place.

For pci_claim_resource() we seem to be doing this in a number
of different places, but there isn't strictly a reason for that.

I've started a patch series to turn all the __weak pcibios_*
functions into callbacks, which seems to be the right solution
for almost all of them.

      Arnd

  reply	other threads:[~2018-08-16 21:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-01 15:14 add support for Xilinx PCIe root ports on RISC-V v2 Christoph Hellwig
2018-08-01 15:14 ` [PATCH 1/3] PCI: add a callback to struct pci_host_bridge for adding a new device Christoph Hellwig
2018-08-02 16:54   ` Lorenzo Pieralisi
2018-08-04 10:11     ` Christoph Hellwig
2018-08-15 19:52     ` Bjorn Helgaas
2018-08-16 20:59       ` Bjorn Helgaas
2018-08-16 21:04         ` Arnd Bergmann [this message]
2018-08-17 15:25           ` Lorenzo Pieralisi
2018-08-17 15:47             ` Arnd Bergmann
2018-08-01 15:14 ` [PATCH 2/3] PCI/xilinx: Work-around for hardware DMA limit (32 bits) Christoph Hellwig
2018-08-01 15:14 ` [PATCH 3/3] PCI/xilinx: Depend on OF instead of the ARCH Christoph Hellwig
2018-08-02 16:56   ` Lorenzo Pieralisi
2018-08-04 10:12     ` Christoph Hellwig
2018-08-01 23:02 ` add support for Xilinx PCIe root ports on RISC-V v2 Wesley Terpstra
2018-08-02  7:14   ` Christoph Hellwig
2018-08-04 10:13 add support for Xilinx PCIe root ports on RISC-V v3 Christoph Hellwig
2018-08-04 10:14 ` [PATCH 1/3] PCI: add a callback to struct pci_host_bridge for adding a new device Christoph Hellwig
2018-08-06 11:23   ` Lorenzo Pieralisi
2018-08-06 12:30     ` Christoph Hellwig
2018-08-06 13:54       ` Arnd Bergmann
2018-08-06 14:55         ` Lorenzo Pieralisi
2018-08-06 19:49           ` Arnd Bergmann

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='CAK8P3a02StKtvE+dfESGdeB_zvLbqy9jYwWWgzV6AaeAwyNu=Q@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=hch@lst.de \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=palmer@dabbelt.com \
    --cc=wesley@sifive.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).