All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Liviu Dudau <liviu.dudau@arm.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Tomasz Nowicki <tn@semihalf.com>,
	linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH v2 1/2] PCI: Add new method for registering PCI hosts
Date: Mon, 04 Jul 2016 15:46:44 +0200	[thread overview]
Message-ID: <38942848.fvm5hraBhy@wuerfel> (raw)
In-Reply-To: <20160704095627.GG8609@e106497-lin.cambridge.arm.com>

On Monday, July 4, 2016 10:56:27 AM CEST Liviu Dudau wrote:
> On Fri, Jul 01, 2016 at 06:30:24PM +0200, Arnd Bergmann wrote:
> > On Friday, July 1, 2016 5:09:23 PM CEST Liviu Dudau wrote:

> > > Don't get me wrong, clearly someone needs to create an instance of pci_host_bridge.
> > > What I want people to accept is that in the PCI(e) architecture there is nothing that
> > > stops a piece of HW that used to be the bridge between host and underlying bus into
> > > becoming the bridge between a higher PCI(e) bus and the bus underneath. If the writes
> > > to the configuration registers happens somehow, the Host Bridge doesn't even know if
> > > it is talking to the actual host. Can the driver in that case make sure it did not made
> > > assumptions that were tied to a specific SoC implementation?
> > 
> > Sorry, I'm not really following what you mean with that, or what the
> > consequence is for the Linux implementation. Can you try to rephrase this?
> 
> I'm thinking drivers expecting to drive the bridge between the host and the PCI bus.
> When that HW is used to bridge between another bus (PCI or PCIe) because the
> functionality was there all the time in terms of signals, the driver's assumptions
> break down. But maybe I'm being too theoretical and such beasts don't exist? (I remember
> seeing a network card that had native PCI chip plus an added PCIe-to-PCI bridge and
> the driver was tripping badly, but I can't remember the exact details.

I think we should expect all non-host PCI bridges to behave according to the
normal PCI spec and get handled by the PCI core.

There are some handlers for broken bridges in drivers/pci/quirks.c, which
is not nice but there is little alternative, and I don't think that
hooking into the PCI host bridge driver code would help here.

	Arnd

  reply	other threads:[~2016-07-04 13:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-30 15:19 [PATCH v2 1/2] PCI: Add new method for registering PCI hosts Thierry Reding
2016-06-30 15:19 ` Thierry Reding
2016-06-30 15:19 ` [PATCH v2 2/2] PCI: tegra: Use new pci_register_host() interface Thierry Reding
     [not found] ` <20160630151931.29216-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-30 15:37   ` [PATCH v2 1/2] PCI: Add new method for registering PCI hosts Arnd Bergmann
2016-06-30 15:37     ` Arnd Bergmann
2016-07-01 14:14     ` Liviu Dudau
2016-07-01 14:14       ` Liviu Dudau
     [not found]       ` <20160701141447.GB8609-2JSQmVVBSi7ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2016-07-01 14:24         ` Arnd Bergmann
2016-07-01 14:24           ` Arnd Bergmann
2016-07-01 14:52           ` Liviu Dudau
2016-07-01 14:52             ` Liviu Dudau
     [not found]             ` <20160701145244.GD8609-2JSQmVVBSi7ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2016-07-01 15:17               ` Arnd Bergmann
2016-07-01 15:17                 ` Arnd Bergmann
2016-07-01 15:40                 ` Liviu Dudau
     [not found]                   ` <20160701154046.GE8609-2JSQmVVBSi7ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2016-07-01 15:58                     ` Arnd Bergmann
2016-07-01 15:58                       ` Arnd Bergmann
2016-07-01 14:46   ` Liviu Dudau
2016-07-01 14:46     ` Liviu Dudau
     [not found]     ` <20160701144648.GC8609-2JSQmVVBSi7ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2016-07-01 15:44       ` Arnd Bergmann
2016-07-01 15:44         ` Arnd Bergmann
2016-07-01 16:09         ` Liviu Dudau
2016-07-01 16:30           ` Arnd Bergmann
2016-07-04  9:56             ` Liviu Dudau
2016-07-04 13:46               ` Arnd Bergmann [this message]
2016-07-28 20:43   ` Bjorn Helgaas
2016-07-28 20:43     ` 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=38942848.fvm5hraBhy@wuerfel \
    --to=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=thierry.reding@gmail.com \
    --cc=tn@semihalf.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.