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, 8 Mar 2021 02:42:51 +0000
From:   Mark-PK Tsai (蔡沛剛) <Mark-PK.Tsai@...iatek.com>
To:     Marc Zyngier <maz@...nel.org>, Daniel Palmer <daniel@...f.com>
CC:     Daniel Palmer <daniel@...ngy.jp>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        YJ Chiang (江英杰) <yj.chiang@...iatek.com>
Subject: RE: [PATCH] irqchip/irq-mst: Support polarity configuration



> Hi Mark-PK,
>
> I'm trying to understand the logic behind the changes.
> It seems like the polarity of interrupts is always the same between the MStar intc and the GIC? Low level interrupts are handled in the mstar intc and become high level interrupts to the GIC?
> I think for the Mstar MSC313(e) and SigmaStar chips all of the internal interrupts are high level so I never noticed this behaviour.
> I can't remember seeing anything that handled this in the MStar kernel code I looked at.
> Is this specific to a certain chip or does it apply for everything with this intc?

I suppose Mstar SoCs also need this patch which depends on what kind of interrupt source the HW designer wire to this intc.
If an interrupt source is active low, we need to set the corresponding bit to reverse the polarity to meet GIC SPI requirement as Marc mentioned.

> The register values being lost if the chip goes into suspend to memory makes sense for the MStar chips too I think as everything that is not in the "pmsleep" register group seems to be lost.

There are mask and eoi bits I did not handle here.
That's because kernel will handle the mask and eoi status when system going to suspend/resume in suspend_device_irqs/ resume_device_irqs.
And all the irqs of Mstar intc are masked by default when the IP powered on.


Best regards,
Mark-PK Tsai


-----Original Message-----
From: Marc Zyngier [mailto:maz@...nel.org] 
Sent: Sunday, March 7, 2021 2:28 AM
To: Daniel Palmer <daniel@...f.com>
Cc: Mark-PK Tsai (蔡沛剛) <Mark-PK.Tsai@...iatek.com>; Daniel Palmer <daniel@...ngy.jp>; Thomas Gleixner <tglx@...utronix.de>; Jason Cooper <jason@...edaemon.net>; Matthias Brugger <matthias.bgg@...il.com>; Linux Kernel Mailing List <linux-kernel@...r.kernel.org>; linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>; linux-mediatek@...ts.infradead.org; YJ Chiang (江英杰) <yj.chiang@...iatek.com>
Subject: Re: [PATCH] irqchip/irq-mst: Support polarity configuration

On Sat, 06 Mar 2021 17:06:51 +0000,
Daniel Palmer <daniel@...f.com> wrote:
> 
> Hi Mark-PK,
> 
> I'm trying to understand the logic behind the changes.
> It seems like the polarity of interrupts is always the same between 
> the MStar intc and the GIC? Low level interrupts are handled in the 
> mstar intc and become high level interrupts to the GIC?

That's because the GIC only supports level-high input interrupts when they are level triggered (and rising edge when edge triggered).

Thanks,

	M.

--
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ