On Thu, Aug 07, 2014 at 03:47:24AM +0200, Javier Martinez Canillas wrote: > Hello Tomasz, > > Thanks a lot for your feedback. > > On 08/07/2014 03:14 AM, Tomasz Figa wrote: > > Hi Javier, > > > > > > Have you observed an actual failure due to this? I believe that > > Yes, I found this issue since the driver was not taking into account the value > defined in the edge/level type cells from the "interrupts" DT property. > > Only doing the change in the following patch was not enough: > > [PATCH 1/1] ARM: dts: Add Peach Pit and Pi dts entry for atmel touchpad [0]. > > > irq_of_parse_and_map() already sets up IRQ trigger type based on DT > > data, by calling irq_create_of_mapping() which in turn calls > > irq_set_irq_type(). > > > > Right but somehow when the IRQ is actually requested the type is overwritten by > the value passed to request_threaded_irq() and interrupts are not being > generated by the device without this patch. > > Do you think that this is a bug in the "interrupt-parent" irqchip driver or the > IRQ core? I'm not that familiar with the IRQ subsystem. No, this is clearly driver fault - it smashed previously done setup with new flags. > > >> > >> + if (client->dev.of_node) > >> + irqflags = irq_get_trigger_type(client->irq); > > > > It might be a bit cleaner to just assign the flags to pdata->irqflags in > > mxt_parse_dt() instead. That would also account for the fact that pdata, > > if provided, should have priority over DT. > > > > You are totally right, also this will break if CONFIG_OF is not enabled since > dev.of_node will not be defined. While this already is taken into account for > mxt_parse_dt() by defining an empty function. > > I'll change it in v2 if getting the flags from the driver is the right approach Yes, please. > instead of fixing the irqchip driver or the IRQ core. Thanks. -- Dmitry -- 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
