On 01/06/2016 01:34 PM, Rob Herring wrote: > On Wed, Jan 6, 2016 at 8:36 AM, Nishanth Menon <n...@ti.com> wrote: >> On 01/06/2016 02:13 AM, Laxman Dewangan wrote: >>> >>> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote: >>>> Hi, >>>> >>>> Am 06.01.2016 um 00:40 schrieb Nishanth Menon <n...@ti.com>: >>>> >>>>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote: >>>>>> + rtc { >>>>>> + compatible = "ti,palmas-rtc"; >>>>>> + interrupt-parent = <&palmas>; >>>>>> + interrupts = <8 IRQ_TYPE_NONE>; >>>>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if >>>>> it had none, there'd be no interrupt, right? >>>> Well, it just translates IRQ_TYPE_NONE through >>>> >>>> Linux/include/dt-bindings/interrupt-controller/irq.h >>>> >>>> to >>>> >>>> interrupts = <8 0>; >>>> >>>> which is given as an example in >>>> >>>> Documentation//devicetree/bindings/rtc/rtc-palmas.txt >>>> >>>> Since I don't know anything about the rtc driver beyond the bindings >>>> documentation I assume it is correct... >>>> I have added Laxman Dewangan because he introduced this interrupts = >>>> <8 0>; >>>> >>> >>> As this is for palmas interrupt controller, it does not use the second >>> field for interrupt from RTC. >>> So there is no really any polarity. It can be set to 0. >>> >>> The second argument will be used for GPIOs mainly. However, support need >>> to be added on GPIO driver for rising/falling configuration. >> >> >> Device tree represents the hardware - not to reflect how the driver >> works. if the driver is wrong, fix it. the interrupt polarity needs to >> be described in DT. based on palmas like designs, you should probably >> use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside >> the SoC as it reaches Secondary interrupt handlers(SIH) registers. > > If the trigger type is not programmable, then not setting the trigger > type in the DT is fine. Internal connections are often not documented. >
Weird, that is not what I got feedback when I send https://patchwork.ozlabs.org/patch/381125/ If this is the new norm, I retract my objection. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html