[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130213212951.GA27849@avionic-0098.mockup.avionic-design.de>
Date: Wed, 13 Feb 2013 22:29:51 +0100
From: Thierry Reding <thierry.reding@...onic-design.de>
To: Rob Herring <robherring2@...il.com>
Cc: Grant Likely <grant.likely@...retlab.ca>,
Andrew Murray <andrew.murray@....com>,
devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] of/pci: Provide support for parsing PCI DT ranges
property
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@....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.
So unless we want to block any new drivers from being merged, the only
alternatives are to either merge these patches or include a copy of the
same code in each new driver that needs the functionality (or open-code
the functions in each driver).
There is quite a bit of rework required to unify the architecture
specific PCI frameworks and I think Bjorn and others have been making
quite a bit of progress in that direction. I think that these patches
can help refactor some of those parts.
Thierry
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists