[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200318174133.160206-2-swboyd@chromium.org>
Date: Wed, 18 Mar 2020 10:41:32 -0700
From: Stephen Boyd <swboyd@...omium.org>
To: Jonathan Corbet <corbet@....net>
Cc: linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: [PATCH v2 1/2] docs: locking: Add 'need' to hardirq section
Add the missing word to make this sentence read properly.
Signed-off-by: Stephen Boyd <swboyd@...omium.org>
---
Documentation/kernel-hacking/locking.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst
index a8518ac0d31d..9850c1e52607 100644
--- a/Documentation/kernel-hacking/locking.rst
+++ b/Documentation/kernel-hacking/locking.rst
@@ -263,7 +263,7 @@ by a hardware interrupt on another CPU. This is where
interrupts on that cpu, then grab the lock.
:c:func:`spin_unlock_irq()` does the reverse.
-The irq handler does not to use :c:func:`spin_lock_irq()`, because
+The irq handler does not need to use :c:func:`spin_lock_irq()`, because
the softirq cannot run while the irq handler is running: it can use
:c:func:`spin_lock()`, which is slightly faster. The only exception
would be if a different hardware irq handler uses the same lock:
--
Sent by a computer, using git, on the internet
Powered by blists - more mailing lists