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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html