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  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:   Sun, 3 Jan 2021 06:43:30 -0600
From:   Samuel Holland <>
To:     Marc Zyngier <>
Cc:     Thomas Gleixner <>,
        Rob Herring <>,
        Maxime Ripard <>,
        Chen-Yu Tsai <>,
        Jernej Skrabec <>,
        Russell King <>,
        Catalin Marinas <>,
        Will Deacon <>,
        Ondrej Jirman <>,,,
Subject: Re: [PATCH v3 00/10] sunxi: Support IRQ wakeup from deep sleep

On 1/3/21 6:16 AM, Marc Zyngier wrote:
> [dropped, which seems to be a closed ML]
> On Sun, 03 Jan 2021 10:30:51 +0000,
> Samuel Holland <> wrote:
>> Allwinner sun6i/sun8i/sun50i SoCs (A31 and newer) have two interrupt
>> controllers: GIC and R_INTC. GIC does not support wakeup. R_INTC handles
>> the external NMI pin, and provides 32+ IRQs to the ARISC. The first 16
>> of these correspond 1:1 to a block of GIC IRQs starting with the NMI.
>> The last 13-16 multiplex the first (up to) 128 GIC SPIs.
>> This series replaces the existing chained irqchip driver that could only
>> control the NMI, with a stacked irqchip driver that also provides wakeup
>> capability for those multiplexed SPI IRQs. The idea is to preconfigure
>> the ARISC's IRQ controller, and then the ARISC firmware knows to wake up
>> as soon as it receives an IRQ. It can also decide how deep it can
>> suspend based on the selected wakeup IRQs.
> Out of curiosity, how do you plan to communicate dynamic configuration
> of IRQs to the ARISC? We recently went through this with some TI
> stuff, and the result a bit awkward (the arm64 side configures
> interrupts that are not visible to the kernel, but only to the
> co-processors).

Assuming by "dynamic" you mean while Linux is running, I don't plan to
communicate anything. As far as I'm concerned, the driver is feature-complete
after this patch series. The ARISC firmware does not use the interrupt
controller (or any other shared peripherals) while Linux is running. It sits in
a tight loop polling its side of the mailbox, waiting for a
hotplug/suspend/poweroff/reboot command.

> I wondered whether you had other ideas...

Sorry, I guess not. We tried to avoid using the ARISC for long enough that
anything that can have a native Linux driver has one. So the ARISC firmware has
nothing to do while Linux is running. (This is in comparison to the vendor BSP,
where some peripherals are only accessed through their firmware.)


> Thanks,
> 	M.

Powered by blists - more mailing lists