linux-kernel - Re: [RESEND PATCH v2 17/33] ARM: davinci: aintc: move timer-specific irq_set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <67127a57-3d1f-5cf4-efb8-f1a2a49b3a2a@arm.com>
Date:   Mon, 11 Feb 2019 13:00:40 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     Bartosz Golaszewski <brgl@...ev.pl>, Sekhar Nori <nsekhar@...com>,
        Kevin Hilman <khilman@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        David Lechner <david@...hnology.com>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [RESEND PATCH v2 17/33] ARM: davinci: aintc: move timer-specific
 irq_set_handler() out of irq.c

On 11/02/2019 12:25, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@...libre.com>
> 
> I've been unable to figure out exactly why, but it seems that the
> IRQ_TINT1_TINT34 interrupt for timer 1 needs to be handled as a
> level irq, not edge like all others.

That's probably because its comparator maintains the interrupt asserted
as long as its value is less than the counter.

Level-trigger timers are the most common thing on this side of the known
universe.

> 
> Let's move the handler setup out of the aintc driver where it's lived
> since the beginning and into the dm* SoC-specific files where it
> belongs.
> 
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@...libre.com>
> ---
>  arch/arm/mach-davinci/dm355.c  | 8 ++++++++
>  arch/arm/mach-davinci/dm365.c  | 8 ++++++++
>  arch/arm/mach-davinci/dm644x.c | 8 ++++++++
>  arch/arm/mach-davinci/dm646x.c | 8 ++++++++
>  arch/arm/mach-davinci/irq.c    | 3 ---
>  5 files changed, 32 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
> index c7cd765114af..a732f2ea1d9a 100644
> --- a/arch/arm/mach-davinci/dm355.c
> +++ b/arch/arm/mach-davinci/dm355.c
> @@ -15,6 +15,7 @@
>  #include <linux/dma-mapping.h>
>  #include <linux/dmaengine.h>
>  #include <linux/init.h>
> +#include <linux/irq.h>
>  #include <linux/irqchip/irq-davinci-aintc.h>
>  #include <linux/platform_data/edma.h>
>  #include <linux/platform_data/gpio-davinci.h>
> @@ -744,6 +745,13 @@ void __init dm355_init_time(void)
>  	psc = ioremap(DAVINCI_PWR_SLEEP_CNTRL_BASE, SZ_4K);
>  	dm355_psc_init(NULL, psc);
>  
> +	/*
> +	 * Nobody knows why anymore, but this interrupt has been handled as
> +	 * a level irq from the very beginning of davinci support in mainline
> +	 * linux.
> +	 */
> +	irq_set_handler(DAVINCI_INTC_IRQ(IRQ_TINT1_TINT34), handle_level_irq);
> +

Now, the real question is: why isn't that set as part of the
set_irq_type() callback, instead of hardcoding it in the platform?

This is exactly the kind of information that should come as part of the
DT or from the driver as one of the request_irq() flags.

It would save quite a bit of boilerplate code.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...