On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring <robherring2@xxxxxxxxx> wrote: > On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote: >> On 04/09/2013 12:16 AM, Stephen Warren wrote: >>> On 04/08/2013 04:05 PM, Rob Herring wrote: >>>> On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote: >>>>> According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >>>>> the "#interrupt-cells" property of an "interrupt-controller" is used >>>>> to define the number of cells needed to specify a single interrupt. >>> ... >>>>> But the type is never returned so it can't be saved on the IRQ struct >>>>> resource flags member. >>>>> >>>>> This means that drivers that need the IRQ type/level flags defined in >>>>> the DT won't be able to get it. >>>> >>>> But the interrupt controllers that need the information should be able >>>> to get to it via irqd_get_trigger_type. What problem exactly are you >>>> trying to fix? What driver would use this? >>> >>> FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking >>> back, I'm not sure if that was the right thing or whether I should have >>> sent this same patch:-) >>> >> >> Hi Stephen, >> >> I'm glad you agree :-) >> >> I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for >> the IRQ with irqd_get_trigger_type() but I prefer $subject because: > > irqd_get_trigger_type probably is not meant for outside of irqchips. > Creating an irq_get_irq_type function which takes an irq number would be > the right function as that does not expose struct irq_data. > Hi Rob, I sent a patch-set a few days ago that adds an irq_get_irq_type() function [1] as you suggested and this function is used on the smsc911x driver probe function to get the edge/level flags [2]. It would be great if I can get your feedback on this. Thanks a lot and best regards, Javier [1]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/97117 [2]: http://permalink.gmane.org/gmane.linux.network/265587 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
