linux-kernel - Re: Generic DT binding for IPIs

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:	Fri, 23 Oct 2015 11:28:56 +0100
From:	Qais Yousef <qais.yousef@...tec.com>
To:	Rob Herring <robh+dt@...nel.org>
CC:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	"Marc Zyngier" <marc.zyngier@....com>,
	Jiang Liu <jiang.liu@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Generic DT binding for IPIs

On 10/22/2015 02:43 PM, Rob Herring wrote:
> On Wed, Oct 14, 2015 at 5:18 AM, Qais Yousef <qais.yousef@...tec.com> wrote:
>> Hi,
>>
>> This is an attempt to revive a discussion on the right list this time with
>> all the correct people hopefully on CC.
> devicetree-spec would be more appropriate list for something like this.

Thanks I didn't know about it.

>
>> While trying to upstream a driver, Thomas and Marc Zyngier pointed out the
>> need for a generic IPI support in the kernel to allow driver to reserve and
>> send ones. Hopefully my latest RFC patch will help to clarify what's being
>> done.
>>
>>      https://lkml.org/lkml/2015/10/13/227
>>
>> We need a generic DT binding support to accompany that to allow a driver to
>> reserve an IPI using this new mechanism.
>>
>> MarcZ had the following suggestion:
>>
>>      https://lkml.org/lkml/2015/8/24/628
>>
>> Which in summary is
>>
>>          mydevice@...00000 {
>>                  interrupt-source = <&intc INT_SPEC 2 &inttarg1 &inttarg1>;
> What is INT_SPEC and "2"? A drawing of the h/w connections and then
> what the binding looks like would be helpful.

INT_SPEC are the interrupt controller specific parameters. I think 2 
refers to how many 'interrupt-sink' references it's being passed.

>
>>          };
>>
>>          inttarg1: mydevice@...00000 {
>>                  interrupt-sink = <&intc HWAFFINITY1>;
> What is HWAFFINITY1? I want to be able to see if say this value is 1,
> then the affinity is for cpu0.

HWAFFINITY is the CPU to map the IPI to. The actual value would be 
specific to the interrupt controller. The controller implementation can 
always provide a set of defines if the mapping is not straightforward.

>
>>          };
>>
>>          inttarg2: cpu@1 {
>>                  interrupt-sink = <&intc HWAFFINITY2>;
>>          };
>>
>>
>> interrupt-sink requests to reserve an IPI that it will receive at HWAFFINITY
>> cpumask. interrupt-source will not do any reservation. It will simply
>> connect an IPI reserved by interrupt-sink to the device that will be
>> responsible for generating that IPI. This description should allow
>> connecting any 2 devices.
>> Correct me Marc if I got it wrong please.
>>
>> I suggested a simplification by assuming that IPIs will only be between host
>> OS and a coprocessor which would gives us this form which I think is easier
>> to deal with
>>
>>          coprocessor {
>>               interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>;
>>               interrupt-sink = <&intc INT_SPEC CPU_HWAFFINITY>;
>>          }
>>
>>
>> interrupt-source here reserves an IPI to be sent from host OS to coprocessor
>> at COP_HWAFFINITY. interrupt-sink will reserve an IPI to be received by host
>> OS at CPU_HWAFFINITY. Less generic but I don't know how important it is for
>> host OS to setup IPIs between 2 external coprocessors and whether it should
>> really be doing that.
> Could we use the existing interrupts binding for interrupt-sink?

No. interrupt-sink will cause an IPI to be dynamically allocated and 
mapped to that processor. Of course, if the connection is hardwired then 
interrupts property is the right thing to use.

>
>> What do the DT experts think? Any preference or a better suggestion?
> Depends how you would assign coproc to coproc IPIs in a system. It may
> be fixed in firmware, or more complex coprocs may read the dtb.

OK. I'll try to cook some RFC patches that implement this which 
hopefully will make it easier to review and build on.

Thanks,
Qais
--
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/