linux-kernel - RE: [PATCH V3 2/2] drivers/irqchip: add NXP INTMUX interrupt multiplexer support

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, 20 Dec 2019 15:35:13 +0000
From:   Joakim Zhang <qiangqing.zhang@....com>
To:     Marc Zyngier <maz@...nel.org>
CC:     Lokesh Vutla <lokeshvutla@...com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "jason@...edaemon.net" <jason@...edaemon.net>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        Andy Duan <fugang.duan@....com>,
        "S.j. Wang" <shengjiu.wang@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH V3 2/2] drivers/irqchip: add NXP INTMUX interrupt
  multiplexer support


> -----Original Message-----
> From: Joakim Zhang
> Sent: 2019年12月20日 23:26
> To: 'Marc Zyngier' <maz@...nel.org>
> Cc: Lokesh Vutla <lokeshvutla@...com>; tglx@...utronix.de;
> jason@...edaemon.net; robh+dt@...nel.org; mark.rutland@....com;
> shawnguo@...nel.org; s.hauer@...gutronix.de; Andy Duan
> <fugang.duan@....com>; S.j. Wang <shengjiu.wang@....com>;
> linux-kernel@...r.kernel.org; dl-linux-imx <linux-imx@....com>;
> kernel@...gutronix.de; linux-arm-kernel@...ts.infradead.org
> Subject: RE: [PATCH V3 2/2] drivers/irqchip: add NXP INTMUX interrupt
> multiplexer support
> 
> 
> > -----Original Message-----
> > From: Marc Zyngier <maz@...nel.org>
> > Sent: 2019年12月20日 22:20
> > To: Joakim Zhang <qiangqing.zhang@....com>
> > Cc: Lokesh Vutla <lokeshvutla@...com>; tglx@...utronix.de;
> > jason@...edaemon.net; robh+dt@...nel.org; mark.rutland@....com;
> > shawnguo@...nel.org; s.hauer@...gutronix.de; Andy Duan
> > <fugang.duan@....com>; S.j. Wang <shengjiu.wang@....com>;
> > linux-kernel@...r.kernel.org; dl-linux-imx <linux-imx@....com>;
> > kernel@...gutronix.de; linux-arm-kernel@...ts.infradead.org
> > Subject: RE: [PATCH V3 2/2] drivers/irqchip: add NXP INTMUX interrupt
> > multiplexer support
> >
> > On 2019-12-20 14:10, Joakim Zhang wrote:
> > >> -----Original Message-----
> > >> From: Lokesh Vutla <lokeshvutla@...com>
> >
> > [...]
> >
> > >> Does the user care to which channel does the interrupt source goes
> > >> to? If not, interrupt-cells in DT can just be a single entry and
> > >> the channel selection can be controlled by the driver no? I am
> > >> trying to understand why user should specify the channel no.
> > > Hi Lokesh,
> > >
> > > If a fixed channel is specified in the driver, all interrupt sources
> > > will be connected to this channel, affecting the interrupt priority
> > > to some extent.
> > >
> > > From my point of view, a fixed channel could be enough if don't care
> > > interrupt priority.
> >
> > Hold on a sec:
> >
> > Is the channel to which an interrupt is routed to programmable? What
> > has the priority of the interrupt to do with this? How does this
> > affect interrupt delivery?
> >
> > It looks like this HW does more that you initially explained...
> Hi Marc,
> 
> The channel to which an interrupt is routed to is not programmable. Each
> channel has the same 32 interrupt sources.
> Each channel has mask, unmask and status register.
> If use 1 channel, 32 interrupt sources input and 1 interrupt output.
> If use 2 channels, 32 interrupt sources input and 2 interrupts output.
> And so on. You can see above INTMUX block diagram. This is how HW works.
> 
> For example:
> 1) use 1 channel:
> We can enable 0~31 interrupt in channel 0. And 1 interrupt output. If generate
> interrupt, we cannot figure out which half happened first.
> 2)use 2 channels:
> We can enable 0~15 interrupt in channel 0, and enable 16~31 in channel 1.
> And 2 interrupts output. If generate interrupt, at least we can find channel 0 or
> channel 1 first. Then find 0~15 or 16~31 first.
> 
> This is my understanding of the interrupt priority from this intmux, I don't
> know if it is my misunderstanding.

So assign interrupt sources to multi-channels will generate multi-interrupt output. And these output interrupts are sequential. Could this be interpreted as interrupt priority?

Best Regards,
Joakim Zhang
> Best Regards,
> Joakim Zhang
> >          M.
> > --
> > Jazz is not dead. It just smells funny...