linux-kernel - [PATCH 0/9] Get rid of FIQ_START/enable/disable

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-next>] [day] [month] [year] [list]

Message-ID: <20120805230238.GA1663@lizard>
Date:	Sun, 5 Aug 2012 16:02:38 -0700
From:	Anton Vorontsov <anton.vorontsov@...aro.org>
To:	Russell King <linux@....linux.org.uk>
Cc:	John Stultz <john.stultz@...aro.org>, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linaro-kernel@...ts.linaro.org, patches@...aro.org,
	kernel-team@...roid.com, Ben Dooks <ben-linux@...ff.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Sascha Hauer <kernel@...gutronix.de>,
	Tony Lindgren <tony@...mide.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...com>
Subject: [PATCH 0/9] Get rid of FIQ_START/enable/disable_fiq() + some FIQ
 cleanups

Hello Russell,

During KDB FIQ patches review you mentioned that I should not introduce
another FIQ_START. It seems that in v3.6-rc the FIQ_START issue was
somewhat band-aided, i.e. machines don't necessary need to define this
stuff any longer, but I also read the background of the issue, and you
once said that you don't want the FIQ subsystem to mess with genirq.

It is surely makes sense as FIQs are arch-specific, plus FIQs are special
in that way that platform makers are free to connects device directly
to the FIQ line, avoiding IC routing, and then enable_fiq(<IRQ>) would
look awkward, at the best.

So, given that, it seems that the only entity that knows for sure how
the particular FIQ is routed is whoever claims the FIQ and fills-in the
fiq_handler struct. It might make sense to introduce disable/enable
callbacks in the fiq_handler struct, and then prototypes for disable/
enable FIQ calls would look like this:

	enable_fiq(struct fiq_handler *fh);
	disable_fiq(struct fiq_handler *fh);

I.e. completely abstracted from the genirq.

Although, to not duplicate IC code, I think it's pretty legitimate to
call genirq functions iff the caller knows for sure that FIQ comes from
IRQ line and it is is routed through the well-known platform IC.

In that case (which is a majority), the typical user would do this:

	static int irq_line;

	void foo_enable_fiq(struct fiq_handler *fh)
	{
		enable_irq(irq_line);
	}

	static struct fiq_handler foo_fiq = {
		.name = "foo",
		.enable_fiq = foo_enable_fiq,
	};

	claim_fiq(&foo_fiq);
	enable_fiq(&foo_fiq);

Obviously, it's needless indirection, so I don't do this. If we ever
pass 'foo_fiq' to some device, which does not know all the routing
details, then it would make sense to introduce it, but not now.

So, the patch set is pretty straightforward:

- Get rid of FIQ_START. Nobody but platform-specific code (and drivers)
  should know the details about which interrupt can be routed to FIQ
  and which cannot;

- Remove disable/enable_fiq() calls from the FIQ subsys (the calls can
  be reintroduced w/ new prototypes when/if needed).

Does the approach make sense?

Thanks!

--
 arch/arm/include/asm/fiq.h                |    2 --
 arch/arm/include/asm/mach/irq.h           |    9 +++++++--
 arch/arm/kernel/fiq.c                     |   22 +++-------------------
 arch/arm/kernel/irq.c                     |    2 --
 arch/arm/mach-rpc/dma.c                   |    4 ++--
 arch/arm/mach-rpc/include/mach/irqs.h     |    8 ++++----
 arch/arm/mach-rpc/irq.c                   |   21 +++++----------------
 arch/arm/mach-s3c24xx/include/mach/irqs.h |    3 ---
 arch/arm/plat-mxc/avic.c                  |    4 +---
 arch/arm/plat-mxc/include/mach/irqs.h     |    2 --
 arch/arm/plat-mxc/tzic.c                  |    4 +---
 arch/arm/plat-omap/include/plat/irqs.h    |    4 ----
 arch/arm/plat-s3c24xx/irq.c               |    6 ++----
 drivers/media/video/mx1_camera.c          |    6 +++---
 sound/soc/fsl/imx-pcm-fiq.c               |    4 ++--
 15 files changed, 30 insertions(+), 71 deletions(-)

-- 
Anton Vorontsov
Email: cbouatmailru@...il.com
--
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/