linux-kernel - RE: [EXT] Re: [v2 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A external interrupt

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, 2 Nov 2020 06:14:58 +0000
From:   "Biwen Li (OSS)" <biwen.li@....nxp.com>
To:     Leo Li <leoyang.li@....com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        "Biwen Li (OSS)" <biwen.li@....nxp.com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "Z.q. Hou" <zhiqiang.hou@....com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "jason@...edaemon.net" <jason@...edaemon.net>,
        "maz@...nel.org" <maz@...nel.org>
CC:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jiafei Pan <jiafei.pan@....com>,
        Xiaobo Xie <xiaobo.xie@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [EXT] Re: [v2 01/11] irqchip: ls-extirq: Add LS1043A, LS1088A
 external interrupt

> > >
> > > Caution: EXT Email
> > >
> > > On 27/10/2020 05.46, Biwen Li wrote:
> > > > From: Hou Zhiqiang <Zhiqiang.Hou@....com>
> > > >
> > > > Add an new IRQ chip declaration for LS1043A and LS1088A
> > > > - compatible "fsl,ls1043a-extirq" for LS1043A, LS1046A.
> SCFG_INTPCR[31:0]
> > > >   of these SoCs is stored/read as SCFG_INTPCR[0:31] defaultly(bit
> > > >   reverse)
> > >
> > > s/defaultly/by default/ I suppose. But what does that mean? Is it
> > > still configurable, just now through some undocumented register? If
> > > that register still exists, does it now have a reset value of
> > > all-ones as opposed to the ls1021 case? If it's not configurable,
> > > then describing the situation as "by default" is confusing and
> > > wrong, it should just say "On LS1043A, LS1046A, SCFG_INTPCR is
> > > stored/read bit-
> > reversed."
> > Okay, got it. Will update it in v3. Thanks.
> 
> Hi Biwen,
> 
> Where did you get this information that the register on LS1043 and LS1046 is bit
> reversed?  I cannot find such information in the RM.  And does this mean all
> other SCFG registers are also bit reversed?  If this is some information that is
> not covered by the RM, we probably should clarify it in the code and the commit
> message.
Hi Leo,

I directly use the same logic to write the bit(field IRQ0~11INTP) of the register SCFG_INTPCR
in LS1043A and LS1046A.
Such as,
if I want to control the polarity of IRQ0(field IRQ0INTP, IRQ0 is active low) of LS1043A/LS1046A,
then I just need write a value 1 << (31 - 0) to it.
The logic depends on register's definition in LS1043A/LS1046A's RM.

Regards,
Biwen

> 
> Regards,
> Leo
> 
> > >
> > >
> > > > - compatible "fsl,ls1088a-extirq" for LS1088A, LS208xA, LX216xA
> > > >
> > > > Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@....com>
> > > > Signed-off-by: Biwen Li <biwen.li@....com>
> > > > ---
> > > > Change in v2:
> > > >       - add despcription of bit reverse
> > > >       - update copyright
> > > >
> > > >  drivers/irqchip/irq-ls-extirq.c | 10 +++++++++-
> > > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/irqchip/irq-ls-extirq.c
> > > > b/drivers/irqchip/irq-ls-extirq.c index 4d1179fed77c..9587bc2607fc
> > > > 100644
> > > > --- a/drivers/irqchip/irq-ls-extirq.c
> > > > +++ b/drivers/irqchip/irq-ls-extirq.c
> > > > @@ -1,5 +1,8 @@
> > > >  // SPDX-License-Identifier: GPL-2.0
> > > > -
> > > > +/*
> > > > + * Author: Rasmus Villemoes <linux@...musvillemoes.dk>
> > >
> > > If I wanted my name splattered all over the files I touch or add,
> > > I'd add it myself, TYVM. The git history is plenty fine for
> > > recording authorship as far as I'm concerned, and I absolutely abhor
> > > having to skip over any kind of legalese boilerplate when opening a file.
> > Okay, got it. Will drop it in v3. Thanks.
> > >
> > > Rasmus