linux-kernel - Re: [PATCH] ARM: Orion: Hoist bridge interrupt handling out of the timer

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]

Date:	Tue, 4 Jun 2013 11:26:38 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Cc:	Andrew Lunn <andrew@...n.ch>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Jason Cooper <jason@...edaemon.net>,
	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] ARM: Orion: Hoist bridge interrupt handling out of the
 timer

On Sun, Dec 09, 2012 at 02:06:48PM +0100, Sebastian Hesselbarth wrote:

> The main irq controller will be required for sure, but for the secondary
> irq controller we had a discussion long ago. IIRC Gregory proposed to have
> shared irqs handled by timer and watchdog, I was proposing chained irqs.

+1 on decoded IRQs for bridge. I've been running that configuration
now since this patch set was first posted.

There is too much HW variance, the timer, watchdog, etc drivers should
not have to poke into SOC specific registers just to get an interrupt.

The bridge decode can either be via a chained handler, or by incorporating
the bridge decode into the main kirkwood handler - the latter having
lower overhead for timer ticks.

> For mvebu archs, IIRC, we have wrt to timer-related irqs:
> - Armada 370/XP with different irq handler and timer irq handling within
>   timer registers.
> - Orion SoCs with Bridge irq registers for timer related stuff (timer0/1)
> - Kirkwood and Dove with watchdog timers (both with wdt irq in bridge irqs)
> - RTC in bridge irqs, but Dove with RTC connected to PMU irqs

> I think we should have patches for irqchip-orion first and then rethink
> if we want a standalone timer-orion or merge it with timer-mvebu. Having
> watchdog using irqs is kind of independent from this.

I would think the logical progression is:
- irq-chip orion combined with work to keep the existing timer working
- Patch to add the bridge irq-chip
- Patches to support orion/kirkwood/dove/etc in the existing timer drivers
- Patch to update the DT to switch to the bridge and updated timer
- Patch to remove the old timer

When I last looked briefly, it seems like merging with timer-mvebu was
fairly straightforward..

> Back in the days when Gregory, Thomas, and I were looking into merged timer
> we agreed not to have an extra check on 25MHz support. If you put the
> property in the node, it will try to set the timer to fixed 25MHz. If you
> use the property on Orion timer, it will just break timer handling.

As for the mveth case we should have a compatible tag for each SOC,
the driver can ignore it, but it should be in the DT for future use..

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/