Merge tag 'docs-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/docs/linux

Pull documentation updates from Jonathan Corbet:
 "Things have calmed down a bit on the docs front, with no earthshaking
  changes this time around:

   - Ongoing work on the Japanese and Portuguese translations

   - Better integration of the MAINTAINERS file into the rendered
     documents, including a search interface

   - A seemingly infinite supply of fixes for typos, minor grammatical
     issues, and related problems that LLMs find with abandon"

* tag 'docs-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/docs/linux: (93 commits)
  docs: pt_BR: Translate 3.Early-stage.rst into Portuguese
  docs: pt_BR: update "Purpose of Defconfigs" section in maintainer-soc.rst
  Documentation: bug-hunting.rst: fix grammar
  docs/ja_JP: translate submitting-patches.rst (interleaved-replies)
  docs: Fix minor grammatical error
  docs/{it_it,sp_SP,zh_CN,zh_TW}: update references to removed CONFIG_DEBUG_SLAB
  Documentation: process: fix brackets
  Documentation: arch: fix brackets
  docs/dyndbg: explain flags parse 1st
  docs/dyndbg: update examples \012 to \n
  docs: kernel-parameters: Fix stale sticore file paths
  docs: real-time: Fix duplicated sched(7) text
  docs: kgdb: Fix stale source file paths
  docs: sonypi: Fix stale header file path
  docs: kernel-parameters: Remove sa1100ir IrDA parameter
  iommu: Documentation: rearrange, update kernel-parameters
  docs: md: fix grammar in speed_limit description
  docs: changes.rst: restore pahole 1.26 minimum (regressed by sort)
  Documentation: Fix syntax of kmalloc_objs example in coding style doc
  docs: pt_BR: update maintainer-handbooks
  ...

5 files changed, 58 insertions, 34 deletions

diff --git a/Documentation/watchdog/mlx-wdt.rst b/Documentation/watchdog/mlx-wdt.rst
index 35e690dea9db..2da36c762890 100644
--- a/Documentation/watchdog/mlx-wdt.rst
+++ b/Documentation/watchdog/mlx-wdt.rst
@@ -28,7 +28,7 @@ Type 3:
   Same as Type 2 with extended maximum timeout period.
   Maximum timeout is 65535 sec.
 
-Type 1 HW watchdog implementation exist in old systems and
+Type 1 HW watchdog implementation exists in old systems and
 all new systems have type 2 HW watchdog.
 Two types of HW implementation have also different register map.
 
@@ -48,7 +48,7 @@ which is optional.
 Watchdog can be started during a probe, in this case it will be
 pinged by watchdog core before watchdog device will be opened by
 user space application.
-Watchdog can be initialised in nowayout way, i.e. oncse started
+Watchdog can be initialised in nowayout mode, i.e. once started
 it can't be stopped.
 
 This mlx-wdt driver supports both HW watchdog implementations.
diff --git a/Documentation/watchdog/pcwd-watchdog.rst b/Documentation/watchdog/pcwd-watchdog.rst
index 151505c856f6..5cd45abe246a 100644
--- a/Documentation/watchdog/pcwd-watchdog.rst
+++ b/Documentation/watchdog/pcwd-watchdog.rst
@@ -29,7 +29,7 @@ Documentation and Driver by Ken Hollis <kenji@bitgate.com>
  to run the program with an "&" to run it in the background!)
 
  If you want to write a program to be compatible with the PC Watchdog
- driver, simply use of modify the watchdog test program:
+ driver, simply use or modify the watchdog test program:
  tools/testing/selftests/watchdog/watchdog-test.c
 
 
@@ -37,16 +37,23 @@ Documentation and Driver by Ken Hollis <kenji@bitgate.com>
 
 	WDIOC_GETSUPPORT
 		This returns the support of the card itself.  This
-		returns in structure "PCWDS" which returns:
+		returns in structure watchdog_info:
+
+                        identity = "PCWD"
+
+			options = list of supported options::
+                                  WDIOF_OVERHEAT
+                                  WDIOF_CARDRESET
+                                  WDIOF_KEEPALIVEPING
+                                  WDIOF_SETTIMEOUT
+                                  WDIOF_MAGICCLOSE
 
-			options = WDIOS_TEMPPANIC
-				  (This card supports temperature)
 			firmware_version = xxxx
 				  (Firmware version of the card)
 
 	WDIOC_GETSTATUS
 		This returns the status of the card, with the bits of
-		WDIOF_* bitwise-anded into the value.  (The comments
+		WDIOF_* bitwise-ored into the value.  (The comments
 		are in include/uapi/linux/watchdog.h)
 
 	WDIOC_GETBOOTSTATUS
@@ -55,7 +62,7 @@ Documentation and Driver by Ken Hollis <kenji@bitgate.com>
 
 	WDIOC_GETTEMP
 		This returns the temperature of the card.  (You can also
-		read /dev/watchdog, which gives a temperature update
+		read /dev/temperature, which gives a temperature update
 		every second.)
 
 	WDIOC_SETOPTIONS
diff --git a/Documentation/watchdog/watchdog-api.rst b/Documentation/watchdog/watchdog-api.rst
index 9acf7fe1fb58..0e6e526d7b95 100644
--- a/Documentation/watchdog/watchdog-api.rst
+++ b/Documentation/watchdog/watchdog-api.rst
@@ -39,12 +39,12 @@ The simplest API
 
 All drivers support the basic mode of operation, where the watchdog
 activates as soon as /dev/watchdog is opened and will reboot unless
-the watchdog is pinged within a certain time, this time is called the
+the watchdog is pinged within a certain time; this time is called the
 timeout or margin.  The simplest way to ping the watchdog is to write
 some data to the device.  So a very simple watchdog daemon would look
 like this source file:  see samples/watchdog/watchdog-simple.c
 
-A more advanced driver could for example check that a HTTP server is
+A more advanced driver could for example check that an HTTP server is
 still responding before doing the write call to ping the watchdog.
 
 When the device is closed, the watchdog is disabled, unless the "Magic
@@ -87,13 +87,13 @@ replaced with::
 		sleep(10);
 	}
 
-the argument to the ioctl is ignored.
+The argument to the ioctl is ignored.
 
 Setting and getting the timeout
 ===============================
 
 For some drivers it is possible to modify the watchdog timeout on the
-fly with the SETTIMEOUT ioctl, those drivers have the WDIOF_SETTIMEOUT
+fly with the SETTIMEOUT ioctl; those drivers have the WDIOF_SETTIMEOUT
 flag set in their option field.  The argument is an integer
 representing the timeout in seconds.  The driver returns the real
 timeout used in the same variable, and this timeout might differ from
@@ -110,7 +110,7 @@ Starting with the Linux 2.4.18 kernel, it is possible to query the
 current timeout using the GETTIMEOUT ioctl::
 
     ioctl(fd, WDIOC_GETTIMEOUT, &timeout);
-    printf("The timeout was is %d seconds\n", timeout);
+    printf("The timeout is %d seconds\n", timeout);
 
 Pretimeouts
 ===========
@@ -133,7 +133,7 @@ seconds.  Setting a pretimeout to zero disables it.
 There is also a get function for getting the pretimeout::
 
     ioctl(fd, WDIOC_GETPRETIMEOUT, &timeout);
-    printf("The pretimeout was is %d seconds\n", timeout);
+    printf("The pretimeout is %d seconds\n", timeout);
 
 Not all watchdog drivers will support a pretimeout.
 
@@ -145,13 +145,13 @@ before the system will reboot. The WDIOC_GETTIMELEFT is the ioctl
 that returns the number of seconds before reboot::
 
     ioctl(fd, WDIOC_GETTIMELEFT, &timeleft);
-    printf("The timeout was is %d seconds\n", timeleft);
+    printf("The timeout is %d seconds\n", timeleft);
 
 Environmental monitoring
 ========================
 
-All watchdog drivers are required return more information about the system,
-some do temperature, fan and power level monitoring, some can tell you
+All watchdog drivers are required to return more information about the system.
+Some do temperature, fan and power level monitoring; some can tell you
 the reason for the last reboot of the system.  The GETSUPPORT ioctl is
 available to ask what the device can do::
 
@@ -166,7 +166,7 @@ the fields returned in the struct watchdog_info are:
 	options			a flags describing what the device supports
 	================	=============================================
 
-the options field can have the following bits set, and describes what
+The options field can have the following bits set, and describes what
 kind of information that the GET_STATUS and GET_BOOT_STATUS ioctls can
 return.
 
@@ -175,13 +175,13 @@ return.
 	================	=========================
 
 The machine was last rebooted by the watchdog because the thermal limit was
-exceeded:
+exceeded.
 
 	==============		==========
 	WDIOF_FANFAULT		Fan failed
 	==============		==========
 
-A system fan monitored by the watchdog card has failed
+A system fan monitored by the watchdog card has failed.
 
 	=============		================
 	WDIOF_EXTERN1		External relay 1
@@ -195,26 +195,26 @@ a reset.
 	WDIOF_EXTERN2		External relay 2
 	=============		================
 
-External monitoring relay/source 2 was triggered
+External monitoring relay/source 2 was triggered.
 
 	================	=====================
 	WDIOF_POWERUNDER	Power bad/power fault
 	================	=====================
 
-The machine is showing an undervoltage status
+The machine is showing an undervoltage status.
 
 	===============		=============================
 	WDIOF_CARDRESET		Card previously reset the CPU
 	===============		=============================
 
-The last reboot was caused by the watchdog card
+The last reboot was caused by the watchdog card.
 
 	================	=====================
 	WDIOF_POWEROVER		Power over voltage
 	================	=====================
 
 The machine is showing an overvoltage status. Note that if one level is
-under and one over both bits will be set - this may seem odd but makes
+under and one over, both bits will be set - this may seem odd but makes
 sense.
 
 	===================	=====================
@@ -227,12 +227,14 @@ The watchdog saw a keepalive ping since it was last queried.
 	WDIOF_SETTIMEOUT	Can set/get the timeout
 	================	=======================
 
-The watchdog can do pretimeouts.
+The watchdog can get/set the timeout.
 
 	================	================================
 	WDIOF_PRETIMEOUT	Pretimeout (in seconds), get/set
 	================	================================
 
+The watchdog can do pretimeouts.
+
 
 For those drivers that return any bits set in the option field, the
 GETSTATUS and GETBOOTSTATUS ioctls can be used to ask for the current
@@ -255,7 +257,7 @@ returned value is the temperature in degrees Fahrenheit::
     ioctl(fd, WDIOC_GETTEMP, &temperature);
 
 Finally the SETOPTIONS ioctl can be used to control some aspects of
-the cards operation::
+the card's operation::
 
     int options = 0;
     ioctl(fd, WDIOC_SETOPTIONS, &options);
diff --git a/Documentation/watchdog/watchdog-kernel-api.rst b/Documentation/watchdog/watchdog-kernel-api.rst
index 7a907cb6f3d3..19755d0d3020 100644
--- a/Documentation/watchdog/watchdog-kernel-api.rst
+++ b/Documentation/watchdog/watchdog-kernel-api.rst
@@ -38,8 +38,8 @@ The watchdog_unregister_device routine deregisters a registered watchdog timer
 device. The parameter of this routine is the pointer to the registered
 watchdog_device structure.
 
-The watchdog subsystem includes an registration deferral mechanism,
-which allows you to register an watchdog as early as you wish during
+The watchdog subsystem includes a registration deferral mechanism,
+which allows you to register a watchdog as early as you wish during
 the boot process.
 
 There is also a resource-managed watchdog_register_device(),
@@ -68,13 +68,14 @@ The watchdog device structure looks like this::
 	unsigned int max_hw_heartbeat_ms;
 	struct notifier_block reboot_nb;
 	struct notifier_block restart_nb;
+	struct notifier_block pm_nb;
 	void *driver_data;
 	struct watchdog_core_data *wd_data;
 	unsigned long status;
 	struct list_head deferred;
   };
 
-It contains following fields:
+It contains the following fields:
 
 * id: set by watchdog_register_device, id 0 is special. It has both a
   /dev/watchdog0 cdev (dynamic major, minor 0) as well as the old
@@ -113,6 +114,8 @@ It contains following fields:
   internal use only. If a watchdog is capable of restarting the machine, it
   should define ops->restart. Priority can be changed through
   watchdog_set_restart_priority.
+* pm_nb: coordinates watchdog_dev_suspend/resume to cancel a ping worker
+  during suspend and restore it during resume.
 * bootstatus: status of the device after booting (reported with watchdog
   WDIOF_* status bits).
 * driver_data: a pointer to the drivers private data of a watchdog device.
@@ -212,7 +215,7 @@ they are supported. These optional routines/operations are:
   If the watchdog driver does not have to perform any action but setting the
   watchdog_device.timeout, this callback can be omitted.
 
-  If set_timeout is not provided but, WDIOF_SETTIMEOUT is set, the watchdog
+  If set_timeout is not provided but WDIOF_SETTIMEOUT is set, the watchdog
   infrastructure updates the timeout value of the watchdog_device internally
   to the requested value.
 
@@ -228,7 +231,7 @@ they are supported. These optional routines/operations are:
   the watchdog". A value of 0 disables pretimeout notification.
 
   (Note: the WDIOF_PRETIMEOUT needs to be set in the options field of the
-  watchdog's info structure).
+  watchdog's info structure.)
 
   If the watchdog driver does not have to perform any action but setting the
   watchdog_device.pretimeout, this callback can be omitted. That means if
@@ -247,7 +250,7 @@ they are supported. These optional routines/operations are:
 The status bits should (preferably) be set with the set_bit and clear_bit alike
 bit-operations. The status bits that are defined are:
 
-* WDOG_ACTIVE: this status bit indicates whether or not a watchdog timer device
+* WDOG_ACTIVE: this status bit indicates whether a watchdog timer device
   is active or not from user perspective. User space is expected to send
   heartbeat requests to the driver while this flag is set.
 * WDOG_NO_WAY_OUT: this bit stores the nowayout setting for the watchdog.
@@ -262,6 +265,9 @@ bit-operations. The status bits that are defined are:
   then opening /dev/watchdog will skip the start operation but send a keepalive
   request instead.
 
+Helper Functions
+~~~~~~~~~~~~~~~~
+
   To set the WDOG_NO_WAY_OUT status bit (before registering your watchdog
   timer device) you can either:
 
@@ -339,7 +345,7 @@ To raise a pretimeout notification, the following function should be used::
   void watchdog_notify_pretimeout(struct watchdog_device *wdd)
 
 The function can be called in the interrupt context. If watchdog pretimeout
-governor framework (kbuild CONFIG_WATCHDOG_PRETIMEOUT_GOV symbol) is enabled,
+governor framework (kconfig CONFIG_WATCHDOG_PRETIMEOUT_GOV symbol) is enabled,
 an action is taken by a preconfigured pretimeout governor preassigned to
 the watchdog device. If watchdog pretimeout governor framework is not
 enabled, watchdog_notify_pretimeout() prints a notification message to
diff --git a/Documentation/watchdog/watchdog-parameters.rst b/Documentation/watchdog/watchdog-parameters.rst
index 8482cc976ce0..ec5f67c060cb 100644
--- a/Documentation/watchdog/watchdog-parameters.rst
+++ b/Documentation/watchdog/watchdog-parameters.rst
@@ -14,13 +14,22 @@ modules.
 -------------------------------------------------
 
 watchdog core:
+    handle_boot_enabled:
+	Watchdog core auto-updates boot-enabled watchdogs before userspace
+	takes over. Default is set by the kconfig option
+	CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED.
+
     open_timeout:
 	Maximum time, in seconds, for which the watchdog framework will take
 	care of pinging a running hardware watchdog until userspace opens the
 	corresponding /dev/watchdogN device. A value of 0 means an infinite
 	timeout. Setting this to a non-zero value can be useful to ensure that
 	either userspace comes up properly, or the board gets reset and allows
-	fallback logic in the bootloader to try something else.
+	fallback logic in the bootloader to try something else. Default is set
+	by the kconfig option CONFIG_WATCHDOG_OPEN_TIMEOUT.
+
+    stop_on_reboot:
+	Stops watchdogs on reboot (0 = keep watching, 1 = stop).
 
 -------------------------------------------------