Hi Andreas!

On Thursday 22 August 2013 at 15:16:18, Andreas Larsson wrote:
> On 2013-08-21 15:38, Lars Poeschel wrote:
> > +static void of_gpio_scan_irq_lines(const struct device_node *const
> > node, +                                struct device_node *const gcn,
> > +                              struct irq_domain *const irq_domain,
> > +                              const u32 intsize,
> > +                              const struct gpio_chip * const gc,
> > +                              bool request)
> > +{
> > +   struct device_node *child;
> > +   struct device_node *irq_parent;
> > +   const __be32 *intspec;
> > +   u32 intlen;
> > +   int ret;
> > +   int i;
> > +   irq_hw_number_t hwirq;
> > +   unsigned int type;
> > +
> > +   if (node == NULL)
> > +           return;
> > +
> > +   for_each_child_of_node(node, child) {
> > +           of_gpio_scan_irq_lines(child, gcn, irq_domain, intsize, gc,
> > +                                  request);
> > +           /* Check if we have an IRQ parent, else continue */
> > +           irq_parent = of_irq_find_parent(child);
> 
> Hi!
> 
> This call to of_irq_find_parent breaks gpiolib-of for SPARC due to the
> fact that the function is undefined when !defined(CONFIG_OF_IRQ) &&
> defined(CONFIG_OF).
> 
> Defining the empty of_irq_find_parent in include/linux/of_irq.h when
> !defined(CONFIG_OF_IRQ) instead of the current case when
> !defined(CONFIG_OF) would solve the immediate compilation problem.

Is this a bug and should be fixed ?

> However, when !defined(CONFIG_OF_IRQ) (i.e. SPARC in this case) the
> whole tree walking will never accomplish anything, so it would be good
> if of_gpiochip_reserve_irq_lines is just an empty dummy or something
> like that when !defined(CONFIG_OF_IRQ).

You are right. I'll consider this in the next spin.

Thanks,
Lars
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to