From: Thierry Reding <thierry.reding@avionic-design.de>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <robherring2@gmail.com>,
Andrew Murray <andrew.murray@arm.com>,
devicetree-discuss@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] of/pci: Provide support for parsing PCI DT ranges property
Date: Thu, 14 Feb 2013 08:05:20 +0100 [thread overview]
Message-ID: <20130214070520.GA29864@avionic-0098.mockup.avionic-design.de> (raw)
In-Reply-To: <20130213220956.DDEB43E3557@localhost>
[-- Attachment #1: Type: text/plain, Size: 3800 bytes --]
On Wed, Feb 13, 2013 at 10:09:56PM +0000, Grant Likely wrote:
> On Wed, 13 Feb 2013 22:29:51 +0100, Thierry Reding <thierry.reding@avionic-design.de> wrote:
> > On Wed, Feb 13, 2013 at 01:54:53PM -0600, Rob Herring wrote:
> > > On 02/13/2013 08:25 AM, Thierry Reding wrote:
> > > > On Wed, Feb 13, 2013 at 08:23:28AM -0600, Rob Herring wrote:
> > > >> On 02/12/2013 12:45 AM, Thierry Reding wrote:
> > > >>> On Mon, Feb 11, 2013 at 01:43:03PM -0600, Rob Herring wrote:
> > > >>>> On 02/11/2013 02:22 AM, Thierry Reding wrote:
> > > >>>>> From: Andrew Murray <andrew.murray@arm.com>
> > > >>
> > > >>>>> @@ -13,6 +13,7 @@
> > > >>>>> #define OF_CHECK_COUNTS(na, ns) (OF_CHECK_ADDR_COUNT(na) && (ns) > 0)
> > > >>>>>
> > > >>>>> static struct of_bus *of_match_bus(struct device_node *np);
> > > >>>>> +static struct of_bus *of_find_bus(const char *name);
> > > >>>>
> > > >>>> Can you move this function up to avoid the forward declaration.
> > > >>>
> > > >>> It needs to be defined after the of_busses structure, which is defined
> > > >>> below the CONFIG_PCI block where of_pci_process_ranges() is defined. I'd
> > > >>> have to move that one as well and add another #ifdef CONFIG_PCI section.
> > > >>> If you prefer that I can do that.
> > > >>
> > > >> Okay, it's fine as is.
> > > >>
> > > >>>>> +static struct of_bus *of_find_bus(const char *name)
> > > >>>>> +{
> > > >>>>> + unsigned int i;
> > > >>>>> +
> > > >>>>> + for (i = 0; i < ARRAY_SIZE(of_busses); i++)
> > > >>>>> + if (strcmp(name, of_busses[i].name) == 0)
> > > >>>> ^
> > > >>>> space needed.
> > > >>>
> > > >>> I don't understand. Do you want the space to go between '.' and "name"?
> > > >>
> > > >> Must have been some dirt on my screen... Never mind.
> > > >>
> > > >> I'll apply these for 3.9.
> > > >
> > > > Great, thanks!
> > >
> > > Grant vetoed merging. We need to see the other architectures using these
> > > functions rather than add yet another copy.
> >
> > I think I've said this before, but converting the other architectures
> > isn't very trivial, mostly because each has a specific way of storing
> > the values read from these properties.
>
> Sorry to be harsh, but this isn't new information. I've had to deal with
> the pain more than once before of copied infrastructure that at some
> time in the future needs to be merged again. Just looking at your patch
> I can tell that it is directly derived from the powerpc
> pci_process_bridge_OF_ranges() and which microblaze has already has a
> verbatum copy of.
>
> So, no, I'm not okay with it for v3.9. I don't want more copies of the
> same code. This doesn't block your v3.10 drivers. When a better patch is
> ready we can set up a separate branch with just the new functions in it
> and the various subsystems can merge that in if needed to resolve
> dependencies.
>
> Instead, here is what you do; you've got the bones of a good approach,
> but you need to show how it is derived from the powerpc approach. I'll
> reply in specifics to the patches themselves, but I can definitely see
> large blocks of code that can be moved out of powerpc & microblaze and
> into drivers/of/address.c without getting into the platform-specific
> PCI representations that you're concerned about.
>
> Now, to be clear here, I'm asking you to change powerpc/microblaze code,
> but I am *not asking you to test it*. This is a code move exercises, and
> I will help you with it if you need.
Alright. I have no idea about how this is going to affect the timeframe,
though. Granted, this doesn't sound as painful as I had assumed, but it
is quite a bit of work and I have to see how I can squeeze it in with
everything else.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-02-14 7:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-11 8:22 [PATCH 0/4] Various PCI-related device tree helpers Thierry Reding
2013-02-11 8:22 ` [PATCH 1/4] of/pci: Provide support for parsing PCI DT ranges property Thierry Reding
2013-02-11 19:43 ` Rob Herring
2013-02-12 6:45 ` Thierry Reding
2013-02-13 14:23 ` Rob Herring
2013-02-13 14:25 ` Thierry Reding
2013-02-13 19:54 ` Rob Herring
2013-02-13 21:29 ` Thierry Reding
2013-02-13 22:09 ` Grant Likely
2013-02-14 7:05 ` Thierry Reding [this message]
2013-02-13 22:53 ` Grant Likely
2013-02-14 16:53 ` Andrew Murray
2013-02-14 19:17 ` Thierry Reding
2013-02-15 4:52 ` Thomas Petazzoni
2013-02-15 13:16 ` Linus Walleij
2013-02-18 9:38 ` Andrew Murray
2013-02-11 8:22 ` [PATCH v2 2/4] of/pci: Add of_pci_get_devfn() function Thierry Reding
2013-02-13 22:59 ` Grant Likely
2013-02-14 6:52 ` Thierry Reding
2013-02-11 8:22 ` [PATCH 3/4] of/pci: Add of_pci_get_bus() function Thierry Reding
2013-02-13 22:56 ` Grant Likely
2013-02-14 6:52 ` Thierry Reding
2013-02-11 8:22 ` [PATCH 4/4] of/pci: Add of_pci_parse_bus_range() function Thierry Reding
2013-02-13 22:58 ` Grant Likely
2013-02-14 6:52 ` Thierry Reding
2013-02-13 13:48 ` [PATCH 0/4] Various PCI-related device tree helpers Thomas Petazzoni
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=20130214070520.GA29864@avionic-0098.mockup.avionic-design.de \
--to=thierry.reding@avionic-design.de \
--cc=andrew.murray@arm.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=robherring2@gmail.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).