linux-kernel - Re: [PATCH 07/27] irqchip: Declare cortex-a7's irqchip to initialize gic from dt

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]

Message-Id: <907CEE7C-19F2-495C-BE8F-712AE4B0A0E1@gmail.com>
Date:	Thu, 10 Apr 2014 16:12:56 +0530
From:	armdev <armdev.ftm@...il.com>
To:	Marc Zyngier <marc.zyngier@....com>
Cc:	Chanwoo Choi <cw00.choi@...sung.com>,
	"kgene.kim@...sung.com" <kgene.kim@...sung.com>,
	"t.figa@...sung.com" <t.figa@...sung.com>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	"hyunhee.kim@...sung.com" <hyunhee.kim@...sung.com>,
	"sw0312.kim@...sung.com" <sw0312.kim@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"yj44.cho@...sung.com" <yj44.cho@...sung.com>,
	"inki.dae@...sung.com" <inki.dae@...sung.com>,
	"kyungmin.park@...sung.com" <kyungmin.park@...sung.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Mark Rutland <Mark.Rutland@....com>
Subject: Re: [PATCH 07/27] irqchip: Declare cortex-a7's irqchip to initialize gic from dt


On 10-Apr-2014, at 4:11 pm, Marc Zyngier <marc.zyngier@....com> wrote:

> On Thu, Apr 10 2014 at 11:30:41 am BST, armdev <armdev.ftm@...il.com> wrote:
>> On 10-Apr-2014, at 3:51 pm, Marc Zyngier <marc.zyngier@....com> wrote:
>> 
>>> On Thu, Apr 10 2014 at 11:09:02 am BST, armdev <armdev.ftm@...il.com> wrote:
>>>> On 10-Apr-2014, at 3:34 pm, Marc Zyngier <marc.zyngier@....com> wrote:
>>>> 
>>>>> On Thu, Apr 10 2014 at 10:28:24 am BST, Chanwoo Choi <cw00.choi@...sung.com> wrote:
>>>>>> This patch declare coretex-a7's irqchip to initialze gic from dt
>>>>>> with "arm,cortex-a7-gic" data.
>>>>>> 
>>>>>> Cc: Thomas Gleixner <tglx@...utronix.de>
>>>>>> Signed-off-by: Chanwoo Choi <cw00.choi@...sung.com>
>>>>>> Signed-off-by: Kyungmin Park <kyungmin.park@...sung.com>
>>>>>> ---
>>>>>> drivers/irqchip/irq-gic.c | 1 +
>>>>>> 1 file changed, 1 insertion(+)
>>>>>> 
>>>>>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>>>>>> index 4300b66..8e906e4 100644
>>>>>> --- a/drivers/irqchip/irq-gic.c
>>>>>> +++ b/drivers/irqchip/irq-gic.c
>>>>>> @@ -1069,6 +1069,7 @@ gic_of_init(struct device_node *node, struct device_node *parent)
>>>>>> }
>>>>>> IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
>>>>>> IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
>>>>>> +IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init);
>>>>>> IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
>>>>>> IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
>>>>> 
>>>>> Frankly, this patch adds no value. Are we going to add
>>>>> "arm,cortex-a12-gic", "arm,cortex-a17-gic", "arm,cortex-a53-gic",
>>>>> "arm,cortex-a57-gic"? And that's just to mention the ARM Ltd cores...
>>>>> 
>>>>> Instead, how about defining a generic "arm,gic" property, and mandate
>>>>> that new DT files are using that? We can always use a more precise
>>>>> compatible for quirks.
>>>>> 
>>>> 
>>>> How about keeping it simple and tied to arm gic versions
>>>> arm,gicv1, arm,gicv2, arm,gicv2ve
>>> 
>>> That's a variation on the same theme. As for GICv2, we don't need to
>>> distinguish between having the Virtualization Extentions, the binding
>>> already allows you to tell one from the other.
>>> 
>> So if there be just 2 types of gic, it would be simple.
> 
> Not exactly. We just happen to support two revisions of the GIC
> architecture with the same binding. GICv3 has an entierely separate
> binding.
> 
>> gicv1 - 2 address sets (gicc and gicd)
> 
> Yes.
> 
>> gicv2 - 4 sets (gicc gicd gicv gich) and 1 maintenance interrupt. Right?
> 
> No.
> 
> The presence of the GICV, GICH and maintenance interrupt are indicative
> of the support for the Virtualization Extentions. GICv2 itself can
> perfectly be built without it.

then does gicv2-ve makes sense ?
> 
> 	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/