linux-kernel - Re: [PATCH v6 1/6] irqchip/mtk-sysirq: support 4 interrupt parameters for sysirq

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:   Mon, 11 Feb 2019 21:01:20 +0800
From:   Seiya Wang <seiya.wang@...iatek.com>
To:     Marc Zyngier <marc.zyngier@....com>
CC:     Matthias Brugger <matthias.bgg@...il.com>,
        Erin Lo <erin.lo@...iatek.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        <devicetree@...r.kernel.org>,
        srv_heupstream <srv_heupstream@...iatek.com>,
        <linux-kernel@...r.kernel.org>, <linux-serial@...r.kernel.org>,
        <linux-mediatek@...ts.infradead.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <yingjoe.chen@...iatek.com>, <mars.cheng@...iatek.com>,
        <eddie.huang@...iatek.com>, <linux-clk@...r.kernel.org>
Subject: Re: [PATCH v6 1/6] irqchip/mtk-sysirq: support 4 interrupt
 parameters for sysirq

On Mon, 2019-02-11 at 08:50 +0000, Marc Zyngier wrote:
> On Mon, 11 Feb 2019 06:35:29 +0000,
> Seiya Wang <seiya.wang@...iatek.com> wrote:
> > 
> > On Thu, 2019-02-07 at 15:52 +0000, Marc Zyngier wrote:
> > > On 07/02/2019 15:47, Marc Zyngier wrote:
> > > > On 07/02/2019 15:20, Matthias Brugger wrote:
> > > >>
> > > >>
> > > >> On 24/01/2019 09:07, Erin Lo wrote:
> > > >>> From: Seiya Wang <seiya.wang@...iatek.com>
> > > >>>
> > > >>> To support partitioned PPIs, 4 interrupt parameters should be valid
> > > >>> for sysirq.
> > > >>>
> > > >>> Signed-off-by: Seiya Wang <seiya.wang@...iatek.com>
> > > >>> Signed-off-by: Erin Lo <erin.lo@...iatek.com>
> > > >>> ---
> > > >>>  drivers/irqchip/irq-mtk-sysirq.c | 4 ++--
> > > >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >>>
> > > >>> diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c
> > > >>> index 90aaf19..282736a 100644
> > > >>> --- a/drivers/irqchip/irq-mtk-sysirq.c
> > > >>> +++ b/drivers/irqchip/irq-mtk-sysirq.c
> > > >>> @@ -81,7 +81,7 @@ static int mtk_sysirq_domain_translate(struct irq_domain *d,
> > > >>>  				       unsigned int *type)
> > > >>>  {
> > > >>>  	if (is_of_node(fwspec->fwnode)) {
> > > >>> -		if (fwspec->param_count != 3)
> > > >>> +		if (fwspec->param_count != 3 && fwspec->param_count != 4)
> > > >>
> > > >> Where is this 4th parameter used?
> > > > 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt#n14
> > > Sorry, I fired Send way too early.
> > > 
> > > What I wanted to add is that it is not clear to me why this change would
> > > be required here, as this driver only supports SPIs. It could be fixed
> > > by just relaxing the binding itself.
> > > 
> > > Thanks,
> > > 
> > > 	M.
> > 
> > Do you mean that we should change #interrupt-cells back to 3 for sysirq
> > and remove the 4th parameters of every spi interrupts in mt8183.dtsi
> > (i.e. 3 parameters for spi, 4 for ppi) such that we can discard this
> > patch?
> 
> It is more subtle than that:
> 
> - PPIs must have the affinity parameter in their int-spec (since you
>   need that for the PMU)
> 
> - SPIs that are directly routed to the GIC must also have the affinity
>   parameter (although set to zero).
> 
> - SPIs that are routed via the sysirq block (or any other) can use the
>   3 parameter variant, as they are not resolved in the context of the
>   GIC, but in that of the sysirq.
> 
> But in short, yes. You should be able to drop this patch altogether.
> 
> > If yes, we may need some time to verify the change before resending the
> > patch.
> 
> That's absolutely fine.
> 
> Thanks,
> 
> 	M.
> 
Thanks for the detailed descriptions.
We will remove this patch and resend again.