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, 02 Sep 2015 10:55:20 +0100
From:	Marc Zyngier <marc.zyngier@....com>
To:	Qais Yousef <qais.yousef@...tec.com>,
	Mark Rutland <Mark.Rutland@....com>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	"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>,
	Jiang Liu <jiang.liu@...ux.intel.com>,
	Mark Brown <broonie@...nel.org>,
	Lisa Parratt <Lisa.Parratt@...tec.com>
Subject: Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi

On 02/09/15 10:33, Qais Yousef wrote:
> On 08/28/2015 03:22 PM, Thomas Gleixner wrote:
>> On Fri, 28 Aug 2015, Qais Yousef wrote:
>>> Thanks a lot for the detailed explanation. I wasn't looking for a quick and
>>> dirty solution but my view of the problem is much simpler than yours so my
>>> idea of a solution would look quick and dirty. I have a better appreciation of
>>> the problem now and a way to approach it :-)
>>>
>>>  From DT point of view are we OK with this form then
>>>
>>>      coprocessor {
>>>              interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>;
>>>              interrupt-sink = <&intc INT_SPEC CPU_HWAFFINITY>;
>>>      }
>>>
>>> and if the root controller sends normal IPI as it sends normal device
>>> interrupts then interrupt-sink can be a standard interrupts property (like in
>>> my case)
>>>
>>>      coprocessor {
>>>              interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>;
>>>              interrupts = <INT_SPEC>;
>>>      }
>>>
>>> Does this look right to you? Is there something else that needs to be covered
>>> still?
>> I'm not an DT wizard. I leave that to the DT experts.
>>   
> 
> Hi Marc Zyngier, Mark Rutland,
> 
> Any comments about the DT binding for the IPIs?
> 
> To recap, the proposal which is based on Marc Zyngier's is to use 
> interrupt-source to represent an IPI from Linux CPU to a coprocessor and 
> interrupt-sink to receive an IPI from coprocessor to Linux CPU. 
> Hopefully the description above is self explanatory. Please let me know 
> if you need more info. Thomas covered the routing, synthesising, and 
> requesting parts in the core code. The remaining (high level) issue is 
> how to describe the IPIs in DT.

I'm definitely *not* a DT expert! ;-) My initial binding proposal was
only for wired interrupts, not for IPIs. There is definitely some common
aspects, except for one part:

Who decides on the IPI number? So far, we've avoided encoding IPI
numbers in the DT just like we don't encode MSIs, because they are
programmable things. My feeling is that we shouldn't put the IPI number
in the DT because the rest of the kernel uses them as well and could
decide to use this particular IPI number for its own use: *clash*.

The way I see it would be to have a pool of IPI numbers that the kernel
requests for its own use first, leaving whatever remains to drivers.

Mark (as *you* are the expert ;-), what do you think?

	M.
-- 
Jazz is not dead. It just smells funny...
--
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/