linux-kernel - Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send

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:	Wed, 26 Aug 2015 15:19:44 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Qais Yousef <qais.yousef@...tec.com>
cc:	Marc Zyngier <marc.zyngier@....com>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	Jason Cooper <jason@...edaemon.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
	Mark Rutland <Mark.Rutland@....com>
Subject: Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi

On Wed, 26 Aug 2015, Qais Yousef wrote:
> Can we replace 'something' in interrupt-source and interrupt-sink definitions
> to 'host' or 'CPU' or do we really care about creating IPI between any 2
> 'things'?
> 
> Changing the definition will also make interrupt-sink a synonym/alias to
> interrupts property. So the description will become
> 
> axd: axd {
>         interrupt-source = <&gic GIC_SHARED 36 IRQ_TYPE_EDGE_RISING>; /*
> interrupt from CPU to AXD */
>         interrupt-sink = <&gic GIC_SHARED 37 IRQ_TYPE_EDGE_RISING>; /*
> interrupt from AXD to CPU */
> }
> 
> But this assume Linux won't take care of the routing. If we want Linux to take
> care of the routing, maybe something like this then?
> 
> axd: axd {
>         interrupt-source = <&gic GIC_SHARED 36 IRQ_TYPE_EDGE_RISING
> HWAFFINITY1>; /* interrupt from CPU to
> AXD@...FFINITY1*/
>         interrupt-sink = <&gic GIC_SHARED 37 IRQ_TYPE_EDGE_RISING
> HWAFFINITY2>; /* interrupt from AXD to CPU@...FFINITY2 */
> }
> 
> I don't think it's necessary to specify the HWAFFINITY2 for interrupt-sink as
> linux can use SMP affinity to move it around but we can make it optional in
> case there's a need to hardcode it to a specific Linux core. Or maybe the
> driver can use affinity hint..

Wrong. You cannot move an IPI around with set_affinity. It's possible
to send an IPI to more than one target CPU, but that has nothing to do
with affinities.

Are you talking about IPIs or about general interrupts which have an
affinity setting?

> Any pointers on the best way to tie gic_send_ipi() with the driver/core code?
> The way it's currently tied to the core code is through SMP IPI functions
> which I don't think we can use. I'm thinking adding a pointer function in
> struct irq_chip would be the easiest approach maybe?

That's the least of our worries. We need to get the high level
interfaces and the devicetree mechanism straight before we talk about
this kind of details.

Thanks,

	tglx
--
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/