[PATCH v2 26/30] Documentation: gpio: mention generic_handle_irq_safe()

[Théo Lebrun <theo.lebrun@xxxxxxxxxxx>]

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