kernel/linux.git/Documentation/kernel-hacking, branch v6.1.168

timers: Update the documentation to reflect on the new timer_shutdown() API

2025-10-29T13:04:32+00:00

[ Upstream commit a31323bef2b66455920d054b160c17d4240f8fd4 ] In order to make sure that a timer is not re-armed after it is stopped before freeing, a new shutdown state is added to the timer code. The API timer_shutdown_sync() and timer_shutdown() must be called before the object that holds the timer can be freed. Update the documentation to reflect this new workflow. [ tglx: Updated to the new semantics and updated the zh_CN version ] Signed-off-by: Steven Rostedt (Google) Signed-off-by: Thomas Gleixner Tested-by: Guenter Roeck Reviewed-by: Jacob Keller Reviewed-by: Anna-Maria Behnsen Link: https://lore.kernel.org/r/20221110064147.712934793@goodmis.org Link: https://lore.kernel.org/r/20221123201625.375284489@linutronix.de Signed-off-by: Jeongjun Park Signed-off-by: Greg Kroah-Hartman

Documentation: Replace del_timer/del_timer_sync()

2025-10-29T13:04:32+00:00

[ Upstream commit 87bdd932e85881895d4720255b40ac28749c4e32 ] Adjust to the new preferred function names. Suggested-by: Steven Rostedt Signed-off-by: Thomas Gleixner Reviewed-by: Jacob Keller Reviewed-by: Anna-Maria Behnsen Link: https://lore.kernel.org/r/20221123201625.075320635@linutronix.de Signed-off-by: Jeongjun Park Signed-off-by: Greg Kroah-Hartman

Documentation: Remove bogus claim about del_timer_sync()

2025-10-29T13:04:31+00:00

[ Upstream commit b0b0aa5d858d4d2fe39a5e4486e0550e858108f6 ] del_timer_sync() does not return the number of times it tried to delete the timer which rearms itself. It's clearly documented: The function returns whether it has deactivated a pending timer or not. This part of the documentation is from 2003 where del_timer_sync() really returned the number of deletion attempts for unknown reasons. The code was rewritten in 2005, but the documentation was not updated. Signed-off-by: Thomas Gleixner Reviewed-by: Jacob Keller Reviewed-by: Anna-Maria Behnsen Link: https://lore.kernel.org/r/20221123201624.452282769@linutronix.de Signed-off-by: Jeongjun Park Signed-off-by: Greg Kroah-Hartman

Documentation: Fix spelling mistake in hacking.rst

2022-10-24T17:27:51+00:00

Fix `botton half locks` to `bottom half locks`. Signed-off-by: Mushahid Hussain Link: https://lore.kernel.org/r/20221017112026.88324-1-mushi.shar@gmail.com Signed-off-by: Jonathan Corbet

docs: process: remove outdated submitting-drivers.rst

2022-07-14T21:03:57+00:00

Commit 31b24bee3357 ("docs: add a warning to submitting-drivers.rst") in October 2016 already warns "This (...) should maybe just be deleted, but I'm not quite ready to do that yet". Maybe, six years ago, we were not ready but let us remove old content for the better now and structure and maintain less content in the kernel documentation with a better result. Drop this already outdated document and adjust all textual references. Here is an argument why deleting the content will not remove any useful information to the existing kernel documentation, individually broken down for each section. Section "Allocating Device Numbers" refers to https://www.lanana.org/, and then refers to Documentation/admin-guide/devices.rst. However, the devices.rst clearly states: "The version of this document at lanana.org is no longer maintained." Everything needed for submitting drivers is already stated in devices.rst and the reference to https://www.lanana.org/ is outdated, and should be just deleted. Section "Who To Submit Drivers To" is all about Linux 2.0 - 2.6, before the new release version scheme; the mentioned developers are still around, but actually not the first developers to contact anymore. Section "What Criteria Determine Acceptance" has a few bullet points: Licensing and Copyright is well-covered in process/kernel-license.rst. Interfaces, Code, Portability, Clarity state some obvious things about ensuring kernel code quality. Control suggests to add a MAINTAINERS entry, which is already mentioned in 6.Followthrough.rst: "... added yourself to the MAINTAINERS file..." PM support states a bit about implementing and testing power management of a driver, it remains an open question where to place that in the process documents. Driver developers interested in power management will find the corresponding part on power management in the kernel documentation anyway. In section "What Criteria Do Not Determine Acceptance", the points Vendor and Author states something basic consequence of the kernel being an open-source community software development. Probably no need to mention it nowadays. Section "Resources" lists resources that are also mentioned elsewhere more central. - Linux kernel tree and mailing list is mentioned in many places. - https://lwn.net/Kernel/LDD3/ is mentioned in Documentation/process/kernel-docs.rst. - https://lwn.net/ is mentioned in: - Documentation/process/8.Conclusion.rst - Documentation/process/kernel-docs.rst - https://kernelnewbies.org/ is mentioned in: - Documentation/process/8.Conclusion.rst - Documentation/process/kernel-docs.rst - http://www.linux-usb.org/ is mentioned in Documentation/driver-api/usb/usb.rst - https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf is mentioned in Documentation/process/kernel-docs.rst - https://kernelnewbies.org/KernelJanitors is mentioned in Documentation/process/howto.rst - https://git-scm.com/ is mentioned in - Documentation/process/2.Process.rst - Documentation/process/7.AdvancedTopics.rst - Documentation/process/howto.rst Signed-off-by: Lukas Bulwahn Link: https://lore.kernel.org/r/20220704122537.3407-7-lukas.bulwahn@gmail.com Signed-off-by: Jonathan Corbet

Documentation: kernel-hacking: minor edits for style

2022-04-05T15:53:24+00:00

Rusty's kernel-hacking guides provide important information, however they are written in a narrative style that some readers may interpret as off-putting. Since the goal is to make kernel documentation accessible to as many new developers as possible, it's best to avoid the turns of phrase that require a specific cultural context to properly understand. Signed-off-by: Konstantin Ryabitsev Signed-off-by: Jonathan Corbet

docs: fix typo in Documentation/kernel-hacking/locking.rst

2022-01-27T18:22:33+00:00

Change copy_from_user*( to copy_from_user() . Signed-off-by: Takahiro Itazuri Link: https://lore.kernel.org/r/20220124081447.34066-1-itazur@amazon.com Signed-off-by: Jonathan Corbet

docs: futex: Fix kernel-doc references

2021-10-19T15:27:05+00:00

Since the futex code was restructured, there's no futex.c file anymore and the implementation is split in various files. Point kernel-doc references to the new files. Signed-off-by: André Almeida Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20211012135549.14451-1-andrealmeid@collabora.com

docs: kernel-hacking: Remove inappropriate text

2021-09-03T21:56:45+00:00

Remove inappropriate sexual (and ableist) text from the locking documentation, aligning it with the kernel code-of-conduct. As the text was unrelated to locking, this change streamlines the document and improves readability. Signed-off-by: Alyssa Rosenzweig Link: https://lore.kernel.org/r/20210903151826.6300-1-alyssa@rosenzweig.io Signed-off-by: Jonathan Corbet

Documentation: in_irq() cleanup

2021-08-24T19:28:23+00:00

Replace the obsolete and ambiguos macro in_irq() with new macro in_hardirq(). Signed-off-by: Changbin Du Link: https://lore.kernel.org/r/20210814014831.53083-1-changbin.du@gmail.com Signed-off-by: Jonathan Corbet