On 15/06/2013, at 00:00, Grant Likely <[email protected]> wrote:
> On Wed, 05 Jun 2013 20:20:39 +0200, Tomasz Figa <[email protected]> wrote: >> Hi, >> >> On Sunday 19 of May 2013 00:56:30 Tomasz Figa wrote: >>> Some drivers might rely on availability of trigger flags in IRQ >>> resource, for example to configure the hardware for particular interrupt >>> type. However current code creating IRQ resources from data in device >>> tree does not configure trigger flags in resulting resources. >>> >>> This patch solves the problem, based on the fact that >>> irq_of_parse_and_map() configures the trigger based on DT interrupt >>> specifier, IRQD_TRIGGER_* flags are consistent with IORESOURCE_IRQ_*, >>> and we can get trigger type by calling irqd_get_trigger_type() after >>> mapping the interrupt. >>> >>> Signed-off-by: Tomasz Figa <[email protected]> >>> --- >>> drivers/of/irq.c | 10 ++++++++++ >>> 1 file changed, 10 insertions(+) >>> >>> diff --git a/drivers/of/irq.c b/drivers/of/irq.c >>> index a3c1c5a..79a7a26 100644 >>> --- a/drivers/of/irq.c >>> +++ b/drivers/of/irq.c >>> @@ -355,6 +355,16 @@ int of_irq_to_resource(struct device_node *dev, int >>> index, struct resource *r) r->start = r->end = irq; >>> r->flags = IORESOURCE_IRQ; >>> r->name = name ? name : dev->full_name; >>> + >>> + /* >>> + * Some drivers might rely on availability of trigger >> flags >>> + * in IRQ resource. Since irq_of_parse_and_map() >> configures the >>> + * trigger based on interrupt specifier and IRQD_TRIGGER_* >>> + * flags are consistent with IORESOURCE_IRQ_*, we can get >>> + * trigger type that was just set and pass it through >> resource >>> + * flags as well. >>> + */ >>> + r->flags |= irqd_get_trigger_type(irq_get_irq_data(irq)); >>> } >>> >>> return irq; >> >> Any comments on this patch? > > That's actually a pretty good solution and a whole lot less invasive > that the approach that Javier was pursuing. Javier, I'm going to pick > up this patch. Please yell if it doesn't solve the problem that you're > trying to solve. > > g. > It solves the issue I was trying to solve and the solution is indeed more elegant and simpler than the one I posted. Thanks a lot for pointing this out. Best regards, Javier-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
