On Wednesday 04 June 2014 10:58:15 Ben Dooks wrote:
> On 03/06/14 16:40, Rob Herring wrote:
> > On Tue, Jun 3, 2014 at 9:47 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> >> This replaces "[PATCH v2] of/irq: provide int of_irq_parse_and_map_pci
> >> wrapper", since now the same driver requires additional interfaces.
> >> We still want to be able to build the driver with CONFIG_OF disabled,
> >> but now we need three functions instead of just one.
> >>
> >> Rob, Grant, can you apply this as a bug fix, or provide comments?
> >>
> >> diff --git a/include/linux/of.h b/include/linux/of.h
> >> index 196b34c..7c29e6c 100644
> >> --- a/include/linux/of.h
> >> +++ b/include/linux/of.h
> >> @@ -511,6 +511,9 @@ static inline struct device_node *of_get_cpu_node(int cpu,
> >> return NULL;
> >> }
> >>
> >> +static inline int of_n_addr_cells(struct device_node *np) { return 0; }
> >> +static inline int of_n_size_cells(struct device_node *np) { return 0; }
> >
> > I'm fine with the rest, but I think these should always be used within
> > some higher level function.
> >
> > I can't seem to find where this is used by rcar. BTW, why does rcar
> > pci DT support fail to have any ranges property?
>
> I think the driver provides all the necessary PCI information
> internally as it started off as a platform-driver.
Actually it gets the memory resource from the 'reg' property instead
of parsing the 'ranges' property, which of course is not compliant
with the generic PCI binding.
It also sets up an I/O resource that is located at the same location
as the memory resource, which is just a bug but might be used to
work around problems of the PCI core when no I/O resource is present.
I think that should be fixed.
I also see that the ranges parser in the pcie-rcar driver still gets
I/O space wrong, we should probably move that to a common range
parser once the arm64 pci implementation is in place and we can
share more of the common helpers.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
