On 10/22/21 7:43 PM, Marc Zyngier wrote:

On Fri, 22 Oct 2021 18:58:54 +0100,
Mark Rutland [off-list ref] wrote:

quoted

On Fri, Oct 22, 2021 at 05:34:20PM +0100, Vladimir Murzin wrote:

quoted

On 10/22/21 4:36 PM, Mark Rutland wrote:

quoted

On Fri, Oct 22, 2021 at 04:18:18PM +0100, Vladimir Murzin wrote:

quoted

Hi Mark,

On 10/21/21 7:02 PM, Mark Rutland wrote:

quoted

+/*
+ * TODO: restructure the ARMv7M entry logic so that this entry logic can live
+ * in arch code.
+ */
+asmlinkage void __exception_irq_entry
+static void nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)

I'm seeing build time failure...

drivers/irqchip/irq-nvic.c:50:8: error: two or more data types in declaration specifiers
 static void nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)
        ^~~~
drivers/irqchip/irq-nvic.c:50:13: warning: 'nvic_handle_irq' defined but not used [-Wunused-function]
 static void nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)

I've fixed that locally and planing to give it a go...

Ah, whoops. I've removed the extraneous `static void` from
nvic_handle_irq() and build tested that as part of stm32_defconfig.

The updated version is in my irq/handle-domain-irq branch at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git

$ cat /proc/interrupts
           CPU0       
 16:         24  nvic_irq   4 Edge      mps2-clkevt
 17:          0  nvic_irq  32 Edge      mps2-uart-rx
 18:          6  nvic_irq  33 Edge      mps2-uart-tx
 19:          0  nvic_irq  47 Edge      mps2-uart-overrun
Err:          0

So if it helps feel free to add my 

Tested-by: Vladimir Murzin <redacted> # ARMv7M

Thanks!

I've folded that in and uppdated the branch.

quoted

As for TODO, is [1] look something you have been thinking of? IIUC,
the show stopper is that hwirq is being passed from exception entry
which retrieved via xPSR (IPSR to be precise). OTOH hwirq also available
via Interrupt Controller Status Register (ICSR) thus can be used in
driver itself... I gave [1] a go and it runs fine, yet I admit I might
be missing something...

I hadn't thought about it in much detail, but that looks good!

I was wondering if we needed something like a
handle_arch_vectored_irq(), but if we can rely on the ICSR that seems
simpler overall. I'm not at all familiar with M-class, so I'm not sure
if there are pitfalls in this area.

Why can't we just use IPSR instead from the C code? It has the
potential of being of lower latency then a MMIO read (though I have no
idea whether it makes a material difference on M-class) and from what
I can see in the arch spec, they are strictly equivalent.

Hmmm, less arch specific asm(s) in driver code, no?

Cheers
Vladimir

Thanks,

	M.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel