generic_handle_irq() must be called from a no-IRQ context. Documentation
advices on using a fake raw lock to call generic_handle_irq() from any
context.
Since 509853f9e1e7 ("genirq: Provide generic_handle_irq_safe()"), a
better alternative is available.
To: Stephen Warren <swarren@xxxxxxxxxxxxx>
To: Jonathan Corbet <corbet@xxxxxxx>
Cc: linux-doc@xxxxxxxxxxxxxxx
Signed-off-by: Théo Lebrun <theo.lebrun@xxxxxxxxxxx>
---
Documentation/driver-api/gpio/driver.rst | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst
index bf6319cc531b..550d167a82ed 100644
--- a/Documentation/driver-api/gpio/driver.rst
+++ b/Documentation/driver-api/gpio/driver.rst
@@ -339,15 +339,8 @@ Cascaded GPIO irqchips usually fall in one of three categories:
The generic_handle_irq() is expected to be called with IRQ disabled,
so the IRQ core will complain if it is called from an IRQ handler which is
- forced to a thread. The "fake?" raw lock can be used to work around this
- problem::
-
- raw_spinlock_t wa_lock;
- static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank)
- unsigned long wa_lock_flags;
- raw_spin_lock_irqsave(&bank->wa_lock, wa_lock_flags);
- generic_handle_irq(irq_find_mapping(bank->chip.irq.domain, bit));
- raw_spin_unlock_irqrestore(&bank->wa_lock, wa_lock_flags);
+ forced to a thread. generic_handle_irq_safe() can be used to work around
+ this problem; it can safely be called from any context.
- GENERIC CHAINED GPIO IRQCHIPS: these are the same as "CHAINED GPIO irqchips",
but chained IRQ handlers are not used. Instead GPIO IRQs dispatching is
--
2.44.0
