Message ID | 20170911200805.3363318-1-arnd@arndb.de (mailing list archive) |
---|---|
State | New, archived |
Delegated to: | Bjorn Helgaas |
Headers | show |
On Mon, Sep 11, 2017 at 3:07 PM, Arnd Bergmann <arnd@arndb.de> wrote: > The pci-rcar driver is enabled for compile tests, and this has > shown that the driver cannot build without CONFIG_OF, > following the inclusion of f8f2fe7355fb "PCI: rcar: Use new OF > interrupt mapping when possible": > > drivers/pci/host/pcie-rcar.c: In function 'pci_dma_range_parser_init': > drivers/pci/host/pcie-rcar.c:1039:2: error: implicit declaration of function 'of_n_addr_cells' [-Werror=implicit-function-declaration] > parser->pna = of_n_addr_cells(node); > ^ > As pointed out by Ben Dooks and Geert Uytterhoeven, this is actually > supposed to build fine, which we can achieve if we make the > declaration of of_irq_parse_and_map_pci conditional on CONFIG_OF > and provide an empty inline function otherwise, as we do for > a lot of other of interfaces. > > This lets us build the rcar_pci driver again without CONFIG_OF > for build testing. All platforms using this driver select OF, > so this doesn't change anything for the users. Sorry, I keep missing this. It's a flaw in my mail filtering... There's a patch series[1] to factor out pci_dma_range_parser_init of the driver which should also fix this. I'd prefer not to take this because ideally all address parsing should be within the DT core code. Rob [1] https://patchwork.kernel.org/patch/9927541/
Hi Rob, On Mon, Sep 18, 2017 at 11:28 PM, Rob Herring <robh+dt@kernel.org> wrote: > On Mon, Sep 11, 2017 at 3:07 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> The pci-rcar driver is enabled for compile tests, and this has >> shown that the driver cannot build without CONFIG_OF, >> following the inclusion of f8f2fe7355fb "PCI: rcar: Use new OF >> interrupt mapping when possible": >> >> drivers/pci/host/pcie-rcar.c: In function 'pci_dma_range_parser_init': >> drivers/pci/host/pcie-rcar.c:1039:2: error: implicit declaration of function 'of_n_addr_cells' [-Werror=implicit-function-declaration] >> parser->pna = of_n_addr_cells(node); >> ^ >> As pointed out by Ben Dooks and Geert Uytterhoeven, this is actually >> supposed to build fine, which we can achieve if we make the >> declaration of of_irq_parse_and_map_pci conditional on CONFIG_OF >> and provide an empty inline function otherwise, as we do for >> a lot of other of interfaces. >> >> This lets us build the rcar_pci driver again without CONFIG_OF >> for build testing. All platforms using this driver select OF, >> so this doesn't change anything for the users. > > Sorry, I keep missing this. It's a flaw in my mail filtering... > > There's a patch series[1] to factor out pci_dma_range_parser_init of > the driver which should also fix this. I'd prefer not to take this > because ideally all address parsing should be within the DT core code. > > Rob > > [1] https://patchwork.kernel.org/patch/9927541/ Yes, that looks like a better solution. (For those who didn't see the rest of the series: of_pci_dma_range_parser_init() in provided in of/address.c, and does have a dummy) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
diff --git a/include/linux/of.h b/include/linux/of.h index cfc34117fc92..fb700d1e1fab 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -734,6 +734,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; } + static inline int of_property_read_u64(const struct device_node *np, const char *propname, u64 *out_value) {