All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robherring2@gmail.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
	Michal Simek <monstr@monstr.eu>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Grant Likely <grant.likely@linaro.org>,
	devicetree@vger.kernel.org
Subject: Re: [RFC] Architecture independent pcibios?
Date: Tue, 08 Oct 2013 11:55:18 -0500	[thread overview]
Message-ID: <525438F6.3090600@gmail.com> (raw)
In-Reply-To: <CAErSpo5=sUJDZGm+zHw+b1h_a1YYbaGBshAutAoPBZYUCRbYkw@mail.gmail.com>

On 10/08/2013 11:32 AM, Bjorn Helgaas wrote:
> [+cc Grant, Rob, devicetree list]
> 
> On Tue, Oct 8, 2013 at 8:42 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> Hello,
>>
>> I am working on adding PCIe support for a new architecture and looking
>> at various existing implementations of pcibios functions I've realised
>> that some architectures share a lot of common code. As I don't like to
>> repeat the pattern again without any good reasons, I am wondering if
>> there is any appetite for carving out those common functions into
>> a generic place under drivers/pci/pcibios.c where they can be reused.
>>
>> Things that I am specifically looking at are pcibios_{alloc,free}_controller,
>> pci_process_bridge_OF_ranges and anything that will make adding support
>> for PCI/PCIe in a new architecture easier. Candidates for promoting
>> to a generic place are the functions found in both powerpc and microblaze
>> as they seem to be mostly identical, they support DT bindings and are
>> 64bits ready.
> 
> I'm very much in favor of unifying code to reduce duplication across
> architectures.
> 
> In general, the pcibios_*() interfaces are things used by the PCI core
> (drivers/pci) but implemented by the architecture.  The specific cases
> you mentioned are not actually used by the PCI core, so my inclination
> would be to name them something else and possibly put them somewhere
> other than drivers/pci.
> 
> I wonder if pci_process_bridge_OF_ranges() would fit somewhere in
> drivers/of?  The implementations I looked at are mostly concerned with
> parsing OF resources, and they don't have much to do with PCI
> directly.

This was being done until Ben weighed in:

https://lkml.org/lkml/2013/5/4/103

Rob

> pcibios_alloc_controller() is implemented by microblaze, powerpc, and
> xtensa.  Each of those arches defines its own "struct pci_controller",
> so it won't be completely trivial to unify this.  I tried to start
> some unification with the "struct pci_host_bridge" in the core, but
> haven't made much progress there.
> 
> Bjorn
> 


  reply	other threads:[~2013-10-08 16:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-08 14:42 [RFC] Architecture independent pcibios? Liviu Dudau
2013-10-08 16:32 ` Bjorn Helgaas
2013-10-08 16:32   ` Bjorn Helgaas
2013-10-08 16:55   ` Rob Herring [this message]
2013-10-08 17:20     ` Andrew Murray
2013-10-08 20:32       ` Benjamin Herrenschmidt
2013-10-08 20:28     ` Benjamin Herrenschmidt
2013-10-09  9:09       ` Liviu Dudau
2013-10-09 10:04         ` Liviu Dudau
2013-10-09 10:37         ` Benjamin Herrenschmidt
2013-10-09 10:45           ` Liviu Dudau
2013-10-09 14:30             ` Bjorn Helgaas
2013-10-09 16:23               ` Liviu Dudau
2013-10-15 11:48         ` Grant Likely
2013-10-08 17:13   ` Liviu Dudau
2013-10-08 18:58     ` Bjorn Helgaas
2013-10-08 20:31     ` Benjamin Herrenschmidt
2013-10-09 11:52       ` Michal Simek

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=525438F6.3090600@gmail.com \
    --to=robherring2@gmail.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=monstr@monstr.eu \
    --cc=olof@lixom.net \
    /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.