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  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:   Wed, 20 Feb 2019 08:36:51 -0800
From:   Tony Lindgren <>
To:     Lokesh Vutla <>
Cc:     Nishanth Menon <>,
        Device Tree Mailing List <>,, Peter Ujfalusi <>,, Sekhar Nori <>,, Tero Kristo <>,
        Rob Herring <>,
        Santosh Shilimkar <>,,
        Linux ARM Mailing List <>,
        Linus Walleij <>
Subject: Re: [PATCH v5 05/10] dt-bindings: irqchip: Introduce TISCI Interrupt
 router bindings


Some more info on chained irq vs mux below that might

* Tony Lindgren <> [190219 15:36]:
> * Lokesh Vutla <> [190219 08:51]:
> > With this can you tell me how can we not have a device-tree and still support
> > irq allocation?
> Using standard dts reg property to differentiate the interrupt
> router instances. And if the interrupt router is a mux, you should
> treat it as a mux rather than a chained interrupt controller.
> We do have drivers/mux nowadays, not sure if it helps in this case
> as at least timer interrupts need to be configured very early.

Adding Linus Walleij to Cc since he posted a good test to
consider if something should use chained (or nested) irq:

"individual masking and ACKing bits and can all be used at the
 same time" [0]

Not sure if we have that documented somewhere?

But seems like the interrupt router should be set up as
a separate mux driver talking with firmware that the
interrupt controller driver calls on request_irq()?




Powered by blists - more mailing lists