All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	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: Fri, 17 Aug 2018 16:25:37 +0100	[thread overview]
Message-ID: <20180817152537.GA14912@red-moon> (raw)
In-Reply-To: <CAK8P3a02StKtvE+dfESGdeB_zvLbqy9jYwWWgzV6AaeAwyNu=Q@mail.gmail.com>

On Thu, Aug 16, 2018 at 11:04:53PM +0200, Arnd Bergmann wrote:
> 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.

pci_claim_resource() is needed if either arch code or the host
controller driver does not trigger a resources assignment (which claims
them while at it); in theory that's arch agnostic but it turned out to
be very arch/platform specific - aka if we move s390 code to core code
we will notice :) so pci_claim_resource() in a pcibios call is
unfortunately legitimate - whether it can be moved out of it to
generic code that's a very complicated problem.

Lorenzo

WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-riscv@lists.infradead.org
Subject: [PATCH 1/3] PCI: add a callback to struct pci_host_bridge for adding a new device
Date: Fri, 17 Aug 2018 16:25:37 +0100	[thread overview]
Message-ID: <20180817152537.GA14912@red-moon> (raw)
In-Reply-To: <CAK8P3a02StKtvE+dfESGdeB_zvLbqy9jYwWWgzV6AaeAwyNu=Q@mail.gmail.com>

On Thu, Aug 16, 2018 at 11:04:53PM +0200, Arnd Bergmann wrote:
> 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.

pci_claim_resource() is needed if either arch code or the host
controller driver does not trigger a resources assignment (which claims
them while at it); in theory that's arch agnostic but it turned out to
be very arch/platform specific - aka if we move s390 code to core code
we will notice :) so pci_claim_resource() in a pcibios call is
unfortunately legitimate - whether it can be moved out of it to
generic code that's a very complicated problem.

Lorenzo

  reply	other threads:[~2018-08-17 15:25 UTC|newest]

Thread overview: 42+ 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 ` 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-01 15:14   ` Christoph Hellwig
2018-08-02 16:54   ` Lorenzo Pieralisi
2018-08-02 16:54     ` Lorenzo Pieralisi
2018-08-04 10:11     ` Christoph Hellwig
2018-08-04 10:11       ` Christoph Hellwig
2018-08-15 19:52     ` Bjorn Helgaas
2018-08-15 19:52       ` Bjorn Helgaas
2018-08-16 20:59       ` Bjorn Helgaas
2018-08-16 20:59         ` Bjorn Helgaas
2018-08-16 21:04         ` Arnd Bergmann
2018-08-16 21:04           ` Arnd Bergmann
2018-08-17 15:25           ` Lorenzo Pieralisi [this message]
2018-08-17 15:25             ` Lorenzo Pieralisi
2018-08-17 15:47             ` Arnd Bergmann
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   ` Christoph Hellwig
2018-08-01 15:14 ` [PATCH 3/3] PCI/xilinx: Depend on OF instead of the ARCH Christoph Hellwig
2018-08-01 15:14   ` Christoph Hellwig
2018-08-02 16:56   ` Lorenzo Pieralisi
2018-08-02 16:56     ` Lorenzo Pieralisi
2018-08-04 10:12     ` Christoph Hellwig
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-01 23:02   ` Wesley Terpstra
2018-08-02  7:14   ` Christoph Hellwig
2018-08-02  7:14     ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
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-04 10:14   ` Christoph Hellwig
2018-08-06 11:23   ` Lorenzo Pieralisi
2018-08-06 11:23     ` Lorenzo Pieralisi
2018-08-06 12:30     ` Christoph Hellwig
2018-08-06 12:30       ` Christoph Hellwig
2018-08-06 13:54       ` Arnd Bergmann
2018-08-06 13:54         ` Arnd Bergmann
2018-08-06 14:55         ` Lorenzo Pieralisi
2018-08-06 14:55           ` Lorenzo Pieralisi
2018-08-06 19:49           ` Arnd Bergmann
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=20180817152537.GA14912@red-moon \
    --to=lorenzo.pieralisi@arm.com \
    --cc=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=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 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.