From: Arnd Bergmann <arnd@arndb.de>
To: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
"linux-pci" <linux-pci@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Will Deacon <Will.Deacon@arm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"linaro-kernel" <linaro-kernel@lists.linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
LAKML <linux-arm-kernel@lists.infradead.org>,
Tanmay Inamdar <tinamdar@apm.com>,
Grant Likely <grant.likely@secretlab.ca>
Subject: Re: [PATCH v7 3/3] arm64: Add architecture support for PCI
Date: Fri, 14 Mar 2014 20:10:39 +0100 [thread overview]
Message-ID: <201403142010.39886.arnd@arndb.de> (raw)
In-Reply-To: <20140314180527.GZ6457@e106497-lin.cambridge.arm.com>
On Friday 14 March 2014, Liviu Dudau wrote:
> >
>
> I haven't seen any reaction from Bjorn on this, so I threaded carefully on that
> subject. I'm new to this so I don't know how to handle this.
>
> To my mind, and looking at the way every architecture has been setup, the pcibios_*
> function are intended to be provided by the architecture.
That is definitely correct.
> No matter how much wishful
> thinking we are going to put in here, it will not change the fact that the non-arm64
> specific version of pcibios_fixup_bus() that I wrote is not shared by anyone else
> and it will remain "for arm64 use only" regardless to where it is placed until the
> next architecture comes into the kernel. And even then its adoption is questionable.
Agreed as well.
> If we are looking for simple and common implementations of this function, maybe we
> should look at why microblaze and powerpc versions, that are identical, are not being
> made the default __weak implementation.
Microblaze could most likely just be moved over to your version. The only
reason it is shared with the powerpc implementation is that they were
anticipating the code to become shared again and that it was known to
be working with flattened device tree.
> As for the other two functions, I've no special attachment to where they are present
> and I'm happy to move them into drivers/pci on the condition that the patchset doesn't
> double in size. The reason why I'm weary of touching other architectures in a significant
> way is the current lack of engineering bandwidth and way of testing all the architectures.
> My low friction approach has been to introduce them in arm64 and then slowly move them
> into core (and yes, I know about good intentions and the road to hell.)
I think everyone working on PCI is fed up with having arch-specific implementations
of all these, and Bjorn has been very supportive of generic infrastructure in the
past. Even just adding a generic infrastructure in a common place that is used
only by one architecture in my mind would be a significant improvement.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 3/3] arm64: Add architecture support for PCI
Date: Fri, 14 Mar 2014 20:10:39 +0100 [thread overview]
Message-ID: <201403142010.39886.arnd@arndb.de> (raw)
In-Reply-To: <20140314180527.GZ6457@e106497-lin.cambridge.arm.com>
On Friday 14 March 2014, Liviu Dudau wrote:
> >
>
> I haven't seen any reaction from Bjorn on this, so I threaded carefully on that
> subject. I'm new to this so I don't know how to handle this.
>
> To my mind, and looking at the way every architecture has been setup, the pcibios_*
> function are intended to be provided by the architecture.
That is definitely correct.
> No matter how much wishful
> thinking we are going to put in here, it will not change the fact that the non-arm64
> specific version of pcibios_fixup_bus() that I wrote is not shared by anyone else
> and it will remain "for arm64 use only" regardless to where it is placed until the
> next architecture comes into the kernel. And even then its adoption is questionable.
Agreed as well.
> If we are looking for simple and common implementations of this function, maybe we
> should look at why microblaze and powerpc versions, that are identical, are not being
> made the default __weak implementation.
Microblaze could most likely just be moved over to your version. The only
reason it is shared with the powerpc implementation is that they were
anticipating the code to become shared again and that it was known to
be working with flattened device tree.
> As for the other two functions, I've no special attachment to where they are present
> and I'm happy to move them into drivers/pci on the condition that the patchset doesn't
> double in size. The reason why I'm weary of touching other architectures in a significant
> way is the current lack of engineering bandwidth and way of testing all the architectures.
> My low friction approach has been to introduce them in arm64 and then slowly move them
> into core (and yes, I know about good intentions and the road to hell.)
I think everyone working on PCI is fed up with having arch-specific implementations
of all these, and Bjorn has been very supportive of generic infrastructure in the
past. Even just adding a generic infrastructure in a common place that is used
only by one architecture in my mind would be a significant improvement.
Arnd
next prev parent reply other threads:[~2014-03-14 19:10 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-14 15:34 [PATCH v7 0/3] Add support for PCI in AArch64 Liviu Dudau
2014-03-14 15:34 ` Liviu Dudau
2014-03-14 15:34 ` Liviu Dudau
2014-03-14 15:34 ` [PATCH v7 1/3] Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases Liviu Dudau
2014-03-14 15:34 ` Liviu Dudau
2014-03-14 15:34 ` [PATCH v7 2/3] arm64: Extend the PCI I/O space to 16MB Liviu Dudau
2014-03-14 15:34 ` Liviu Dudau
2014-03-14 15:34 ` [PATCH v7 3/3] arm64: Add architecture support for PCI Liviu Dudau
2014-03-14 15:34 ` Liviu Dudau
2014-03-14 17:14 ` Catalin Marinas
2014-03-14 17:14 ` Catalin Marinas
2014-03-14 17:38 ` Arnd Bergmann
2014-03-14 17:38 ` Arnd Bergmann
2014-03-14 17:38 ` Arnd Bergmann
2014-03-14 18:05 ` Liviu Dudau
2014-03-14 18:05 ` Liviu Dudau
2014-03-14 19:10 ` Arnd Bergmann [this message]
2014-03-14 19:10 ` Arnd Bergmann
2014-03-16 6:22 ` Benjamin Herrenschmidt
2014-03-16 6:22 ` Benjamin Herrenschmidt
2014-03-16 6:22 ` Benjamin Herrenschmidt
2014-03-17 17:38 ` Catalin Marinas
2014-03-17 17:38 ` Catalin Marinas
2014-03-17 18:05 ` Liviu Dudau
2014-03-17 18:05 ` Liviu Dudau
2014-03-19 13:56 ` Catalin Marinas
2014-03-19 13:56 ` Catalin Marinas
2014-03-19 17:21 ` Liviu Dudau
2014-03-19 17:21 ` Liviu Dudau
2014-03-19 17:53 ` Rob Herring
2014-03-19 17:53 ` Rob Herring
2014-03-19 17:53 ` Rob Herring
2014-03-19 18:36 ` Arnd Bergmann
2014-03-19 18:36 ` Arnd Bergmann
2014-03-19 18:37 ` Arnd Bergmann
2014-03-19 18:37 ` Arnd Bergmann
2014-03-20 9:46 ` Liviu Dudau
2014-03-20 9:46 ` Liviu Dudau
2014-03-20 11:17 ` Arnd Bergmann
2014-03-20 11:17 ` Arnd Bergmann
2014-03-20 11:38 ` Liviu Dudau
2014-03-20 11:38 ` Liviu Dudau
2014-03-20 12:26 ` Arnd Bergmann
2014-03-20 12:26 ` Arnd Bergmann
2014-03-20 12:26 ` Arnd Bergmann
2014-03-20 12:50 ` Liviu Dudau
2014-03-20 12:50 ` Liviu Dudau
2014-03-17 16:05 ` Rob Herring
2014-03-17 16:05 ` Rob Herring
2014-03-17 16:05 ` Rob Herring
2014-03-17 16:22 ` Liviu Dudau
2014-03-17 16:22 ` Liviu Dudau
2014-04-07 23:58 ` Bjorn Helgaas
2014-04-07 23:58 ` Bjorn Helgaas
2014-04-08 9:52 ` Liviu Dudau
2014-04-08 9:52 ` Liviu Dudau
2014-04-08 9:52 ` Liviu Dudau
2014-04-22 8:58 ` [PATCH v7 0/3] Add support for PCI in AArch64 Sandeepa Prabhu
2014-04-22 8:58 ` Sandeepa Prabhu
2014-04-22 10:11 ` Liviu Dudau
2014-04-22 10:11 ` Liviu Dudau
2014-04-22 10:11 ` Liviu Dudau
2014-04-22 11:50 ` Sandeepa Prabhu
2014-04-22 11:50 ` Sandeepa Prabhu
2014-04-22 12:34 ` Liviu Dudau
2014-04-22 12:34 ` Liviu Dudau
2014-04-23 20:32 ` Tanmay Inamdar
2014-04-23 20:32 ` Tanmay Inamdar
2014-04-24 3:08 ` Sandeepa Prabhu
2014-04-24 3:08 ` Sandeepa Prabhu
2014-05-16 10:33 ` Sunil Kovvuri
2014-05-16 10:33 ` Sunil Kovvuri
2014-05-16 13:24 ` Liviu Dudau
2014-05-16 13:24 ` Liviu Dudau
2014-05-16 13:24 ` Liviu Dudau
2014-05-16 17:42 ` Sunil Kovvuri
2014-05-16 17:42 ` Sunil Kovvuri
2014-05-21 11:15 ` Sunil Kovvuri
2014-05-21 11:15 ` Sunil Kovvuri
2014-05-21 11:34 ` Liviu Dudau
2014-05-21 11:34 ` Liviu Dudau
2014-05-21 11:34 ` Liviu Dudau
2014-05-21 17:06 ` Jason Gunthorpe
2014-05-21 17:06 ` Jason Gunthorpe
2014-05-21 17:06 ` Jason Gunthorpe
2014-05-19 13:01 ` Arnd Bergmann
2014-05-19 13:01 ` Arnd Bergmann
2014-05-20 4:22 ` Sunil Kovvuri
2014-05-20 4:22 ` Sunil Kovvuri
2014-05-20 8:44 ` Arnd Bergmann
2014-05-20 8:44 ` Arnd Bergmann
2014-05-20 8:44 ` Arnd Bergmann
2014-05-20 8:55 ` Sunil Kovvuri
2014-05-20 8:55 ` Sunil Kovvuri
2014-05-20 8:55 ` Sunil Kovvuri
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=201403142010.39886.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=Catalin.Marinas@arm.com \
--cc=Liviu.Dudau@arm.com \
--cc=Will.Deacon@arm.com \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@secretlab.ca \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=tinamdar@apm.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.