* Re: [PATCH v3 22/33] docs: pps.txt: convert to ReST and rename to pps.rst
From: Rodolfo Giometti @ 2019-06-09 9:20 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet
In-Reply-To: <cb9274c1d5e94a74c5922c04d99b90554f2d804b.1560045490.git.mchehab+samsung@kernel.org>
On 09/06/2019 04:27, Mauro Carvalho Chehab wrote:
> This file is already in a good shape: just its title and
> adding some literal block markups is needed for it to be
> part of the document.
>
> While it has a small chapter with sysfs stuff, most of
> the document is focused on driver development.
>
> As it describes a kernel API, move it to the driver-api
> directory.
>
> In order to avoid conflicts, let's add an :orphan: tag
> to it, to be removed when added to the driver-api book.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@linux.it
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
^ permalink raw reply
* Re: [PATCH v3 00/33] Convert files to ReST - part 1
From: Heiko Carstens @ 2019-06-09 9:27 UTC (permalink / raw)
To: Markus Heiser
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet,
Palmer Dabbelt, Albert Ou, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Greentime Hu,
Vincent Chen, linux-riscv, netdev, bpf
In-Reply-To: <56cd597a-9db8-b6ea-eed1-51d3bdf0e6e0@darmarit.de>
On Sun, Jun 09, 2019 at 11:22:36AM +0200, Markus Heiser wrote:
>
> Am 09.06.19 um 11:16 schrieb Heiko Carstens:
> >Will there be a web page (e.g. kernel.org), which contains always the
> >latest upstream version?
>
> You are looking for the HTML docs on kernel.org?
>
> https://www.kernel.org/doc/html/latest/
Yes, thanks!
^ permalink raw reply
* [PATCH] block: document iostat changes for disk busy time accounting
From: Konstantin Khlebnikov @ 2019-06-09 11:14 UTC (permalink / raw)
To: linux-block, Jens Axboe, linux-kernel
Cc: Alan Jenkins, Jonathan Corbet, Mikulas Patocka, Mike Snitzer,
linux-doc
Since commit 5b18b5a73760 ("block: delete part_round_stats and switch to
less precise counting") io_ticks is approximated by adding one at each
start and end of requests if jiffies has changed.
This works perfectly for requests shorter than a jiffy. If requests runs
more than 2 jiffies some I/O time will not be accounted unless there are
other reuqests.
Fixes: 5b18b5a73760 ("block: delete part_round_stats and switch to less precise counting")
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Links: https://lore.kernel.org/lkml/155413438824.3201.15254568091182734151.stgit@buzz/
---
Documentation/iostats.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/iostats.txt b/Documentation/iostats.txt
index 49df45f90e8a..5d63b18bd6d1 100644
--- a/Documentation/iostats.txt
+++ b/Documentation/iostats.txt
@@ -97,6 +97,10 @@ Field 9 -- # of I/Os currently in progress
Field 10 -- # of milliseconds spent doing I/Os
This field increases so long as field 9 is nonzero.
+ Since 5.0 this field counts jiffies when at least one request was
+ started or completed. If request runs more than 2 jiffies then some
+ I/O time will not be accounted unless there are other requests.
+
Field 11 -- weighted # of milliseconds spent doing I/Os
This field is incremented at each I/O start, I/O completion, I/O
merge, or read of these stats by the number of I/Os in progress
^ permalink raw reply related
* Re: [PATCH v3 00/33] Convert files to ReST - part 1
From: Mauro Carvalho Chehab @ 2019-06-09 12:29 UTC (permalink / raw)
To: Heiko Carstens
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List, linux-kernel,
Jonathan Corbet, Palmer Dabbelt, Albert Ou, Alexei Starovoitov,
Daniel Borkmann, Martin KaFai Lau, Song Liu, Yonghong Song,
Greentime Hu, Vincent Chen, linux-riscv, netdev, bpf
In-Reply-To: <20190609091642.GA3705@osiris>
Em Sun, 9 Jun 2019 11:16:43 +0200
Heiko Carstens <heiko.carstens@de.ibm.com> escreveu:
> On Sat, Jun 08, 2019 at 11:26:50PM -0300, Mauro Carvalho Chehab wrote:
> > This is the first part of a series I wrote sometime ago where I manually
> > convert lots of files to be properly parsed by Sphinx as ReST files.
> >
> > As it touches on lot of stuff, this series is based on today's docs-next
> > + linux-next, at tag next-20190607.
> >
> > I have right now about 85 patches with this undergoing work. That's
> > because I opted to do ~1 patch per converted directory.
> >
> > That sounds too much to be send on a single round. So, I'm opting to split
> > it on 3 parts. Those patches should probably be good to be merged
> > either by subsystem maintainers or via the docs tree.
> >
> > I opted to mark new files not included yet to the main index.rst (directly or
> > indirectly ) with the :orphan: tag, in order to avoid adding warnings to the
> > build system. This should be removed after we find a "home" for all
> > the converted files within the new document tree arrangement.
> >
> > Both this series and the next parts are on my devel git tree,
> > at:
> >
> > https://git.linuxtv.org/mchehab/experimental.git/log/?h=convert_rst_renames_v4
> >
> > The final output in html (after all patches I currently have, including
> > the upcoming series) can be seen at:
> >
> > https://www.infradead.org/~mchehab/rst_conversion/
>
> Will there be a web page (e.g. kernel.org), which contains always the
> latest upstream version?
Yes:
https://www.kernel.org/doc/html/latest/
I guess this one is based on Linus tree.
Jon also maintains a version at:
https://static.lwn.net/kerneldoc/
I guess that one is based on docs-next branch from the Docs tree.
Btw, if you want to build it for yourself, you could use:
make htmldocs
If your system doesn't have all dependencies, it will give the
hints about how to install them.
>
> > docs: Debugging390.txt: convert table to ascii artwork
> > docs: s390: convert docs to ReST and rename to *.rst
> > s390: include/asm/debug.h add kerneldoc markups
>
> I can pick these up for s390. Or do you want to send the whole series
> in one go upstream?
Yeah, feel free to pick them via the s390 tree.
Regards,
Mauro
Thanks,
Mauro
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v3 23/33] docs: ptp.txt: convert to ReST and move to driver-api
From: Richard Cochran @ 2019-06-09 13:45 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, David S. Miller, netdev
In-Reply-To: <1736539355fdee1effe3b332cf3d93124394672b.1560045490.git.mchehab+samsung@kernel.org>
On Sat, Jun 08, 2019 at 11:27:13PM -0300, Mauro Carvalho Chehab wrote:
> The conversion is trivial: just adjust title markups.
>
> In order to avoid conflicts, let's add an :orphan: tag
> to it, to be removed when this file gets added to the
> driver-api book.
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* Re: [PATCH v3 30/33] docs: watchdog: convert docs to ReST and rename to *.rst
From: Guenter Roeck @ 2019-06-09 20:51 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Wim Van Sebroeck, Jerry Hoemann, linux-watchdog
In-Reply-To: <8c4657f2999cb81df52d73bdcb6a5fe02bd5677d.1560045490.git.mchehab+samsung@kernel.org>
On Sat, Jun 08, 2019 at 11:27:20PM -0300, Mauro Carvalho Chehab wrote:
> Convert those documents and prepare them to be part of the kernel
> API book, as most of the stuff there are related to the
> Kernel interfaces.
>
> Still, in the future, it would make sense to split the docs,
> as some of the stuff is clearly focused on sysadmin tasks.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Cc: Mauro Carvalho Chehab <mchehab@infradead.org>, linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> .../admin-guide/kernel-parameters.txt | 2 +-
> Documentation/kernel-per-CPU-kthreads.txt | 2 +-
> ....txt => convert_drivers_to_kernel_api.rst} | 109 +--
> .../watchdog/{hpwdt.txt => hpwdt.rst} | 25 +-
> Documentation/watchdog/index.rst | 25 +
> .../watchdog/{mlx-wdt.txt => mlx-wdt.rst} | 24 +-
> .../{pcwd-watchdog.txt => pcwd-watchdog.rst} | 13 +-
> .../{watchdog-api.txt => watchdog-api.rst} | 76 +-
> ...kernel-api.txt => watchdog-kernel-api.rst} | 91 ++-
> ...parameters.txt => watchdog-parameters.rst} | 672 +++++++++++++-----
> .../{watchdog-pm.txt => watchdog-pm.rst} | 3 +
> Documentation/watchdog/{wdt.txt => wdt.rst} | 31 +-
> MAINTAINERS | 2 +-
> drivers/watchdog/Kconfig | 6 +-
> drivers/watchdog/smsc37b787_wdt.c | 2 +-
> 15 files changed, 767 insertions(+), 316 deletions(-)
> rename Documentation/watchdog/{convert_drivers_to_kernel_api.txt => convert_drivers_to_kernel_api.rst} (75%)
> rename Documentation/watchdog/{hpwdt.txt => hpwdt.rst} (79%)
> create mode 100644 Documentation/watchdog/index.rst
> rename Documentation/watchdog/{mlx-wdt.txt => mlx-wdt.rst} (78%)
> rename Documentation/watchdog/{pcwd-watchdog.txt => pcwd-watchdog.rst} (89%)
> rename Documentation/watchdog/{watchdog-api.txt => watchdog-api.rst} (80%)
> rename Documentation/watchdog/{watchdog-kernel-api.txt => watchdog-kernel-api.rst} (90%)
> rename Documentation/watchdog/{watchdog-parameters.txt => watchdog-parameters.rst} (42%)
> rename Documentation/watchdog/{watchdog-pm.txt => watchdog-pm.rst} (92%)
> rename Documentation/watchdog/{wdt.txt => wdt.rst} (68%)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 0092a453f7dc..3d072ca532bb 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5182,7 +5182,7 @@
> Default: 3 = cyan.
>
> watchdog timers [HW,WDT] For information on watchdog timers,
> - see Documentation/watchdog/watchdog-parameters.txt
> + see Documentation/watchdog/watchdog-parameters.rst
> or other driver-specific files in the
> Documentation/watchdog/ directory.
>
> diff --git a/Documentation/kernel-per-CPU-kthreads.txt b/Documentation/kernel-per-CPU-kthreads.txt
> index 23b0c8b20cd1..5623b9916411 100644
> --- a/Documentation/kernel-per-CPU-kthreads.txt
> +++ b/Documentation/kernel-per-CPU-kthreads.txt
> @@ -348,7 +348,7 @@ To reduce its OS jitter, do at least one of the following:
> 2. Boot with "nosoftlockup=0", which will also prevent these kthreads
> from being created. Other related watchdog and softlockup boot
> parameters may be found in Documentation/admin-guide/kernel-parameters.rst
> - and Documentation/watchdog/watchdog-parameters.txt.
> + and Documentation/watchdog/watchdog-parameters.rst.
> 3. Echo a zero to /proc/sys/kernel/watchdog to disable the
> watchdog timer.
> 4. Echo a large number of /proc/sys/kernel/watchdog_thresh in
> diff --git a/Documentation/watchdog/convert_drivers_to_kernel_api.txt b/Documentation/watchdog/convert_drivers_to_kernel_api.rst
> similarity index 75%
> rename from Documentation/watchdog/convert_drivers_to_kernel_api.txt
> rename to Documentation/watchdog/convert_drivers_to_kernel_api.rst
> index 9fffb2958d13..dd934cc08e40 100644
> --- a/Documentation/watchdog/convert_drivers_to_kernel_api.txt
> +++ b/Documentation/watchdog/convert_drivers_to_kernel_api.rst
> @@ -1,6 +1,8 @@
> +=========================================================
> Converting old watchdog drivers to the watchdog framework
> +=========================================================
> +
> by Wolfram Sang <w.sang@pengutronix.de>
> -=========================================================
>
> Before the watchdog framework came into the kernel, every driver had to
> implement the API on its own. Now, as the framework factored out the common
> @@ -69,16 +71,16 @@ Here is a overview of the functions and probably needed actions:
> -ENOIOCTLCMD, the IOCTLs of the framework will be tried, too. Any other error
> is directly given to the user.
>
> -Example conversion:
> +Example conversion::
>
> --static const struct file_operations s3c2410wdt_fops = {
> -- .owner = THIS_MODULE,
> -- .llseek = no_llseek,
> -- .write = s3c2410wdt_write,
> -- .unlocked_ioctl = s3c2410wdt_ioctl,
> -- .open = s3c2410wdt_open,
> -- .release = s3c2410wdt_release,
> --};
> + -static const struct file_operations s3c2410wdt_fops = {
> + - .owner = THIS_MODULE,
> + - .llseek = no_llseek,
> + - .write = s3c2410wdt_write,
> + - .unlocked_ioctl = s3c2410wdt_ioctl,
> + - .open = s3c2410wdt_open,
> + - .release = s3c2410wdt_release,
> + -};
>
> Check the functions for device-specific stuff and keep it for later
> refactoring. The rest can go.
> @@ -89,24 +91,24 @@ Remove the miscdevice
>
> Since the file_operations are gone now, you can also remove the 'struct
> miscdevice'. The framework will create it on watchdog_dev_register() called by
> -watchdog_register_device().
> +watchdog_register_device()::
>
> --static struct miscdevice s3c2410wdt_miscdev = {
> -- .minor = WATCHDOG_MINOR,
> -- .name = "watchdog",
> -- .fops = &s3c2410wdt_fops,
> --};
> + -static struct miscdevice s3c2410wdt_miscdev = {
> + - .minor = WATCHDOG_MINOR,
> + - .name = "watchdog",
> + - .fops = &s3c2410wdt_fops,
> + -};
>
>
> Remove obsolete includes and defines
> ------------------------------------
>
> Because of the simplifications, a few defines are probably unused now. Remove
> -them. Includes can be removed, too. For example:
> +them. Includes can be removed, too. For example::
>
> -- #include <linux/fs.h>
> -- #include <linux/miscdevice.h> (if MODULE_ALIAS_MISCDEV is not used)
> -- #include <linux/uaccess.h> (if no custom IOCTLs are used)
> + - #include <linux/fs.h>
> + - #include <linux/miscdevice.h> (if MODULE_ALIAS_MISCDEV is not used)
> + - #include <linux/uaccess.h> (if no custom IOCTLs are used)
>
>
> Add the watchdog operations
> @@ -121,30 +123,30 @@ change the function header. Other changes are most likely not needed, because
> here simply happens the direct hardware access. If you have device-specific
> code left from the above steps, it should be refactored into these callbacks.
>
> -Here is a simple example:
> +Here is a simple example::
>
> -+static struct watchdog_ops s3c2410wdt_ops = {
> -+ .owner = THIS_MODULE,
> -+ .start = s3c2410wdt_start,
> -+ .stop = s3c2410wdt_stop,
> -+ .ping = s3c2410wdt_keepalive,
> -+ .set_timeout = s3c2410wdt_set_heartbeat,
> -+};
> + +static struct watchdog_ops s3c2410wdt_ops = {
> + + .owner = THIS_MODULE,
> + + .start = s3c2410wdt_start,
> + + .stop = s3c2410wdt_stop,
> + + .ping = s3c2410wdt_keepalive,
> + + .set_timeout = s3c2410wdt_set_heartbeat,
> + +};
>
> -A typical function-header change looks like:
> +A typical function-header change looks like::
>
> --static void s3c2410wdt_keepalive(void)
> -+static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
> - {
> -...
> -+
> -+ return 0;
> - }
> + -static void s3c2410wdt_keepalive(void)
> + +static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
> + {
> + ...
> + +
> + + return 0;
> + }
>
> -...
> + ...
>
> -- s3c2410wdt_keepalive();
> -+ s3c2410wdt_keepalive(&s3c2410_wdd);
> + - s3c2410wdt_keepalive();
> + + s3c2410wdt_keepalive(&s3c2410_wdd);
>
>
> Add the watchdog device
> @@ -159,12 +161,12 @@ static variables. Those have to be converted to use the members in
> watchdog_device. Note that the timeout values are unsigned int. Some drivers
> use signed int, so this has to be converted, too.
>
> -Here is a simple example for a watchdog device:
> +Here is a simple example for a watchdog device::
>
> -+static struct watchdog_device s3c2410_wdd = {
> -+ .info = &s3c2410_wdt_ident,
> -+ .ops = &s3c2410wdt_ops,
> -+};
> + +static struct watchdog_device s3c2410_wdd = {
> + + .info = &s3c2410_wdt_ident,
> + + .ops = &s3c2410wdt_ops,
> + +};
>
>
> Handle the 'nowayout' feature
> @@ -173,12 +175,12 @@ Handle the 'nowayout' feature
> A few drivers use nowayout statically, i.e. there is no module parameter for it
> and only CONFIG_WATCHDOG_NOWAYOUT determines if the feature is going to be
> used. This needs to be converted by initializing the status variable of the
> -watchdog_device like this:
> +watchdog_device like this::
>
> .status = WATCHDOG_NOWAYOUT_INIT_STATUS,
>
> Most drivers, however, also allow runtime configuration of nowayout, usually
> -by adding a module parameter. The conversion for this would be something like:
> +by adding a module parameter. The conversion for this would be something like::
>
> watchdog_set_nowayout(&s3c2410_wdd, nowayout);
>
> @@ -191,15 +193,15 @@ Register the watchdog device
>
> Replace misc_register(&miscdev) with watchdog_register_device(&watchdog_dev).
> Make sure the return value gets checked and the error message, if present,
> -still fits. Also convert the unregister case.
> +still fits. Also convert the unregister case::
>
> -- ret = misc_register(&s3c2410wdt_miscdev);
> -+ ret = watchdog_register_device(&s3c2410_wdd);
> + - ret = misc_register(&s3c2410wdt_miscdev);
> + + ret = watchdog_register_device(&s3c2410_wdd);
>
> -...
> + ...
>
> -- misc_deregister(&s3c2410wdt_miscdev);
> -+ watchdog_unregister_device(&s3c2410_wdd);
> + - misc_deregister(&s3c2410wdt_miscdev);
> + + watchdog_unregister_device(&s3c2410_wdd);
>
>
> Update the Kconfig-entry
> @@ -207,7 +209,7 @@ Update the Kconfig-entry
>
> The entry for the driver now needs to select WATCHDOG_CORE:
>
> -+ select WATCHDOG_CORE
> + + select WATCHDOG_CORE
>
>
> Create a patch and send it to upstream
> @@ -215,4 +217,3 @@ Create a patch and send it to upstream
>
> Make sure you understood Documentation/process/submitting-patches.rst and send your patch to
> linux-watchdog@vger.kernel.org. We are looking forward to it :)
> -
> diff --git a/Documentation/watchdog/hpwdt.txt b/Documentation/watchdog/hpwdt.rst
> similarity index 79%
> rename from Documentation/watchdog/hpwdt.txt
> rename to Documentation/watchdog/hpwdt.rst
> index aaa9e4b4bdcd..94a96371113e 100644
> --- a/Documentation/watchdog/hpwdt.txt
> +++ b/Documentation/watchdog/hpwdt.rst
> @@ -1,7 +1,12 @@
> +===========================
> +HPE iLO NMI Watchdog Driver
> +===========================
> +
> +for iLO based ProLiant Servers
> +==============================
> +
> Last reviewed: 08/20/2018
>
> - HPE iLO NMI Watchdog Driver
> - for iLO based ProLiant Servers
>
> The HPE iLO NMI Watchdog driver is a kernel module that provides basic
> watchdog functionality and handler for the iLO "Generate NMI to System"
> @@ -20,23 +25,26 @@ Last reviewed: 08/20/2018
>
> The hpwdt driver also has the following module parameters:
>
> - soft_margin - allows the user to set the watchdog timer value.
> + ============ ================================================================
> + soft_margin allows the user to set the watchdog timer value.
> Default value is 30 seconds.
> - timeout - an alias of soft_margin.
> - pretimeout - allows the user to set the watchdog pretimeout value.
> + timeout an alias of soft_margin.
> + pretimeout allows the user to set the watchdog pretimeout value.
> This is the number of seconds before timeout when an
> NMI is delivered to the system. Setting the value to
> zero disables the pretimeout NMI.
> Default value is 9 seconds.
> - nowayout - basic watchdog parameter that does not allow the timer to
> + nowayout basic watchdog parameter that does not allow the timer to
> be restarted or an impending ASR to be escaped.
> Default value is set when compiling the kernel. If it is set
> to "Y", then there is no way of disabling the watchdog once
> it has been started.
> + ============ ================================================================
>
> - NOTE: More information about watchdog drivers in general, including the ioctl
> + NOTE:
> + More information about watchdog drivers in general, including the ioctl
> interface to /dev/watchdog can be found in
> - Documentation/watchdog/watchdog-api.txt and Documentation/IPMI.txt.
> + Documentation/watchdog/watchdog-api.rst and Documentation/IPMI.txt.
>
> Due to limitations in the iLO hardware, the NMI pretimeout if enabled,
> can only be set to 9 seconds. Attempts to set pretimeout to other
> @@ -63,4 +71,3 @@ Last reviewed: 08/20/2018
>
> The HPE iLO NMI Watchdog Driver and documentation were originally developed
> by Tom Mingarelli.
> -
> diff --git a/Documentation/watchdog/index.rst b/Documentation/watchdog/index.rst
> new file mode 100644
> index 000000000000..33a0de631e84
> --- /dev/null
> +++ b/Documentation/watchdog/index.rst
> @@ -0,0 +1,25 @@
> +:orphan:
> +
> +======================
> +Linux Watchdog Support
> +======================
> +
> +.. toctree::
> + :maxdepth: 1
> +
> + hpwdt
> + mlx-wdt
> + pcwd-watchdog
> + watchdog-api
> + watchdog-kernel-api
> + watchdog-parameters
> + watchdog-pm
> + wdt
> + convert_drivers_to_kernel_api
> +
> +.. only:: subproject and html
> +
> + Indices
> + =======
> +
> + * :ref:`genindex`
> diff --git a/Documentation/watchdog/mlx-wdt.txt b/Documentation/watchdog/mlx-wdt.rst
> similarity index 78%
> rename from Documentation/watchdog/mlx-wdt.txt
> rename to Documentation/watchdog/mlx-wdt.rst
> index 66eeb78505c3..bf5bafac47f0 100644
> --- a/Documentation/watchdog/mlx-wdt.txt
> +++ b/Documentation/watchdog/mlx-wdt.rst
> @@ -1,5 +1,9 @@
> - Mellanox watchdog drivers
> - for x86 based system switches
> +=========================
> +Mellanox watchdog drivers
> +=========================
> +
> +for x86 based system switches
> +=============================
>
> This driver provides watchdog functionality for various Mellanox
> Ethernet and Infiniband switch systems.
> @@ -9,16 +13,16 @@ Mellanox watchdog device is implemented in a programmable logic device.
> There are 2 types of HW watchdog implementations.
>
> Type 1:
> -Actual HW timeout can be defined as a power of 2 msec.
> -e.g. timeout 20 sec will be rounded up to 32768 msec.
> -The maximum timeout period is 32 sec (32768 msec.),
> -Get time-left isn't supported
> + Actual HW timeout can be defined as a power of 2 msec.
> + e.g. timeout 20 sec will be rounded up to 32768 msec.
> + The maximum timeout period is 32 sec (32768 msec.),
> + Get time-left isn't supported
>
> Type 2:
> -Actual HW timeout is defined in sec. and it's the same as
> -a user-defined timeout.
> -Maximum timeout is 255 sec.
> -Get time-left is supported.
> + Actual HW timeout is defined in sec. and it's the same as
> + a user-defined timeout.
> + Maximum timeout is 255 sec.
> + Get time-left is supported.
>
> Type 1 HW watchdog implementation exist in old systems and
> all new systems have type 2 HW watchdog.
> diff --git a/Documentation/watchdog/pcwd-watchdog.txt b/Documentation/watchdog/pcwd-watchdog.rst
> similarity index 89%
> rename from Documentation/watchdog/pcwd-watchdog.txt
> rename to Documentation/watchdog/pcwd-watchdog.rst
> index b8e60a441a43..405e2a370082 100644
> --- a/Documentation/watchdog/pcwd-watchdog.txt
> +++ b/Documentation/watchdog/pcwd-watchdog.rst
> @@ -1,8 +1,13 @@
> +===================================
> +Berkshire Products PC Watchdog Card
> +===================================
> +
> Last reviewed: 10/05/2007
>
> - Berkshire Products PC Watchdog Card
> - Support for ISA Cards Revision A and C
> - Documentation and Driver by Ken Hollis <kenji@bitgate.com>
> +Support for ISA Cards Revision A and C
> +=======================================
> +
> +Documentation and Driver by Ken Hollis <kenji@bitgate.com>
>
> The PC Watchdog is a card that offers the same type of functionality that
> the WDT card does, only it doesn't require an IRQ to run. Furthermore,
> @@ -33,6 +38,7 @@ Last reviewed: 10/05/2007
> WDIOC_GETSUPPORT
> This returns the support of the card itself. This
> returns in structure "PCWDS" which returns:
> +
> options = WDIOS_TEMPPANIC
> (This card supports temperature)
> firmware_version = xxxx
> @@ -63,4 +69,3 @@ Last reviewed: 10/05/2007
>
> -- Ken Hollis
> (kenji@bitgate.com)
> -
> diff --git a/Documentation/watchdog/watchdog-api.txt b/Documentation/watchdog/watchdog-api.rst
> similarity index 80%
> rename from Documentation/watchdog/watchdog-api.txt
> rename to Documentation/watchdog/watchdog-api.rst
> index 0e62ba33b7fb..c6c1e9fa9f73 100644
> --- a/Documentation/watchdog/watchdog-api.txt
> +++ b/Documentation/watchdog/watchdog-api.rst
> @@ -1,7 +1,10 @@
> +=============================
> +The Linux Watchdog driver API
> +=============================
> +
> Last reviewed: 10/05/2007
>
>
> -The Linux Watchdog driver API.
>
> Copyright 2002 Christer Weingel <wingel@nano-system.com>
>
> @@ -10,7 +13,8 @@ driver which is (c) Copyright 2000 Jakob Oestergaard <jakob@ostenfeld.dk>
>
> This document describes the state of the Linux 2.4.18 kernel.
>
> -Introduction:
> +Introduction
> +============
>
> A Watchdog Timer (WDT) is a hardware circuit that can reset the
> computer system in case of a software fault. You probably knew that
> @@ -30,7 +34,8 @@ drivers implement different, and sometimes incompatible, parts of it.
> This file is an attempt to document the existing usage and allow
> future driver writers to use it as a reference.
>
> -The simplest API:
> +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
> @@ -54,7 +59,8 @@ after the timeout has passed. Watchdog devices also usually support
> the nowayout module parameter so that this option can be controlled at
> runtime.
>
> -Magic Close feature:
> +Magic Close feature
> +===================
>
> If a driver supports "Magic Close", the driver will not disable the
> watchdog unless a specific magic character 'V' has been sent to
> @@ -64,7 +70,8 @@ will assume that the daemon (and userspace in general) died, and will
> stop pinging the watchdog without disabling it first. This will then
> cause a reboot if the watchdog is not re-opened in sufficient time.
>
> -The ioctl API:
> +The ioctl API
> +=============
>
> All conforming drivers also support an ioctl API.
>
> @@ -73,7 +80,7 @@ Pinging the watchdog using an ioctl:
> All drivers that have an ioctl interface support at least one ioctl,
> KEEPALIVE. This ioctl does exactly the same thing as a write to the
> watchdog device, so the main loop in the above program could be
> -replaced with:
> +replaced with::
>
> while (1) {
> ioctl(fd, WDIOC_KEEPALIVE, 0);
> @@ -82,14 +89,15 @@ replaced with:
>
> the argument to the ioctl is ignored.
>
> -Setting and getting the timeout:
> +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
> 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
> -the requested one due to limitation of the hardware.
> +the requested one due to limitation of the hardware::
>
> int timeout = 45;
> ioctl(fd, WDIOC_SETTIMEOUT, &timeout);
> @@ -99,18 +107,19 @@ This example might actually print "The timeout was set to 60 seconds"
> if the device has a granularity of minutes for its timeout.
>
> Starting with the Linux 2.4.18 kernel, it is possible to query the
> -current timeout using the GETTIMEOUT ioctl.
> +current timeout using the GETTIMEOUT ioctl::
>
> ioctl(fd, WDIOC_GETTIMEOUT, &timeout);
> printf("The timeout was is %d seconds\n", timeout);
>
> -Pretimeouts:
> +Pretimeouts
> +===========
>
> Some watchdog timers can be set to have a trigger go off before the
> actual time they will reset the system. This can be done with an NMI,
> interrupt, or other mechanism. This allows Linux to record useful
> information (like panic information and kernel coredumps) before it
> -resets.
> +resets::
>
> pretimeout = 10;
> ioctl(fd, WDIOC_SETPRETIMEOUT, &pretimeout);
> @@ -121,89 +130,113 @@ the pretimeout. So, for instance, if you set the timeout to 60 seconds
> and the pretimeout to 10 seconds, the pretimeout will go off in 50
> seconds. Setting a pretimeout to zero disables it.
>
> -There is also a get function for getting the pretimeout:
> +There is also a get function for getting the pretimeout::
>
> ioctl(fd, WDIOC_GETPRETIMEOUT, &timeout);
> printf("The pretimeout was is %d seconds\n", timeout);
>
> Not all watchdog drivers will support a pretimeout.
>
> -Get the number of seconds before reboot:
> +Get the number of seconds before reboot
> +=======================================
>
> Some watchdog drivers have the ability to report the remaining time
> before the system will reboot. The WDIOC_GETTIMELEFT is the ioctl
> -that returns the number of seconds before reboot.
> +that returns the number of seconds before reboot::
>
> ioctl(fd, WDIOC_GETTIMELEFT, &timeleft);
> printf("The timeout was is %d seconds\n", timeleft);
>
> -Environmental monitoring:
> +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
> the reason for the last reboot of the system. The GETSUPPORT ioctl is
> -available to ask what the device can do:
> +available to ask what the device can do::
>
> struct watchdog_info ident;
> ioctl(fd, WDIOC_GETSUPPORT, &ident);
>
> the fields returned in the ident struct are:
>
> + ================ =============================================
> identity a string identifying the watchdog driver
> firmware_version the firmware version of the card if available
> options a flags describing what the device supports
> + ================ =============================================
>
> 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. [FIXME -- Is this correct?]
>
> + ================ =========================
> WDIOF_OVERHEAT Reset due to CPU overheat
> + ================ =========================
>
> 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
>
> + ============= ================
> WDIOF_EXTERN1 External relay 1
> + ============= ================
>
> External monitoring relay/source 1 was triggered. Controllers intended for
> real world applications include external monitoring pins that will trigger
> a reset.
>
> + ============= ================
> WDIOF_EXTERN2 External relay 2
> + ============= ================
>
> External monitoring relay/source 2 was triggered
>
> + ================ =====================
> WDIOF_POWERUNDER Power bad/power fault
> + ================ =====================
>
> The machine is showing an undervoltage status
>
> + =============== =============================
> WDIOF_CARDRESET Card previously reset the CPU
> + =============== =============================
>
> 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
> sense.
>
> + =================== =====================
> WDIOF_KEEPALIVEPING Keep alive ping reply
> + =================== =====================
>
> The watchdog saw a keepalive ping since it was last queried.
>
> + ================ =======================
> WDIOF_SETTIMEOUT Can set/get the timeout
> + ================ =======================
>
> The watchdog can do pretimeouts.
>
> + ================ ================================
> WDIOF_PRETIMEOUT Pretimeout (in seconds), get/set
> + ================ ================================
>
>
> 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
> -status, and the status at the last reboot, respectively.
> +status, and the status at the last reboot, respectively::
>
> int flags;
> ioctl(fd, WDIOC_GETSTATUS, &flags);
> @@ -216,22 +249,23 @@ Note that not all devices support these two calls, and some only
> support the GETBOOTSTATUS call.
>
> Some drivers can measure the temperature using the GETTEMP ioctl. The
> -returned value is the temperature in degrees fahrenheit.
> +returned value is the temperature in degrees fahrenheit::
>
> int temperature;
> ioctl(fd, WDIOC_GETTEMP, &temperature);
>
> Finally the SETOPTIONS ioctl can be used to control some aspects of
> -the cards operation.
> +the cards operation::
>
> int options = 0;
> ioctl(fd, WDIOC_SETOPTIONS, &options);
>
> The following options are available:
>
> + ================= ================================
> WDIOS_DISABLECARD Turn off the watchdog timer
> WDIOS_ENABLECARD Turn on the watchdog timer
> WDIOS_TEMPPANIC Kernel panic on temperature trip
> + ================= ================================
>
> [FIXME -- better explanations]
> -
> diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.rst
> similarity index 90%
> rename from Documentation/watchdog/watchdog-kernel-api.txt
> rename to Documentation/watchdog/watchdog-kernel-api.rst
> index 3a91ef5af044..864edbe932c1 100644
> --- a/Documentation/watchdog/watchdog-kernel-api.txt
> +++ b/Documentation/watchdog/watchdog-kernel-api.rst
> @@ -1,5 +1,7 @@
> -The Linux WatchDog Timer Driver Core kernel API.
> ===============================================
> +The Linux WatchDog Timer Driver Core kernel API
> +===============================================
> +
> Last reviewed: 12-Feb-2013
>
> Wim Van Sebroeck <wim@iguana.be>
> @@ -9,7 +11,7 @@ Introduction
> This document does not describe what a WatchDog Timer (WDT) Driver or Device is.
> It also does not describe the API which can be used by user space to communicate
> with a WatchDog Timer. If you want to know this then please read the following
> -file: Documentation/watchdog/watchdog-api.txt .
> +file: Documentation/watchdog/watchdog-api.rst .
>
> So what does this document describe? It describes the API that can be used by
> WatchDog Timer Drivers that want to use the WatchDog Timer Driver Core
> @@ -23,10 +25,10 @@ The API
> Each watchdog timer driver that wants to use the WatchDog Timer Driver Core
> must #include <linux/watchdog.h> (you would have to do this anyway when
> writing a watchdog device driver). This include file contains following
> -register/unregister routines:
> +register/unregister routines::
>
> -extern int watchdog_register_device(struct watchdog_device *);
> -extern void watchdog_unregister_device(struct watchdog_device *);
> + extern int watchdog_register_device(struct watchdog_device *);
> + extern void watchdog_unregister_device(struct watchdog_device *);
>
> The watchdog_register_device routine registers a watchdog timer device.
> The parameter of this routine is a pointer to a watchdog_device structure.
> @@ -40,9 +42,9 @@ The watchdog subsystem includes an registration deferral mechanism,
> which allows you to register an watchdog as early as you wish during
> the boot process.
>
> -The watchdog device structure looks like this:
> +The watchdog device structure looks like this::
>
> -struct watchdog_device {
> + struct watchdog_device {
> int id;
> struct device *parent;
> const struct attribute_group **groups;
> @@ -62,9 +64,10 @@ struct watchdog_device {
> struct watchdog_core_data *wd_data;
> unsigned long status;
> struct list_head deferred;
> -};
> + };
>
> It contains 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
> /dev/watchdog miscdev. The id is set automatically when calling
> @@ -114,9 +117,9 @@ It contains following fields:
> * deferred: entry in wtd_deferred_reg_list which is used to
> register early initialized watchdogs.
>
> -The list of watchdog operations is defined as:
> +The list of watchdog operations is defined as::
>
> -struct watchdog_ops {
> + struct watchdog_ops {
> struct module *owner;
> /* mandatory operations */
> int (*start)(struct watchdog_device *);
> @@ -129,7 +132,7 @@ struct watchdog_ops {
> unsigned int (*get_timeleft)(struct watchdog_device *);
> int (*restart)(struct watchdog_device *);
> long (*ioctl)(struct watchdog_device *, unsigned int, unsigned long);
> -};
> + };
>
> It is important that you first define the module owner of the watchdog timer
> driver's operations. This module owner will be used to lock the module when
> @@ -138,6 +141,7 @@ module and /dev/watchdog is still open).
>
> Some operations are mandatory and some are optional. The mandatory operations
> are:
> +
> * start: this is a pointer to the routine that starts the watchdog timer
> device.
> The routine needs a pointer to the watchdog timer device structure as a
> @@ -146,51 +150,64 @@ are:
> Not all watchdog timer hardware supports the same functionality. That's why
> all other routines/operations are optional. They only need to be provided if
> they are supported. These optional routines/operations are:
> +
> * stop: with this routine the watchdog timer device is being stopped.
> +
> The routine needs a pointer to the watchdog timer device structure as a
> parameter. It returns zero on success or a negative errno code for failure.
> Some watchdog timer hardware can only be started and not be stopped. A
> driver supporting such hardware does not have to implement the stop routine.
> +
> If a driver has no stop function, the watchdog core will set WDOG_HW_RUNNING
> and start calling the driver's keepalive pings function after the watchdog
> device is closed.
> +
> If a watchdog driver does not implement the stop function, it must set
> max_hw_heartbeat_ms.
> * ping: this is the routine that sends a keepalive ping to the watchdog timer
> hardware.
> +
> The routine needs a pointer to the watchdog timer device structure as a
> parameter. It returns zero on success or a negative errno code for failure.
> +
> Most hardware that does not support this as a separate function uses the
> start function to restart the watchdog timer hardware. And that's also what
> the watchdog timer driver core does: to send a keepalive ping to the watchdog
> timer hardware it will either use the ping operation (when available) or the
> start operation (when the ping operation is not available).
> +
> (Note: the WDIOC_KEEPALIVE ioctl call will only be active when the
> WDIOF_KEEPALIVEPING bit has been set in the option field on the watchdog's
> info structure).
> * status: this routine checks the status of the watchdog timer device. The
> status of the device is reported with watchdog WDIOF_* status flags/bits.
> +
> WDIOF_MAGICCLOSE and WDIOF_KEEPALIVEPING are reported by the watchdog core;
> it is not necessary to report those bits from the driver. Also, if no status
> function is provided by the driver, the watchdog core reports the status bits
> provided in the bootstatus variable of struct watchdog_device.
> +
> * set_timeout: this routine checks and changes the timeout of the watchdog
> timer device. It returns 0 on success, -EINVAL for "parameter out of range"
> and -EIO for "could not write value to the watchdog". On success this
> routine should set the timeout value of the watchdog_device to the
> achieved timeout value (which may be different from the requested one
> because the watchdog does not necessarily have a 1 second resolution).
> +
> Drivers implementing max_hw_heartbeat_ms set the hardware watchdog heartbeat
> to the minimum of timeout and max_hw_heartbeat_ms. Those drivers set the
> timeout value of the watchdog_device either to the requested timeout value
> (if it is larger than max_hw_heartbeat_ms), or to the achieved timeout value.
> (Note: the WDIOF_SETTIMEOUT needs to be set in the options field of the
> watchdog's info structure).
> +
> 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
> infrastructure updates the timeout value of the watchdog_device internally
> to the requested value.
> +
> If the pretimeout feature is used (WDIOF_PRETIMEOUT), then set_timeout must
> also take care of checking if pretimeout is still valid and set up the timer
> accordingly. This can't be done in the core without races, so it is the
> @@ -201,13 +218,16 @@ they are supported. These optional routines/operations are:
> seconds before the actual timeout would happen. It returns 0 on success,
> -EINVAL for "parameter out of range" and -EIO for "could not write value to
> 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).
> +
> 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
> set_pretimeout is not provided but WDIOF_PRETIMEOUT is set, the watchdog
> infrastructure updates the pretimeout value of the watchdog_device internally
> to the requested value.
> +
> * get_timeleft: this routines returns the time that's left before a reset.
> * restart: this routine restarts the machine. It returns 0 on success or a
> negative errno code for failure.
> @@ -218,6 +238,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
> is active or not from user perspective. User space is expected to send
> heartbeat requests to the driver while this flag is set.
> @@ -235,22 +256,30 @@ bit-operations. The status bits that are defined are:
>
> To set the WDOG_NO_WAY_OUT status bit (before registering your watchdog
> timer device) you can either:
> +
> * set it statically in your watchdog_device struct with
> +
> .status = WATCHDOG_NOWAYOUT_INIT_STATUS,
> +
> (this will set the value the same as CONFIG_WATCHDOG_NOWAYOUT) or
> - * use the following helper function:
> - static inline void watchdog_set_nowayout(struct watchdog_device *wdd, int nowayout)
> + * use the following helper function::
> +
> + static inline void watchdog_set_nowayout(struct watchdog_device *wdd,
> + int nowayout)
> +
> +Note:
> + The WatchDog Timer Driver Core supports the magic close feature and
> + the nowayout feature. To use the magic close feature you must set the
> + WDIOF_MAGICCLOSE bit in the options field of the watchdog's info structure.
>
> -Note: The WatchDog Timer Driver Core supports the magic close feature and
> -the nowayout feature. To use the magic close feature you must set the
> -WDIOF_MAGICCLOSE bit in the options field of the watchdog's info structure.
> The nowayout feature will overrule the magic close feature.
>
> To get or set driver specific data the following two helper functions should be
> -used:
> +used::
>
> -static inline void watchdog_set_drvdata(struct watchdog_device *wdd, void *data)
> -static inline void *watchdog_get_drvdata(struct watchdog_device *wdd)
> + static inline void watchdog_set_drvdata(struct watchdog_device *wdd,
> + void *data)
> + static inline void *watchdog_get_drvdata(struct watchdog_device *wdd)
>
> The watchdog_set_drvdata function allows you to add driver specific data. The
> arguments of this function are the watchdog device where you want to add the
> @@ -260,10 +289,11 @@ The watchdog_get_drvdata function allows you to retrieve driver specific data.
> The argument of this function is the watchdog device where you want to retrieve
> data from. The function returns the pointer to the driver specific data.
>
> -To initialize the timeout field, the following function can be used:
> +To initialize the timeout field, the following function can be used::
>
> -extern int watchdog_init_timeout(struct watchdog_device *wdd,
> - unsigned int timeout_parm, struct device *dev);
> + extern int watchdog_init_timeout(struct watchdog_device *wdd,
> + unsigned int timeout_parm,
> + struct device *dev);
>
> The watchdog_init_timeout function allows you to initialize the timeout field
> using the module timeout parameter or by retrieving the timeout-sec property from
> @@ -272,30 +302,33 @@ to set the default timeout value as timeout value in the watchdog_device and
> then use this function to set the user "preferred" timeout value.
> This routine returns zero on success and a negative errno code for failure.
>
> -To disable the watchdog on reboot, the user must call the following helper:
> +To disable the watchdog on reboot, the user must call the following helper::
>
> -static inline void watchdog_stop_on_reboot(struct watchdog_device *wdd);
> + static inline void watchdog_stop_on_reboot(struct watchdog_device *wdd);
>
> To disable the watchdog when unregistering the watchdog, the user must call
> the following helper. Note that this will only stop the watchdog if the
> nowayout flag is not set.
>
> -static inline void watchdog_stop_on_unregister(struct watchdog_device *wdd);
> +::
> +
> + static inline void watchdog_stop_on_unregister(struct watchdog_device *wdd);
>
> To change the priority of the restart handler the following helper should be
> -used:
> +used::
>
> -void watchdog_set_restart_priority(struct watchdog_device *wdd, int priority);
> + void watchdog_set_restart_priority(struct watchdog_device *wdd, int priority);
>
> User should follow the following guidelines for setting the priority:
> +
> * 0: should be called in last resort, has limited restart capabilities
> * 128: default restart handler, use if no other handler is expected to be
> available, and/or if restart is sufficient to restart the entire system
> * 255: highest priority, will preempt all other restart handlers
>
> -To raise a pretimeout notification, the following function should be used:
> +To raise a pretimeout notification, the following function should be used::
>
> -void watchdog_notify_pretimeout(struct watchdog_device *wdd)
> + 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,
> diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.rst
> similarity index 42%
> rename from Documentation/watchdog/watchdog-parameters.txt
> rename to Documentation/watchdog/watchdog-parameters.rst
> index 0b88e333f9e1..b121caae7798 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.rst
> @@ -1,410 +1,736 @@
> +==========================
> +WatchDog Module Parameters
> +==========================
> +
> This file provides information on the module parameters of many of
> the Linux watchdog drivers. Watchdog driver parameter specs should
> be listed here unless the driver has its own driver-specific information
> file.
>
> -
> See Documentation/admin-guide/kernel-parameters.rst for information on
> providing kernel parameters for builtin drivers versus loadable
> modules.
>
> -
> -------------------------------------------------
> +
> acquirewdt:
> -wdt_stop: Acquire WDT 'stop' io port (default 0x43)
> -wdt_start: Acquire WDT 'start' io port (default 0x443)
> -nowayout: Watchdog cannot be stopped once started
> + wdt_stop:
> + Acquire WDT 'stop' io port (default 0x43)
> + wdt_start:
> + Acquire WDT 'start' io port (default 0x443)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> advantechwdt:
> -wdt_stop: Advantech WDT 'stop' io port (default 0x443)
> -wdt_start: Advantech WDT 'start' io port (default 0x443)
> -timeout: Watchdog timeout in seconds. 1<= timeout <=63, default=60.
> -nowayout: Watchdog cannot be stopped once started
> + wdt_stop:
> + Advantech WDT 'stop' io port (default 0x443)
> + wdt_start:
> + Advantech WDT 'start' io port (default 0x443)
> + timeout:
> + Watchdog timeout in seconds. 1<= timeout <=63, default=60.
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> alim1535_wdt:
> -timeout: Watchdog timeout in seconds. (0 < timeout < 18000, default=60
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in seconds. (0 < timeout < 18000, default=60
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> alim7101_wdt:
> -timeout: Watchdog timeout in seconds. (1<=timeout<=3600, default=30
> -use_gpio: Use the gpio watchdog (required by old cobalt boards).
> + timeout:
> + Watchdog timeout in seconds. (1<=timeout<=3600, default=30
> + use_gpio:
> + Use the gpio watchdog (required by old cobalt boards).
> default=0/off/no
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> ar7_wdt:
> -margin: Watchdog margin in seconds (default=60)
> -nowayout: Disable watchdog shutdown on close
> + margin:
> + Watchdog margin in seconds (default=60)
> + nowayout:
> + Disable watchdog shutdown on close
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> armada_37xx_wdt:
> -timeout: Watchdog timeout in seconds. (default=120)
> -nowayout: Disable watchdog shutdown on close
> + timeout:
> + Watchdog timeout in seconds. (default=120)
> + nowayout:
> + Disable watchdog shutdown on close
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> at91rm9200_wdt:
> -wdt_time: Watchdog time in seconds. (default=5)
> -nowayout: Watchdog cannot be stopped once started
> + wdt_time:
> + Watchdog time in seconds. (default=5)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> at91sam9_wdt:
> -heartbeat: Watchdog heartbeats in seconds. (default = 15)
> -nowayout: Watchdog cannot be stopped once started
> + heartbeat:
> + Watchdog heartbeats in seconds. (default = 15)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> bcm47xx_wdt:
> -wdt_time: Watchdog time in seconds. (default=30)
> -nowayout: Watchdog cannot be stopped once started
> + wdt_time:
> + Watchdog time in seconds. (default=30)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> coh901327_wdt:
> -margin: Watchdog margin in seconds (default 60s)
> + margin:
> + Watchdog margin in seconds (default 60s)
> +
> -------------------------------------------------
> +
> cpu5wdt:
> -port: base address of watchdog card, default is 0x91
> -verbose: be verbose, default is 0 (no)
> -ticks: count down ticks, default is 10000
> + port:
> + base address of watchdog card, default is 0x91
> + verbose:
> + be verbose, default is 0 (no)
> + ticks:
> + count down ticks, default is 10000
> +
> -------------------------------------------------
> +
> cpwd:
> -wd0_timeout: Default watchdog0 timeout in 1/10secs
> -wd1_timeout: Default watchdog1 timeout in 1/10secs
> -wd2_timeout: Default watchdog2 timeout in 1/10secs
> + wd0_timeout:
> + Default watchdog0 timeout in 1/10secs
> + wd1_timeout:
> + Default watchdog1 timeout in 1/10secs
> + wd2_timeout:
> + Default watchdog2 timeout in 1/10secs
> +
> -------------------------------------------------
> +
> da9052wdt:
> -timeout: Watchdog timeout in seconds. 2<= timeout <=131, default=2.048s
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in seconds. 2<= timeout <=131, default=2.048s
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> davinci_wdt:
> -heartbeat: Watchdog heartbeat period in seconds from 1 to 600, default 60
> + heartbeat:
> + Watchdog heartbeat period in seconds from 1 to 600, default 60
> +
> -------------------------------------------------
> +
> ebc-c384_wdt:
> -timeout: Watchdog timeout in seconds. (1<=timeout<=15300, default=60)
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in seconds. (1<=timeout<=15300, default=60)
> + nowayout:
> + Watchdog cannot be stopped once started
> +
> -------------------------------------------------
> +
> ep93xx_wdt:
> -nowayout: Watchdog cannot be stopped once started
> -timeout: Watchdog timeout in seconds. (1<=timeout<=3600, default=TBD)
> + nowayout:
> + Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in seconds. (1<=timeout<=3600, default=TBD)
> +
> -------------------------------------------------
> +
> eurotechwdt:
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> -io: Eurotech WDT io port (default=0x3f0)
> -irq: Eurotech WDT irq (default=10)
> -ev: Eurotech WDT event type (default is `int')
> + io:
> + Eurotech WDT io port (default=0x3f0)
> + irq:
> + Eurotech WDT irq (default=10)
> + ev:
> + Eurotech WDT event type (default is `int`)
> +
> -------------------------------------------------
> +
> gef_wdt:
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> geodewdt:
> -timeout: Watchdog timeout in seconds. 1<= timeout <=131, default=60.
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in seconds. 1<= timeout <=131, default=60.
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> i6300esb:
> -heartbeat: Watchdog heartbeat in seconds. (1<heartbeat<2046, default=30)
> -nowayout: Watchdog cannot be stopped once started
> + heartbeat:
> + Watchdog heartbeat in seconds. (1<heartbeat<2046, default=30)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> iTCO_wdt:
> -heartbeat: Watchdog heartbeat in seconds.
> + heartbeat:
> + Watchdog heartbeat in seconds.
> (2<heartbeat<39 (TCO v1) or 613 (TCO v2), default=30)
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> iTCO_vendor_support:
> -vendorsupport: iTCO vendor specific support mode, default=0 (none),
> + vendorsupport:
> + iTCO vendor specific support mode, default=0 (none),
> 1=SuperMicro Pent3, 2=SuperMicro Pent4+, 911=Broken SMI BIOS
> +
> -------------------------------------------------
> +
> ib700wdt:
> -timeout: Watchdog timeout in seconds. 0<= timeout <=30, default=30.
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in seconds. 0<= timeout <=30, default=30.
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> ibmasr:
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> imx2_wdt:
> -timeout: Watchdog timeout in seconds (default 60 s)
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in seconds (default 60 s)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> indydog:
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> iop_wdt:
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> it8712f_wdt:
> -margin: Watchdog margin in seconds (default 60)
> -nowayout: Disable watchdog shutdown on close
> + margin:
> + Watchdog margin in seconds (default 60)
> + nowayout:
> + Disable watchdog shutdown on close
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> it87_wdt:
> -nogameport: Forbid the activation of game port, default=0
> -nocir: Forbid the use of CIR (workaround for some buggy setups); set to 1 if
> + nogameport:
> + Forbid the activation of game port, default=0
> + nocir:
> + Forbid the use of CIR (workaround for some buggy setups); set to 1 if
> system resets despite watchdog daemon running, default=0
> -exclusive: Watchdog exclusive device open, default=1
> -timeout: Watchdog timeout in seconds, default=60
> -testmode: Watchdog test mode (1 = no reboot), default=0
> -nowayout: Watchdog cannot be stopped once started
> + exclusive:
> + Watchdog exclusive device open, default=1
> + timeout:
> + Watchdog timeout in seconds, default=60
> + testmode:
> + Watchdog test mode (1 = no reboot), default=0
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> ixp4xx_wdt:
> -heartbeat: Watchdog heartbeat in seconds (default 60s)
> -nowayout: Watchdog cannot be stopped once started
> + heartbeat:
> + Watchdog heartbeat in seconds (default 60s)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> ks8695_wdt:
> -wdt_time: Watchdog time in seconds. (default=5)
> -nowayout: Watchdog cannot be stopped once started
> + wdt_time:
> + Watchdog time in seconds. (default=5)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> machzwd:
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> -action: after watchdog resets, generate:
> + action:
> + after watchdog resets, generate:
> 0 = RESET(*) 1 = SMI 2 = NMI 3 = SCI
> +
> -------------------------------------------------
> +
> max63xx_wdt:
> -heartbeat: Watchdog heartbeat period in seconds from 1 to 60, default 60
> -nowayout: Watchdog cannot be stopped once started
> + heartbeat:
> + Watchdog heartbeat period in seconds from 1 to 60, default 60
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> -nodelay: Force selection of a timeout setting without initial delay
> + nodelay:
> + Force selection of a timeout setting without initial delay
> (max6373/74 only, default=0)
> +
> -------------------------------------------------
> +
> mixcomwd:
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> mpc8xxx_wdt:
> -timeout: Watchdog timeout in ticks. (0<timeout<65536, default=65535)
> -reset: Watchdog Interrupt/Reset Mode. 0 = interrupt, 1 = reset
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in ticks. (0<timeout<65536, default=65535)
> + reset:
> + Watchdog Interrupt/Reset Mode. 0 = interrupt, 1 = reset
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> mv64x60_wdt:
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> ni903x_wdt:
> -timeout: Initial watchdog timeout in seconds (0<timeout<516, default=60)
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Initial watchdog timeout in seconds (0<timeout<516, default=60)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> nic7018_wdt:
> -timeout: Initial watchdog timeout in seconds (0<timeout<464, default=80)
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Initial watchdog timeout in seconds (0<timeout<464, default=80)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> nuc900_wdt:
> -heartbeat: Watchdog heartbeats in seconds.
> + heartbeat:
> + Watchdog heartbeats in seconds.
> (default = 15)
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> omap_wdt:
> -timer_margin: initial watchdog timeout (in seconds)
> -early_enable: Watchdog is started on module insertion (default=0
> -nowayout: Watchdog cannot be stopped once started
> + timer_margin:
> + initial watchdog timeout (in seconds)
> + early_enable:
> + Watchdog is started on module insertion (default=0
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> orion_wdt:
> -heartbeat: Initial watchdog heartbeat in seconds
> -nowayout: Watchdog cannot be stopped once started
> + heartbeat:
> + Initial watchdog heartbeat in seconds
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> pc87413_wdt:
> -io: pc87413 WDT I/O port (default: io).
> -timeout: Watchdog timeout in minutes (default=timeout).
> -nowayout: Watchdog cannot be stopped once started
> + io:
> + pc87413 WDT I/O port (default: io).
> + timeout:
> + Watchdog timeout in minutes (default=timeout).
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> pika_wdt:
> -heartbeat: Watchdog heartbeats in seconds. (default = 15)
> -nowayout: Watchdog cannot be stopped once started
> + heartbeat:
> + Watchdog heartbeats in seconds. (default = 15)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> pnx4008_wdt:
> -heartbeat: Watchdog heartbeat period in seconds from 1 to 60, default 19
> -nowayout: Set to 1 to keep watchdog running after device release
> + heartbeat:
> + Watchdog heartbeat period in seconds from 1 to 60, default 19
> + nowayout:
> + Set to 1 to keep watchdog running after device release
> +
> -------------------------------------------------
> +
> pnx833x_wdt:
> -timeout: Watchdog timeout in Mhz. (68Mhz clock), default=2040000000 (30 seconds)
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in Mhz. (68Mhz clock), default=2040000000 (30 seconds)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> -start_enabled: Watchdog is started on module insertion (default=1)
> + start_enabled:
> + Watchdog is started on module insertion (default=1)
> +
> -------------------------------------------------
> +
> rc32434_wdt:
> -timeout: Watchdog timeout value, in seconds (default=20)
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout value, in seconds (default=20)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> riowd:
> -riowd_timeout: Watchdog timeout in minutes (default=1)
> + riowd_timeout:
> + Watchdog timeout in minutes (default=1)
> +
> -------------------------------------------------
> +
> s3c2410_wdt:
> -tmr_margin: Watchdog tmr_margin in seconds. (default=15)
> -tmr_atboot: Watchdog is started at boot time if set to 1, default=0
> -nowayout: Watchdog cannot be stopped once started
> + tmr_margin:
> + Watchdog tmr_margin in seconds. (default=15)
> + tmr_atboot:
> + Watchdog is started at boot time if set to 1, default=0
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> -soft_noboot: Watchdog action, set to 1 to ignore reboots, 0 to reboot
> -debug: Watchdog debug, set to >1 for debug, (default 0)
> + soft_noboot:
> + Watchdog action, set to 1 to ignore reboots, 0 to reboot
> + debug:
> + Watchdog debug, set to >1 for debug, (default 0)
> +
> -------------------------------------------------
> +
> sa1100_wdt:
> -margin: Watchdog margin in seconds (default 60s)
> + margin:
> + Watchdog margin in seconds (default 60s)
> +
> -------------------------------------------------
> +
> sb_wdog:
> -timeout: Watchdog timeout in microseconds (max/default 8388607 or 8.3ish secs)
> + timeout:
> + Watchdog timeout in microseconds (max/default 8388607 or 8.3ish secs)
> +
> -------------------------------------------------
> +
> sbc60xxwdt:
> -wdt_stop: SBC60xx WDT 'stop' io port (default 0x45)
> -wdt_start: SBC60xx WDT 'start' io port (default 0x443)
> -timeout: Watchdog timeout in seconds. (1<=timeout<=3600, default=30)
> -nowayout: Watchdog cannot be stopped once started
> + wdt_stop:
> + SBC60xx WDT 'stop' io port (default 0x45)
> + wdt_start:
> + SBC60xx WDT 'start' io port (default 0x443)
> + timeout:
> + Watchdog timeout in seconds. (1<=timeout<=3600, default=30)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> sbc7240_wdt:
> -timeout: Watchdog timeout in seconds. (1<=timeout<=255, default=30)
> -nowayout: Disable watchdog when closing device file
> + timeout:
> + Watchdog timeout in seconds. (1<=timeout<=255, default=30)
> + nowayout:
> + Disable watchdog when closing device file
> +
> -------------------------------------------------
> +
> sbc8360:
> -timeout: Index into timeout table (0-63) (default=27 (60s))
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Index into timeout table (0-63) (default=27 (60s))
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> sbc_epx_c3:
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> sbc_fitpc2_wdt:
> -margin: Watchdog margin in seconds (default 60s)
> -nowayout: Watchdog cannot be stopped once started
> + margin:
> + Watchdog margin in seconds (default 60s)
> + nowayout:
> + Watchdog cannot be stopped once started
> +
> -------------------------------------------------
> +
> sbsa_gwdt:
> -timeout: Watchdog timeout in seconds. (default 10s)
> -action: Watchdog action at the first stage timeout,
> + timeout:
> + Watchdog timeout in seconds. (default 10s)
> + action:
> + Watchdog action at the first stage timeout,
> set to 0 to ignore, 1 to panic. (default=0)
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> sc1200wdt:
> -isapnp: When set to 0 driver ISA PnP support will be disabled (default=1)
> -io: io port
> -timeout: range is 0-255 minutes, default is 1
> -nowayout: Watchdog cannot be stopped once started
> + isapnp:
> + When set to 0 driver ISA PnP support will be disabled (default=1)
> + io:
> + io port
> + timeout:
> + range is 0-255 minutes, default is 1
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> sc520_wdt:
> -timeout: Watchdog timeout in seconds. (1 <= timeout <= 3600, default=30)
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in seconds. (1 <= timeout <= 3600, default=30)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> sch311x_wdt:
> -force_id: Override the detected device ID
> -therm_trip: Should a ThermTrip trigger the reset generator
> -timeout: Watchdog timeout in seconds. 1<= timeout <=15300, default=60
> -nowayout: Watchdog cannot be stopped once started
> + force_id:
> + Override the detected device ID
> + therm_trip:
> + Should a ThermTrip trigger the reset generator
> + timeout:
> + Watchdog timeout in seconds. 1<= timeout <=15300, default=60
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> scx200_wdt:
> -margin: Watchdog margin in seconds
> -nowayout: Disable watchdog shutdown on close
> + margin:
> + Watchdog margin in seconds
> + nowayout:
> + Disable watchdog shutdown on close
> +
> -------------------------------------------------
> +
> shwdt:
> -clock_division_ratio: Clock division ratio. Valid ranges are from 0x5 (1.31ms)
> + clock_division_ratio:
> + Clock division ratio. Valid ranges are from 0x5 (1.31ms)
> to 0x7 (5.25ms). (default=7)
> -heartbeat: Watchdog heartbeat in seconds. (1 <= heartbeat <= 3600, default=30
> -nowayout: Watchdog cannot be stopped once started
> + heartbeat:
> + Watchdog heartbeat in seconds. (1 <= heartbeat <= 3600, default=30
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> smsc37b787_wdt:
> -timeout: range is 1-255 units, default is 60
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + range is 1-255 units, default is 60
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> softdog:
> -soft_margin: Watchdog soft_margin in seconds.
> + soft_margin:
> + Watchdog soft_margin in seconds.
> (0 < soft_margin < 65536, default=60)
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> -soft_noboot: Softdog action, set to 1 to ignore reboots, 0 to reboot
> + soft_noboot:
> + Softdog action, set to 1 to ignore reboots, 0 to reboot
> (default=0)
> +
> -------------------------------------------------
> +
> stmp3xxx_wdt:
> -heartbeat: Watchdog heartbeat period in seconds from 1 to 4194304, default 19
> + heartbeat:
> + Watchdog heartbeat period in seconds from 1 to 4194304, default 19
> +
> -------------------------------------------------
> +
> tegra_wdt:
> -heartbeat: Watchdog heartbeats in seconds. (default = 120)
> -nowayout: Watchdog cannot be stopped once started
> + heartbeat:
> + Watchdog heartbeats in seconds. (default = 120)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> ts72xx_wdt:
> -timeout: Watchdog timeout in seconds. (1 <= timeout <= 8, default=8)
> -nowayout: Disable watchdog shutdown on close
> + timeout:
> + Watchdog timeout in seconds. (1 <= timeout <= 8, default=8)
> + nowayout:
> + Disable watchdog shutdown on close
> +
> -------------------------------------------------
> +
> twl4030_wdt:
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> txx9wdt:
> -timeout: Watchdog timeout in seconds. (0<timeout<N, default=60)
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in seconds. (0<timeout<N, default=60)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> uniphier_wdt:
> -timeout: Watchdog timeout in power of two seconds.
> + timeout:
> + Watchdog timeout in power of two seconds.
> (1 <= timeout <= 128, default=64)
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> w83627hf_wdt:
> -wdt_io: w83627hf/thf WDT io port (default 0x2E)
> -timeout: Watchdog timeout in seconds. 1 <= timeout <= 255, default=60.
> -nowayout: Watchdog cannot be stopped once started
> + wdt_io:
> + w83627hf/thf WDT io port (default 0x2E)
> + timeout:
> + Watchdog timeout in seconds. 1 <= timeout <= 255, default=60.
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> w83877f_wdt:
> -timeout: Watchdog timeout in seconds. (1<=timeout<=3600, default=30)
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in seconds. (1<=timeout<=3600, default=30)
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> w83977f_wdt:
> -timeout: Watchdog timeout in seconds (15..7635), default=45)
> -testmode: Watchdog testmode (1 = no reboot), default=0
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in seconds (15..7635), default=45)
> + testmode:
> + Watchdog testmode (1 = no reboot), default=0
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> wafer5823wdt:
> -timeout: Watchdog timeout in seconds. 1 <= timeout <= 255, default=60.
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in seconds. 1 <= timeout <= 255, default=60.
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> wdt285:
> -soft_margin: Watchdog timeout in seconds (default=60)
> + soft_margin:
> + Watchdog timeout in seconds (default=60)
> +
> -------------------------------------------------
> +
> wdt977:
> -timeout: Watchdog timeout in seconds (60..15300, default=60)
> -testmode: Watchdog testmode (1 = no reboot), default=0
> -nowayout: Watchdog cannot be stopped once started
> + timeout:
> + Watchdog timeout in seconds (60..15300, default=60)
> + testmode:
> + Watchdog testmode (1 = no reboot), default=0
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> wm831x_wdt:
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> wm8350_wdt:
> -nowayout: Watchdog cannot be stopped once started
> + nowayout:
> + Watchdog cannot be stopped once started
> (default=kernel config parameter)
> +
> -------------------------------------------------
> +
> sun4v_wdt:
> -timeout_ms: Watchdog timeout in milliseconds 1..180000, default=60000)
> -nowayout: Watchdog cannot be stopped once started
> --------------------------------------------------
> + timeout_ms:
> + Watchdog timeout in milliseconds 1..180000, default=60000)
> + nowayout:
> + Watchdog cannot be stopped once started
> diff --git a/Documentation/watchdog/watchdog-pm.txt b/Documentation/watchdog/watchdog-pm.rst
> similarity index 92%
> rename from Documentation/watchdog/watchdog-pm.txt
> rename to Documentation/watchdog/watchdog-pm.rst
> index 7a4dd46e0d24..646e1f28f31f 100644
> --- a/Documentation/watchdog/watchdog-pm.txt
> +++ b/Documentation/watchdog/watchdog-pm.rst
> @@ -1,5 +1,7 @@
> +===============================================
> The Linux WatchDog Timer Power Management Guide
> ===============================================
> +
> Last reviewed: 17-Dec-2018
>
> Wolfram Sang <wsa+renesas@sang-engineering.com>
> @@ -16,4 +18,5 @@ On resume, a watchdog timer shall be reset to its selected value to give
> userspace enough time to resume. [1] [2]
>
> [1] https://patchwork.kernel.org/patch/10252209/
> +
> [2] https://patchwork.kernel.org/patch/10711625/
> diff --git a/Documentation/watchdog/wdt.txt b/Documentation/watchdog/wdt.rst
> similarity index 68%
> rename from Documentation/watchdog/wdt.txt
> rename to Documentation/watchdog/wdt.rst
> index ed2f0b860869..d97b0361535b 100644
> --- a/Documentation/watchdog/wdt.txt
> +++ b/Documentation/watchdog/wdt.rst
> @@ -1,11 +1,14 @@
> +============================================================
> +WDT Watchdog Timer Interfaces For The Linux Operating System
> +============================================================
> +
> Last Reviewed: 10/05/2007
>
> - WDT Watchdog Timer Interfaces For The Linux Operating System
> - Alan Cox <alan@lxorguk.ukuu.org.uk>
> +Alan Cox <alan@lxorguk.ukuu.org.uk>
>
> - ICS WDT501-P
> - ICS WDT501-P (no fan tachometer)
> - ICS WDT500-P
> + - ICS WDT501-P
> + - ICS WDT501-P (no fan tachometer)
> + - ICS WDT500-P
>
> All the interfaces provide /dev/watchdog, which when open must be written
> to within a timeout or the machine will reboot. Each write delays the reboot
> @@ -21,19 +24,26 @@ degrees Fahrenheit. Each read returns a single byte giving the temperature.
> The third interface logs kernel messages on additional alert events.
>
> The ICS ISA-bus wdt card cannot be safely probed for. Instead you need to
> -pass IO address and IRQ boot parameters. E.g.:
> +pass IO address and IRQ boot parameters. E.g.::
> +
> wdt.io=0x240 wdt.irq=11
>
> Other "wdt" driver parameters are:
> +
> + =========== ======================================================
> heartbeat Watchdog heartbeat in seconds (default 60)
> nowayout Watchdog cannot be stopped once started (kernel
> - build parameter)
> + build parameter)
> tachometer WDT501-P Fan Tachometer support (0=disable, default=0)
> type WDT501-P Card type (500 or 501, default=500)
> + =========== ======================================================
>
> Features
> --------
> - WDT501P WDT500P
> +
> +================ ======= =======
> + WDT501P WDT500P
> +================ ======= =======
> Reboot Timer X X
> External Reboot X X
> I/O Port Monitor o o
> @@ -42,9 +52,12 @@ Fan Speed X o
> Power Under X o
> Power Over X o
> Overheat X o
> +================ ======= =======
>
> The external event interfaces on the WDT boards are not currently supported.
> Minor numbers are however allocated for it.
>
>
> -Example Watchdog Driver: see samples/watchdog/watchdog-simple.c
> +Example Watchdog Driver:
> +
> + see samples/watchdog/watchdog-simple.c
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 08efe50266b5..a9abccb2644b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7027,7 +7027,7 @@ F: drivers/media/usb/hdpvr/
> HEWLETT PACKARD ENTERPRISE ILO NMI WATCHDOG DRIVER
> M: Jerry Hoemann <jerry.hoemann@hpe.com>
> S: Supported
> -F: Documentation/watchdog/hpwdt.txt
> +F: Documentation/watchdog/hpwdt.rst
> F: drivers/watchdog/hpwdt.c
>
> HEWLETT-PACKARD SMART ARRAY RAID DRIVER (hpsa)
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index ffe754539f5a..6cad0b33d7ad 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -18,7 +18,7 @@ menuconfig WATCHDOG
> reboot the machine) and a driver for hardware watchdog boards, which
> are more robust and can also keep track of the temperature inside
> your computer. For details, read
> - <file:Documentation/watchdog/watchdog-api.txt> in the kernel source.
> + <file:Documentation/watchdog/watchdog-api.rst> in the kernel source.
>
> The watchdog is usually used together with the watchdog daemon
> which is available from
> @@ -1870,7 +1870,7 @@ config BOOKE_WDT
> Watchdog driver for PowerPC Book-E chips, such as the Freescale
> MPC85xx SOCs and the IBM PowerPC 440.
>
> - Please see Documentation/watchdog/watchdog-api.txt for
> + Please see Documentation/watchdog/watchdog-api.rst for
> more information.
>
> config BOOKE_WDT_DEFAULT_TIMEOUT
> @@ -2019,7 +2019,7 @@ config PCWATCHDOG
> This card simply watches your kernel to make sure it doesn't freeze,
> and if it does, it reboots your computer after a certain amount of
> time. This driver is like the WDT501 driver but for different
> - hardware. Please read <file:Documentation/watchdog/pcwd-watchdog.txt>. The PC
> + hardware. Please read <file:Documentation/watchdog/pcwd-watchdog.rst>. The PC
> watchdog cards can be ordered from <http://www.berkprod.com/>.
>
> To compile this driver as a module, choose M here: the
> diff --git a/drivers/watchdog/smsc37b787_wdt.c b/drivers/watchdog/smsc37b787_wdt.c
> index 13c817ea1d6a..f5713030d0f7 100644
> --- a/drivers/watchdog/smsc37b787_wdt.c
> +++ b/drivers/watchdog/smsc37b787_wdt.c
> @@ -36,7 +36,7 @@
> * mknod /dev/watchdog c 10 130
> *
> * For an example userspace keep-alive daemon, see:
> - * Documentation/watchdog/wdt.txt
> + * Documentation/watchdog/wdt.rst
> */
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
^ permalink raw reply
* Re: [PATCH v3 07/33] docs: cpu-freq: convert docs to ReST and rename to *.rst
From: Rafael J. Wysocki @ 2019-06-09 21:38 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab,
Linux Kernel Mailing List, Jonathan Corbet, Rafael J. Wysocki,
Viresh Kumar, Linux PM
In-Reply-To: <e8cb6d826e691a34996b6812851461b6000442e8.1560045490.git.mchehab+samsung@kernel.org>
On Sun, Jun 9, 2019 at 4:30 AM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
I have said "no" to this already twice.
How many times do I still need to repeat that?
There already is some cpufreq documentation under admin-guide in the
.rst format and the rest is obsolete. It is going to be replaced with
something new and more up to date.
The API docs need to go under driver-api and conversions like this
don't help. Indeed, they are counter-prodictive in my view.
DIsappointed,
Rafael
^ permalink raw reply
* Re: [PATCH v3 07/33] docs: cpu-freq: convert docs to ReST and rename to *.rst
From: Mauro Carvalho Chehab @ 2019-06-10 0:27 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab,
Linux Kernel Mailing List, Jonathan Corbet, Rafael J. Wysocki,
Viresh Kumar, Linux PM
In-Reply-To: <CAJZ5v0jfObx72ZSKP+rrErkNTHH6Q1L5_gkHq1SRnHiAtYT1Og@mail.gmail.com>
Em Sun, 9 Jun 2019 23:38:32 +0200
"Rafael J. Wysocki" <rafael@kernel.org> escreveu:
> On Sun, Jun 9, 2019 at 4:30 AM Mauro Carvalho Chehab
> <mchehab+samsung@kernel.org> wrote:
> >
> > The conversion is actually:
> > - add blank lines and identation in order to identify paragraphs;
> > - fix tables markups;
> > - add some lists markups;
> > - mark literal blocks;
> > - adjust title markups.
> >
> > At its new index.rst, let's add a :orphan: while this is not linked to
> > the main index.rst file, in order to avoid build warnings.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
>
> I have said "no" to this already twice.
I'm really sorry, I forgot to drop it. It is gone now from:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=convert_rst_renames_v4.1&ofs=50
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH] docs: filesystems: vfs: Render method descriptions
From: Tobin C. Harding @ 2019-06-10 1:11 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Tobin C. Harding, Al Viro, Neil Brown, Randy Dunlap, linux-doc,
linux-fsdevel, linux-kernel
In-Reply-To: <20190606094628.0e8775f7@lwn.net>
On Thu, Jun 06, 2019 at 09:46:28AM -0600, Jonathan Corbet wrote:
> On Tue, 4 Jun 2019 10:26:56 +1000
> "Tobin C. Harding" <tobin@kernel.org> wrote:
>
> > Currently vfs.rst does not render well into HTML the method descriptions
> > for VFS data structures. We can improve the HTML output by putting the
> > description string on a new line following the method name.
> >
> > Suggested-by: Jonathan Corbet <corbet@lwn.net>
> > Signed-off-by: Tobin C. Harding <tobin@kernel.org>
> > ---
> >
> > Jon,
> >
> > As discussed on LKML; this patch applies on top of the series
> >
> > [PATCH v4 0/9] docs: Convert VFS doc to RST
> >
> > If it does not apply cleanly to your branch please feel free to ask me
> > to fix it.
>
> There was one merge conflict, but nothing too serious. I've applied it,
> and things look a lot better - thanks!
Awesome, cheers mate.
Tobin
^ permalink raw reply
* [PATCH V14 1/5] dt-bindings: fsl: scu: add thermal binding
From: Anson.Huang @ 2019-06-10 2:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, corbet, shawnguo, s.hauer, kernel,
festevam, catalin.marinas, will.deacon, rui.zhang, edubezval,
daniel.lezcano, aisheng.dong, ulf.hansson, peng.fan,
mchehab+samsung, linux, daniel.baluta, maxime.ripard, olof, jagan,
horms+renesas, leonard.crestez, bjorn.andersson, dinguyen,
enric.balletbo, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-pm
Cc: Linux-imx
From: Anson Huang <Anson.Huang@nxp.com>
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and thermal sensors etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to get temperature from thermal sensors, this patch adds
binding doc for i.MX system controller thermal driver.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
No change.
---
.../devicetree/bindings/arm/freescale/fsl,scu.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index a575e42..fc3844e 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -155,6 +155,17 @@ Required properties:
Optional properties:
- timeout-sec: contains the watchdog timeout in seconds.
+Thermal bindings based on SCU Message Protocol
+------------------------------------------------------------
+
+Required properties:
+- compatible: Should be :
+ "fsl,imx8qxp-sc-thermal"
+ followed by "fsl,imx-sc-thermal";
+
+- #thermal-sensor-cells: See Documentation/devicetree/bindings/thermal/thermal.txt
+ for a description.
+
Example (imx8qxp):
-------------
aliases {
@@ -222,6 +233,11 @@ firmware {
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
};
+
+ tsens: thermal-sensor {
+ compatible = "fsl,imx8qxp-sc-thermal", "fsl,imx-sc-thermal";
+ #thermal-sensor-cells = <1>;
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH V14 4/5] defconfig: arm64: add i.MX system controller thermal support
From: Anson.Huang @ 2019-06-10 2:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, corbet, shawnguo, s.hauer, kernel,
festevam, catalin.marinas, will.deacon, rui.zhang, edubezval,
daniel.lezcano, aisheng.dong, ulf.hansson, peng.fan,
mchehab+samsung, linux, daniel.baluta, maxime.ripard, olof, jagan,
horms+renesas, leonard.crestez, bjorn.andersson, dinguyen,
enric.balletbo, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-pm
Cc: Linux-imx
In-Reply-To: <20190610025254.23940-1-Anson.Huang@nxp.com>
From: Anson Huang <Anson.Huang@nxp.com>
This patch enables CONFIG_IMX_SC_THERMAL as module.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
No change.
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b3d6eb8..323e772 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -414,6 +414,7 @@ CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
CONFIG_CPU_THERMAL=y
CONFIG_THERMAL_EMULATION=y
CONFIG_QORIQ_THERMAL=m
+CONFIG_IMX_SC_THERMAL=m
CONFIG_ROCKCHIP_THERMAL=m
CONFIG_RCAR_THERMAL=y
CONFIG_RCAR_GEN3_THERMAL=y
--
2.7.4
^ permalink raw reply related
* [PATCH V14 5/5] arm64: dts: imx: add i.MX8QXP thermal support
From: Anson.Huang @ 2019-06-10 2:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, corbet, shawnguo, s.hauer, kernel,
festevam, catalin.marinas, will.deacon, rui.zhang, edubezval,
daniel.lezcano, aisheng.dong, ulf.hansson, peng.fan,
mchehab+samsung, linux, daniel.baluta, maxime.ripard, olof, jagan,
horms+renesas, leonard.crestez, bjorn.andersson, dinguyen,
enric.balletbo, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-pm
Cc: Linux-imx
In-Reply-To: <20190610025254.23940-1-Anson.Huang@nxp.com>
From: Anson Huang <Anson.Huang@nxp.com>
Add i.MX8QXP CPU thermal zone support.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
No change.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 37 ++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index b2cb818..12044be 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -10,6 +10,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/pinctrl/pads-imx8qxp.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
interrupt-parent = <&gic>;
@@ -168,6 +169,11 @@
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
};
+
+ tsens: thermal-sensor {
+ compatible = "fsl,imx8qxp-sc-thermal", "fsl,imx-sc-thermal";
+ #thermal-sensor-cells = <1>;
+ };
};
timer {
@@ -536,4 +542,35 @@
power-domains = <&pd IMX_SC_R_GPIO_7>;
};
};
+
+ thermal_zones: thermal-zones {
+ cpu-thermal0 {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = <&tsens IMX_SC_R_SYSTEM>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ cpu_crit0: trip1 {
+ temperature = <127000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ cooling-device =
+ <&A35_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A35_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A35_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A35_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+
+ };
+ };
+ };
+ };
};
--
2.7.4
^ permalink raw reply related
* [PATCH V14 3/5] thermal: imx_sc: add i.MX system controller thermal support
From: Anson.Huang @ 2019-06-10 2:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, corbet, shawnguo, s.hauer, kernel,
festevam, catalin.marinas, will.deacon, rui.zhang, edubezval,
daniel.lezcano, aisheng.dong, ulf.hansson, peng.fan,
mchehab+samsung, linux, daniel.baluta, maxime.ripard, olof, jagan,
horms+renesas, leonard.crestez, bjorn.andersson, dinguyen,
enric.balletbo, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-pm
Cc: Linux-imx
In-Reply-To: <20190610025254.23940-1-Anson.Huang@nxp.com>
From: Anson Huang <Anson.Huang@nxp.com>
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and thermal sensors etc..
This patch adds i.MX system controller thermal driver support,
Linux kernel has to communicate with system controller via MU
(message unit) IPC to get each thermal sensor's temperature,
it supports multiple sensors which are passed from device tree,
please see the binding doc for details.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
No change.
---
drivers/thermal/Kconfig | 11 +++
drivers/thermal/Makefile | 1 +
drivers/thermal/imx_sc_thermal.c | 142 +++++++++++++++++++++++++++++++++++++++
3 files changed, 154 insertions(+)
create mode 100644 drivers/thermal/imx_sc_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 9966364..454cbe5 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -233,6 +233,17 @@ config IMX_THERMAL
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
+config IMX_SC_THERMAL
+ tristate "Temperature sensor driver for NXP i.MX SoCs with System Controller"
+ depends on ARCH_MXC && IMX_SCU
+ depends on OF
+ help
+ Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
+ system controller inside, Linux kernel has to communicate with system
+ controller via MU (message unit) IPC to get temperature from thermal
+ sensor. It supports one critical trip point and one
+ passive trip point for each thermal sensor.
+
config MAX77620_THERMAL
tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
depends on MFD_MAX77620
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 74a37c7..717a1ba 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
obj-$(CONFIG_TANGO_THERMAL) += tango_thermal.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
+obj-$(CONFIG_IMX_SC_THERMAL) += imx_sc_thermal.o
obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
obj-$(CONFIG_QORIQ_THERMAL) += qoriq_thermal.o
obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
diff --git a/drivers/thermal/imx_sc_thermal.c b/drivers/thermal/imx_sc_thermal.c
new file mode 100644
index 0000000..d406ecb
--- /dev/null
+++ b/drivers/thermal/imx_sc_thermal.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018-2019 NXP.
+ */
+
+#include <linux/err.h>
+#include <linux/firmware/imx/sci.h>
+#include <linux/firmware/imx/types.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/thermal.h>
+
+#include "thermal_core.h"
+
+#define IMX_SC_MISC_FUNC_GET_TEMP 13
+
+static struct imx_sc_ipc *thermal_ipc_handle;
+
+struct imx_sc_sensor {
+ struct thermal_zone_device *tzd;
+ u32 resource_id;
+};
+
+struct req_get_temp {
+ u16 resource_id;
+ u8 type;
+} __packed;
+
+struct resp_get_temp {
+ u16 celsius;
+ u8 tenths;
+} __packed;
+
+struct imx_sc_msg_misc_get_temp {
+ struct imx_sc_rpc_msg hdr;
+ union {
+ struct req_get_temp req;
+ struct resp_get_temp resp;
+ } data;
+};
+
+static int imx_sc_thermal_get_temp(void *data, int *temp)
+{
+ struct imx_sc_msg_misc_get_temp msg;
+ struct imx_sc_rpc_msg *hdr = &msg.hdr;
+ struct imx_sc_sensor *sensor = data;
+ int ret;
+
+ msg.data.req.resource_id = sensor->resource_id;
+ msg.data.req.type = IMX_SC_C_TEMP;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
+ hdr->size = 2;
+
+ ret = imx_scu_call_rpc(thermal_ipc_handle, &msg, true);
+ if (ret) {
+ dev_err(&sensor->tzd->device, "read temp sensor %d failed, ret %d\n",
+ sensor->resource_id, ret);
+ return ret;
+ }
+
+ *temp = msg.data.resp.celsius * 1000 + msg.data.resp.tenths * 100;
+
+ return 0;
+}
+
+static const struct thermal_zone_of_device_ops imx_sc_thermal_ops = {
+ .get_temp = imx_sc_thermal_get_temp,
+};
+
+static int imx_sc_thermal_probe(struct platform_device *pdev)
+{
+ struct device_node *np, *child, *sensor_np;
+ struct imx_sc_sensor *sensor;
+ int ret;
+
+ ret = imx_scu_get_handle(&thermal_ipc_handle);
+ if (ret)
+ return ret;
+
+ np = of_find_node_by_name(NULL, "thermal-zones");
+ if (!np)
+ return -ENODEV;
+
+ sensor_np = of_node_get(pdev->dev.of_node);
+
+ for_each_available_child_of_node(np, child) {
+ sensor = devm_kzalloc(&pdev->dev, sizeof(*sensor), GFP_KERNEL);
+ if (!sensor) {
+ of_node_put(sensor_np);
+ return -ENOMEM;
+ }
+
+ ret = thermal_zone_of_get_sensor_id(child,
+ sensor_np,
+ &sensor->resource_id);
+ if (ret < 0) {
+ dev_err(&pdev->dev,
+ "failed to get valid sensor resource id: %d\n",
+ ret);
+ break;
+ }
+
+ sensor->tzd = devm_thermal_zone_of_sensor_register(&pdev->dev,
+ sensor->resource_id,
+ sensor,
+ &imx_sc_thermal_ops);
+ if (IS_ERR(sensor->tzd)) {
+ dev_err(&pdev->dev, "failed to register thermal zone\n");
+ ret = PTR_ERR(sensor->tzd);
+ break;
+ }
+ }
+
+ of_node_put(sensor_np);
+
+ return ret;
+}
+
+static const struct of_device_id imx_sc_thermal_table[] = {
+ { .compatible = "fsl,imx-sc-thermal", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, imx_sc_thermal_table);
+
+static struct platform_driver imx_sc_thermal_driver = {
+ .probe = imx_sc_thermal_probe,
+ .driver = {
+ .name = "imx-sc-thermal",
+ .of_match_table = imx_sc_thermal_table,
+ },
+};
+module_platform_driver(imx_sc_thermal_driver);
+
+MODULE_AUTHOR("Anson Huang <Anson.Huang@nxp.com>");
+MODULE_DESCRIPTION("Thermal driver for NXP i.MX SoCs with system controller");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH V14 2/5] thermal: of-thermal: add API for getting sensor ID from DT
From: Anson.Huang @ 2019-06-10 2:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, corbet, shawnguo, s.hauer, kernel,
festevam, catalin.marinas, will.deacon, rui.zhang, edubezval,
daniel.lezcano, aisheng.dong, ulf.hansson, peng.fan,
mchehab+samsung, linux, daniel.baluta, maxime.ripard, olof, jagan,
horms+renesas, leonard.crestez, bjorn.andersson, dinguyen,
enric.balletbo, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-pm
Cc: Linux-imx
In-Reply-To: <20190610025254.23940-1-Anson.Huang@nxp.com>
From: Anson Huang <Anson.Huang@nxp.com>
On some platforms like i.MX8QXP, the thermal driver needs a
real HW sensor ID from DT thermal zone, the HW sensor ID is
used to get temperature from SCU firmware, and the virtual
sensor ID starting from 0 to N is NOT used at all, this patch
adds new API thermal_zone_of_get_sensor_id() to provide the
feature of getting sensor ID from DT thermal zone's node.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V13:
- add new API into the thermal API doc.
---
Documentation/thermal/sysfs-api.txt | 8 +++++
drivers/thermal/of-thermal.c | 66 ++++++++++++++++++++++++++++---------
include/linux/thermal.h | 10 ++++++
3 files changed, 68 insertions(+), 16 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt
index c3fa500..8d7f1b1 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -159,6 +159,14 @@ temperature) and throttle appropriate devices.
for the thermal zone device, which might be useful for platform
drivers for temperature calculations.
+1.1.9 int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
+ struct device_node *sensor_np,
+ u32 *id)
+
+ This interface is used to get the sensor id from thermal sensor's
+ phandle argument, it might be necessary for some platforms which
+ have specific sensor ID rather than virtual ID from 0 - N.
+
1.2 thermal cooling device interface
1.2.1 struct thermal_cooling_device *thermal_cooling_device_register(char *name,
void *devdata, struct thermal_cooling_device_ops *)
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index dc5093b..a53792b 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -449,6 +449,54 @@ thermal_zone_of_add_sensor(struct device_node *zone,
}
/**
+ * thermal_zone_of_get_sensor_id - get sensor ID from a DT thermal zone
+ * @tz_np: a valid thermal zone device node.
+ * @sensor_np: a sensor node of a valid sensor device.
+ * @id: a sensor ID pointer will be passed back.
+ *
+ * This function will get sensor ID from a given thermal zone node, use
+ * "thermal-sensors" as list name, and get sensor ID from first phandle's
+ * argument.
+ *
+ * Return: 0 on success, proper error code otherwise.
+ */
+
+int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
+ struct device_node *sensor_np,
+ u32 *id)
+{
+ struct of_phandle_args sensor_specs;
+ int ret;
+
+ ret = of_parse_phandle_with_args(tz_np,
+ "thermal-sensors",
+ "#thermal-sensor-cells",
+ 0,
+ &sensor_specs);
+ if (ret)
+ return ret;
+
+ if (sensor_specs.np != sensor_np) {
+ of_node_put(sensor_specs.np);
+ return -ENODEV;
+ }
+
+ if (sensor_specs.args_count >= 1) {
+ *id = sensor_specs.args[0];
+ WARN(sensor_specs.args_count > 1,
+ "%pOFn: too many cells in sensor specifier %d\n",
+ sensor_specs.np, sensor_specs.args_count);
+ } else {
+ *id = 0;
+ }
+
+ of_node_put(sensor_specs.np);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(thermal_zone_of_get_sensor_id);
+
+/**
* thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
* @dev: a valid struct device pointer of a sensor device. Must contain
* a valid .of_node, for the sensor node.
@@ -499,36 +547,22 @@ thermal_zone_of_sensor_register(struct device *dev, int sensor_id, void *data,
sensor_np = of_node_get(dev->of_node);
for_each_available_child_of_node(np, child) {
- struct of_phandle_args sensor_specs;
int ret, id;
/* For now, thermal framework supports only 1 sensor per zone */
- ret = of_parse_phandle_with_args(child, "thermal-sensors",
- "#thermal-sensor-cells",
- 0, &sensor_specs);
+ ret = thermal_zone_of_get_sensor_id(child, sensor_np, &id);
if (ret)
continue;
- if (sensor_specs.args_count >= 1) {
- id = sensor_specs.args[0];
- WARN(sensor_specs.args_count > 1,
- "%pOFn: too many cells in sensor specifier %d\n",
- sensor_specs.np, sensor_specs.args_count);
- } else {
- id = 0;
- }
-
- if (sensor_specs.np == sensor_np && id == sensor_id) {
+ if (id == sensor_id) {
tzd = thermal_zone_of_add_sensor(child, sensor_np,
data, ops);
if (!IS_ERR(tzd))
tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED);
- of_node_put(sensor_specs.np);
of_node_put(child);
goto exit;
}
- of_node_put(sensor_specs.np);
}
exit:
of_node_put(sensor_np);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 15a4ca5..5edffe6 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -375,6 +375,9 @@ struct thermal_trip {
/* Function declarations */
#ifdef CONFIG_THERMAL_OF
+int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
+ struct device_node *sensor_np,
+ u32 *id);
struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
const struct thermal_zone_of_device_ops *ops);
@@ -386,6 +389,13 @@ struct thermal_zone_device *devm_thermal_zone_of_sensor_register(
void devm_thermal_zone_of_sensor_unregister(struct device *dev,
struct thermal_zone_device *tz);
#else
+
+static int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
+ struct device_node *sensor_np,
+ u32 *id)
+{
+ return -ENOENT;
+}
static inline struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
const struct thermal_zone_of_device_ops *ops)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 08/20] docs: zh_CN: avoid duplicate citation references
From: Alex Shi @ 2019-06-10 3:52 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet, Harry Wei
In-Reply-To: <3c26852c46db3a56cb5f42765db0cc5c64334986.1559933665.git.mchehab+samsung@kernel.org>
Acked!
Thanks!
Alex
On 2019/6/8 2:54 上午, Mauro Carvalho Chehab wrote:
> Documentation/process/programming-language.rst:44: WARNING: duplicate citation n2049, other instance in Documentation/translations/zh_CN/process/programming-language.rst
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Lee Jones @ 2019-06-10 7:27 UTC (permalink / raw)
To: Randy Dunlap
Cc: Ezequiel Garcia, Greg Kroah-Hartman, Guenter Roeck,
Enric Balletbo i Serra, linux-kernel, Gwendal Grignou,
Guenter Roeck, Benson Leung, kernel, Dmitry Torokhov,
Gustavo Pimentel, Lorenzo Pieralisi, linux-doc, Enno Luebbers,
Guido Kiener, Thomas Gleixner, Kishon Vijay Abraham I,
Jonathan Corbet, Wu Hao, Kate Stewart, Tycho Andersen,
Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <c577a7f8-b4d6-0574-bc0e-993637ced41f@infradead.org>
On Thu, 06 Jun 2019, Randy Dunlap wrote:
> > On Thu, 2019-06-06 at 16:51 +0200, Greg Kroah-Hartman wrote:
> >> Again, don't be noisy, it's not hard, and is how things have been
> >> trending for many years now.
>
> Ack that.
Not to say that this particular print is acceptable, but there are
places where a low-level (dbg/info) print on successful probe is
helpful. Driver initialisation is important!
There's a big difference between drivers 'being noisy', spilling all
sorts of information that may well be useful or interesting to a
driver developer, but has little value to anyone else, and providing a
single print to say that a device has been detected and successfully
initialised/probed.
I recently fell victim to a silent, but fully functional device.
Successful device initialisation should not be silent when debugging
has been set to the highest level IMHO.
And yes, of course turning on debugging for Driver Core works, but is
not practical for all cases and is certainly not the first port of
call when figuring out why initialisation seems to be failing for a
single particular device.
Truly surplus churn should absolutely be removed from the boot log, or
at the very least downgraded, leaving only truly useful information
such as highlighting a newly detected device for example. If the user
wants an even more silent boot log, they should turn the log level
down a notch. That is why we have log levels after all. Simply
removing all useful prints regardless of log-level is not the way to
go IMHO.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [RESEND PATCH] Documentation/stackprotector: powerpc supports stack protector
From: Bhupesh Sharma @ 2019-06-10 10:03 UTC (permalink / raw)
To: linuxppc-dev
Cc: arnd, bhsharma, bhupesh.linux, mpe, benh, paulus, linux-kernel,
Jonathan Corbet, linux-doc
powerpc architecture (both 64-bit and 32-bit) supports stack protector
mechanism since some time now [see commit 06ec27aea9fc ("powerpc/64:
add stack protector support")].
Update stackprotector arch support documentation to reflect the same.
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
---
Resend, this time Cc'ing Jonathan and doc-list.
Documentation/features/debug/stackprotector/arch-support.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/features/debug/stackprotector/arch-support.txt b/Documentation/features/debug/stackprotector/arch-support.txt
index 9999ea521f3e..32bbdfc64c32 100644
--- a/Documentation/features/debug/stackprotector/arch-support.txt
+++ b/Documentation/features/debug/stackprotector/arch-support.txt
@@ -22,7 +22,7 @@
| nios2: | TODO |
| openrisc: | TODO |
| parisc: | TODO |
- | powerpc: | TODO |
+ | powerpc: | ok |
| riscv: | TODO |
| s390: | TODO |
| sh: | ok |
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Yu-cheng Yu @ 2019-06-10 15:22 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Dave Hansen, Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner,
Ingo Molnar, linux-kernel, linux-doc, linux-mm, linux-arch,
linux-api, Arnd Bergmann, Balbir Singh, Borislav Petkov,
Cyrill Gorcunov, Dave Hansen, Eugene Syromiatnikov,
Florian Weimer, H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook,
Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Randy Dunlap, Ravi V. Shankar, Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <25281DB3-FCE4-40C2-BADB-B3B05C5F8DD3@amacapital.net>
On Fri, 2019-06-07 at 13:43 -0700, Andy Lutomirski wrote:
> > On Jun 7, 2019, at 12:49 PM, Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
> >
> > On Fri, 2019-06-07 at 11:29 -0700, Andy Lutomirski wrote:
> > > > On Jun 7, 2019, at 10:59 AM, Dave Hansen <dave.hansen@intel.com> wrote:
> > > >
> > > > > On 6/7/19 10:43 AM, Peter Zijlstra wrote:
> > > > > I've no idea what the kernel should do; since you failed to answer the
> > > > > question what happens when you point this to garbage.
> > > > >
> > > > > Does it then fault or what?
> > > >
> > > > Yeah, I think you'll fault with a rather mysterious CR2 value since
> > > > you'll go look at the instruction that faulted and not see any
> > > > references to the CR2 value.
> > > >
> > > > I think this new MSR probably needs to get included in oops output when
> > > > CET is enabled.
> > >
> > > This shouldn’t be able to OOPS because it only happens at CPL 3,
> > > right? We
> > > should put it into core dumps, though.
> > >
> > > >
> > > > Why don't we require that a VMA be in place for the entire bitmap?
> > > > Don't we need a "get" prctl function too in case something like a JIT is
> > > > running and needs to find the location of this bitmap to set bits
> > > > itself?
> > > >
> > > > Or, do we just go whole-hog and have the kernel manage the bitmap
> > > > itself. Our interface here could be:
> > > >
> > > > prctl(PR_MARK_CODE_AS_LEGACY, start, size);
> > > >
> > > > and then have the kernel allocate and set the bitmap for those code
> > > > locations.
> > >
> > > Given that the format depends on the VA size, this might be a good
> > > idea. I
> > > bet we can reuse the special mapping infrastructure for this — the VMA
> > > could
> > > be a MAP_PRIVATE special mapping named [cet_legacy_bitmap] or similar, and
> > > we
> > > can even make special rules to core dump it intelligently if needed. And
> > > we
> > > can make mremap() on it work correctly if anyone (CRIU?) cares.
> > >
> > > Hmm. Can we be creative and skip populating it with zeros? The CPU
> > > should
> > > only ever touch a page if we miss an ENDBR on it, so, in normal operation,
> > > we
> > > don’t need anything to be there. We could try to prevent anyone from
> > > *reading* it outside of ENDBR tracking if we want to avoid people
> > > accidentally
> > > wasting lots of memory by forcing it to be fully populated when the read
> > > it.
> > >
> > > The one downside is this forces it to be per-mm, but that seems like a
> > > generally reasonable model anyway.
> > >
> > > This also gives us an excellent opportunity to make it read-only as seen
> > > from
> > > userspace to prevent exploits from just poking it full of ones before
> > > redirecting execution.
> >
> > GLIBC sets bits only for legacy code, and then makes the bitmap read-
> > only. That
> > avoids most issues:
>
> How does glibc know the linear address space size? We don’t want LA64 to
> break old binaries because the address calculation changed.
When an application starts, its highest stack address is determined.
It uses that as the maximum the bitmap needs to cover.
Yu-cheng
^ permalink raw reply
* Re: [PATCH v3 00/33] Convert files to ReST - part 1
From: Heiko Carstens @ 2019-06-10 15:55 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, linux-kernel, Jonathan Corbet,
Palmer Dabbelt, Albert Ou, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Greentime Hu,
Vincent Chen, linux-riscv, netdev, bpf
In-Reply-To: <20190609092940.5e34e3b0@recife.lan>
On Sun, Jun 09, 2019 at 09:29:40AM -0300, Mauro Carvalho Chehab wrote:
> Em Sun, 9 Jun 2019 11:16:43 +0200
> > Will there be a web page (e.g. kernel.org), which contains always the
> > latest upstream version?
>
> Yes:
>
> https://www.kernel.org/doc/html/latest/
>
> I guess this one is based on Linus tree.
>
> Jon also maintains a version at:
>
> https://static.lwn.net/kerneldoc/
>
> I guess that one is based on docs-next branch from the Docs tree.
>
> Btw, if you want to build it for yourself, you could use:
>
> make htmldocs
Thanks a lot!
> > I can pick these up for s390. Or do you want to send the whole series
> > in one go upstream?
>
> Yeah, feel free to pick them via the s390 tree.
Ok, applied! :)
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Yu-cheng Yu @ 2019-06-10 15:47 UTC (permalink / raw)
To: Pavel Machek, Dave Hansen
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Andy Lutomirski, Balbir Singh, Borislav Petkov,
Cyrill Gorcunov, Dave Hansen, Eugene Syromiatnikov,
Florian Weimer, H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook,
Mike Kravetz, Nadav Amit, Oleg Nesterov, Randy Dunlap,
Ravi V. Shankar, Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <20190608205218.GA2359@xo-6d-61-c0.localdomain>
On Sat, 2019-06-08 at 22:52 +0200, Pavel Machek wrote:
> Hi!
>
> > > I've no idea what the kernel should do; since you failed to answer the
> > > question what happens when you point this to garbage.
> > >
> > > Does it then fault or what?
> >
> > Yeah, I think you'll fault with a rather mysterious CR2 value since
> > you'll go look at the instruction that faulted and not see any
> > references to the CR2 value.
> >
> > I think this new MSR probably needs to get included in oops output when
> > CET is enabled.
> >
> > Why don't we require that a VMA be in place for the entire bitmap?
> > Don't we need a "get" prctl function too in case something like a JIT is
> > running and needs to find the location of this bitmap to set bits itself?
> >
> > Or, do we just go whole-hog and have the kernel manage the bitmap
> > itself. Our interface here could be:
> >
> > prctl(PR_MARK_CODE_AS_LEGACY, start, size);
> >
> > and then have the kernel allocate and set the bitmap for those code
> > locations.
>
> For the record, that sounds like a better interface than userspace knowing
> about the bitmap formats...
> Pavel
Initially we implemented the bitmap that way. To manage the bitmap, every time
the application issues a syscall for a .so it loads, and the kernel does
copy_from_user() & copy_to_user() (or similar things). If a system has a few
legacy .so files and every application does the same, it can take a long time to
boot up.
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Yu-cheng Yu @ 2019-06-10 16:03 UTC (permalink / raw)
To: Andy Lutomirski, Dave Hansen
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <4F7D0C3C-F239-4B67-BB05-31350F809293@amacapital.net>
On Fri, 2019-06-07 at 15:27 -0700, Andy Lutomirski wrote:
> > On Jun 7, 2019, at 2:09 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> >
> > On 6/7/19 1:06 PM, Yu-cheng Yu wrote:
> > > > Huh, how does glibc know about all possible past and future legacy code
> > > > in the application?
> > >
> > > When dlopen() gets a legacy binary and the policy allows that, it will
> > > manage
> > > the bitmap:
> > >
> > > If a bitmap has not been created, create one.
> > > Set bits for the legacy code being loaded.
> >
> > I was thinking about code that doesn't go through GLIBC like JITs.
>
> CRIU is another consideration: it would be rather annoying if CET programs
> can’t migrate between LA57 and normal machines.
When a machine migrates, does its applications' addresses change?
If no, then the bitmap should still work, right?
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Yu-cheng Yu @ 2019-06-10 16:05 UTC (permalink / raw)
To: Dave Hansen, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <f6de9073-9939-a20d-2196-25fa223cf3fc@intel.com>
On Fri, 2019-06-07 at 14:09 -0700, Dave Hansen wrote:
> On 6/7/19 1:06 PM, Yu-cheng Yu wrote:
> > > Huh, how does glibc know about all possible past and future legacy code
> > > in the application?
> >
> > When dlopen() gets a legacy binary and the policy allows that, it will
> > manage
> > the bitmap:
> >
> > If a bitmap has not been created, create one.
> > Set bits for the legacy code being loaded.
>
> I was thinking about code that doesn't go through GLIBC like JITs.
If JIT manages the bitmap, it knows where it is.
It can always read the bitmap again, right?
Yu-cheng
^ permalink raw reply
* Re: [PATCH v3 09/33] docs: fault-injection: convert docs to ReST and rename to *.rst
From: Federico Vaga @ 2019-06-10 16:24 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Akinobu Mita, Harry Wei, Alex Shi, Kees Cook,
Arnd Bergmann, Greg Kroah-Hartman
In-Reply-To: <5bbdd14f23a8fa66164ac38d84662091b90adddc.1560045490.git.mchehab+samsung@kernel.org>
In data Sunday, June 9, 2019 4:26:59 AM CEST, Mauro Carvalho Chehab ha
scritto:
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> ...ault-injection.txt => fault-injection.rst} | 265 +++++++++---------
> Documentation/fault-injection/index.rst | 20 ++
> ...r-inject.txt => notifier-error-inject.rst} | 18 +-
> ...injection.txt => nvme-fault-injection.rst} | 174 ++++++------
> ...rovoke-crashes.txt => provoke-crashes.rst} | 40 ++-
> Documentation/process/4.Coding.rst | 2 +-
> .../translations/it_IT/process/4.Coding.rst | 2 +-
Limited to translations/it_IT
Acked-by: Federico Vaga <federico.vaga@vaga.pv.it>
> .../translations/zh_CN/process/4.Coding.rst | 2 +-
> drivers/misc/lkdtm/core.c | 2 +-
> include/linux/fault-inject.h | 2 +-
> lib/Kconfig.debug | 2 +-
> tools/testing/fault-injection/failcmd.sh | 2 +-
> 12 files changed, 290 insertions(+), 241 deletions(-)
> rename Documentation/fault-injection/{fault-injection.txt =>
> fault-injection.rst} (68%) create mode 100644
> Documentation/fault-injection/index.rst
> rename Documentation/fault-injection/{notifier-error-inject.txt =>
> notifier-error-inject.rst} (83%) rename
> Documentation/fault-injection/{nvme-fault-injection.txt =>
> nvme-fault-injection.rst} (19%) rename
> Documentation/fault-injection/{provoke-crashes.txt => provoke-crashes.rst}
> (45%)
>
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Yu-cheng Yu @ 2019-06-10 16:29 UTC (permalink / raw)
To: Dave Martin
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Peter Zijlstra, Randy Dunlap,
Ravi V. Shankar, Vedvyas Shanbhogue
In-Reply-To: <20190607180115.GJ28398@e103592.cambridge.arm.com>
On Fri, 2019-06-07 at 19:01 +0100, Dave Martin wrote:
> On Thu, Jun 06, 2019 at 01:06:41PM -0700, Yu-cheng Yu wrote:
> > An ELF file's .note.gnu.property indicates features the executable file
> > can support. For example, the property GNU_PROPERTY_X86_FEATURE_1_AND
> > indicates the file supports GNU_PROPERTY_X86_FEATURE_1_IBT and/or
> > GNU_PROPERTY_X86_FEATURE_1_SHSTK.
> >
> > With this patch, if an arch needs to setup features from ELF properties,
> > it needs CONFIG_ARCH_USE_GNU_PROPERTY to be set, and a specific
> > arch_setup_property().
> >
> > For example, for X86_64:
> >
> > int arch_setup_property(void *ehdr, void *phdr, struct file *f, bool inter)
> > {
> > int r;
> > uint32_t property;
> >
> > r = get_gnu_property(ehdr, phdr, f, GNU_PROPERTY_X86_FEATURE_1_AND,
> > &property);
> > ...
> > }
>
> Although this code works for the simple case, I have some concerns about
> some aspects of the implementation here. There appear to be some bounds
> checking / buffer overrun issues, and the code seems quite complex.
>
> Maybe this patch tries too hard to be compatible with toolchains that do
> silly things such as embedding huge notes in an executable, or mixing
> NT_GNU_PROPERTY_TYPE_0 in a single PT_NOTE with a load of junk not
> relevant to the loader. I wonder whether Linux can dictate what
> interpretation(s) of the ELF specs it is prepared to support, rather than
> trying to support absolutely anything.
To me, looking at PT_GNU_PROPERTY and not trying to support anything is a
logical choice. And it breaks only a limited set of toolchains.
I will simplify the parser and leave this patch as-is for anyone who wants to
back-port. Are there any objections or concerns?
Yu-cheng
^ permalink raw reply
* Re: [PATCH v7 22/27] binfmt_elf: Extract .note.gnu.property from an ELF file
From: Dave Martin @ 2019-06-10 16:57 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Peter Zijlstra, Randy Dunlap,
Ravi V. Shankar, Vedvyas Shanbhogue
In-Reply-To: <94b9c55b3b874825fda485af40ab2a6bc3dad171.camel@intel.com>
On Mon, Jun 10, 2019 at 09:29:04AM -0700, Yu-cheng Yu wrote:
> On Fri, 2019-06-07 at 19:01 +0100, Dave Martin wrote:
> > On Thu, Jun 06, 2019 at 01:06:41PM -0700, Yu-cheng Yu wrote:
> > > An ELF file's .note.gnu.property indicates features the executable file
> > > can support. For example, the property GNU_PROPERTY_X86_FEATURE_1_AND
> > > indicates the file supports GNU_PROPERTY_X86_FEATURE_1_IBT and/or
> > > GNU_PROPERTY_X86_FEATURE_1_SHSTK.
> > >
> > > With this patch, if an arch needs to setup features from ELF properties,
> > > it needs CONFIG_ARCH_USE_GNU_PROPERTY to be set, and a specific
> > > arch_setup_property().
> > >
> > > For example, for X86_64:
> > >
> > > int arch_setup_property(void *ehdr, void *phdr, struct file *f, bool inter)
> > > {
> > > int r;
> > > uint32_t property;
> > >
> > > r = get_gnu_property(ehdr, phdr, f, GNU_PROPERTY_X86_FEATURE_1_AND,
> > > &property);
> > > ...
> > > }
> >
> > Although this code works for the simple case, I have some concerns about
> > some aspects of the implementation here. There appear to be some bounds
> > checking / buffer overrun issues, and the code seems quite complex.
> >
> > Maybe this patch tries too hard to be compatible with toolchains that do
> > silly things such as embedding huge notes in an executable, or mixing
> > NT_GNU_PROPERTY_TYPE_0 in a single PT_NOTE with a load of junk not
> > relevant to the loader. I wonder whether Linux can dictate what
> > interpretation(s) of the ELF specs it is prepared to support, rather than
> > trying to support absolutely anything.
>
> To me, looking at PT_GNU_PROPERTY and not trying to support anything is a
> logical choice. And it breaks only a limited set of toolchains.
>
> I will simplify the parser and leave this patch as-is for anyone who wants to
> back-port. Are there any objections or concerns?
No objection from me ;) But I'm biased.
Hopefully this change should allow substantial simplification. For one
thing, PT_GNU_PROPERTY tells its file offset and size directly in its
phdrs entry. That should save us a lot of effort on the kernel side.
Cheers
---Dave
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox