* [PATCH 6/8] docs/gpu: fix a documentation build break in i915.rst
From: Jonathan Corbet @ 2019-05-22 20:50 UTC (permalink / raw)
To: linux-doc
Cc: linux-kernel, Jani Nikula, Markus Heiser, Mauro Carvalho Chehab,
Oleksandr Natalenko, Jonathan Corbet
In-Reply-To: <20190522205034.25724-1-corbet@lwn.net>
Documentation/gpu/i915.rst is not included in the TOC tree, but newer
versions of sphinx parse it anyway. That leads to this hard build failure:
> Global GTT Fence Handling
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> reST markup error:
> /stuff/k/git/kernel/Documentation/gpu/i915.rst:403: (SEVERE/4) Title level inconsistent:
Make the underlining consistent and restore a working docs build.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/gpu/i915.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 055df45596c1..cf9ff64753cc 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -401,13 +401,13 @@ GTT Fences and Swizzling
:internal:
Global GTT Fence Handling
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_fence_reg.c
:doc: fence register handling
Hardware Tiling and Swizzling Details
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_fence_reg.c
:doc: tiling swizzling details
--
2.21.0
^ permalink raw reply related
* [PATCH 0/8] docs: Fixes for recent versions of Sphinx
From: Jonathan Corbet @ 2019-05-22 20:50 UTC (permalink / raw)
To: linux-doc
Cc: linux-kernel, Jani Nikula, Markus Heiser, Mauro Carvalho Chehab,
Oleksandr Natalenko, Jonathan Corbet
The Sphinx folks deprecated some interfaces in the 2.0 release; one
immediate result of that is a bunch of warnings that show up when building
with 1.8. These two patches make those warnings go away, but at a cost:
- It introduces a couple of Sphinx version checks, which are always
ugly, but the alternative would be to stop supporting versions
before 1.7. For now, I think we can carry that cruft.
- The second patch causes the build to fail horribly on newer
Sphinx installations. The change to switch_source_input() seems
to make the parser much more finicky, increasing warnings and
eventually failing the build altogether. In particular, it will
scream about problems in .rst files that are not included in the
TOC tree at all.
This version of the patch set fixes up the worst problems (the i915 error
in particular, which breaks the build hard). I've tested it with versions
1.4, 1.8, and 2.0.
Given that these problems are already breaking builds on some systems, I
think I may try to sell these changes to Linus for 5.2 still.
Changes since v1:
- Fix up a couple of logging changes I somehow missed
- Don't save state when using switch_source_input()
- Fix a few build errors
- Add Mauro's sphinx-pre-install improvements
Jonathan Corbet (7):
doc: Cope with Sphinx logging deprecations
doc: Cope with the deprecation of AutoReporter
docs: fix numaperf.rst and add it to the doc tree
lib/list_sort: fix kerneldoc build error
docs: fix multiple doc build warnings in enumeration.rst
docs/gpu: fix a documentation build break in i915.rst
docs: Fix conf.py for Sphinx 2.0
Mauro Carvalho Chehab (1):
scripts/sphinx-pre-install: make it handle Sphinx versions
Documentation/admin-guide/mm/index.rst | 1 +
Documentation/admin-guide/mm/numaperf.rst | 2 +-
Documentation/conf.py | 2 +-
.../firmware-guide/acpi/enumeration.rst | 2 +-
Documentation/gpu/i915.rst | 4 +-
Documentation/sphinx/kerneldoc.py | 44 +++++++---
Documentation/sphinx/kernellog.py | 28 +++++++
Documentation/sphinx/kfigure.py | 40 +++++----
lib/list_sort.c | 3 +-
scripts/sphinx-pre-install | 81 +++++++++++++++++--
10 files changed, 166 insertions(+), 41 deletions(-)
create mode 100644 Documentation/sphinx/kernellog.py
--
2.21.0
^ permalink raw reply
* Re: [PATCH] scripts/sphinx-pre-install: make it handle Sphinx versions
From: Jonathan Corbet @ 2019-05-22 20:35 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Markus Heiser, Jani Nikula, linux-doc, linux-kernel
In-Reply-To: <a741574b7081c162d200bdead35302ccac6fd116.1558545958.git.mchehab+samsung@kernel.org>
On Wed, 22 May 2019 13:28:34 -0400
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> As we want to switch to a newer Sphinx version in the future,
> add some version detected logic, checking if the current
> version meets the requirement and suggesting upgrade it the
> version is supported but too old.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
I've applied this in the branch with my other fixes (coming soon to a
mailing list near you), thanks. I do think we eventually want to emit a
warning during a normal docs build as well, and to raise the recommended
version, but one step at a time...
jon
^ permalink raw reply
* Re: [PATCH 00/10] Fix broken documentation references at v5.2-rc1
From: Federico Vaga @ 2019-05-22 20:18 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <20190521212600.39bc341c@coco.lan>
On Wednesday, May 22, 2019 2:26:00 AM CEST Mauro Carvalho Chehab wrote:
> Hi Frederico,
>
> Em Wed, 22 May 2019 00:54:48 +0200
>
> Federico Vaga <federico.vaga@vaga.pv.it> escreveu:
> > On Monday, May 20, 2019 4:47:29 PM CEST Mauro Carvalho Chehab wrote:
> > > There are several broken Documentation/* references within the Kernel
> > > tree. There are some reasons for several of them:
> > >
> > > 1. The acpi and x86 documentation files were renamed, but the
> > >
> > > references weren't updated;
> > >
> > > 2. The DT files have been converted to JSON format, causing them
> > >
> > > to be renamed;
> > >
> > > 3. Translated files point to future translation work still pending merge
> > >
> > > or require some action from someone that it is fluent at the
> > > translated language;
> >
> > Hi Mauro
>
> My main goal with this patchset is to get as close as possible to zero
> warnings, as this helps me on rebasing a documentation patch series
> I wrote with renames hundreds of file from .txt to .rst.
>
> In the case of (3), the scripts/documentation-file-ref-check was unable to
> find some files pointed by Italian and Chinese translations. So, after
> this series, it will keep pointing for broken links there.
>
> > I am not sure to get what you mean in terms of actions but I think you are
> > referring to the "empty" files I added in the Italian translations. I
> > added
> > those files to avoid broken links; the alternative would have been to not
> > write those links or to point directly to the main document, but in both
> > cases it easy to forget to update them later.
> > I chose to have links to "empty" files so that the document does
> > not need to be updated later.
> >
> > If you are not referring to those files than I am not understanding, can
> > you point to a clear example?
>
> What I meant is that I can barely read Italian and have no glue on
> Chinese. So, I can't really address those properly :-)
> So, basically, it should be up to someone else fluent on such
> languages to address those.
>
> Btw, I understand why you pointed to some non-existing files:
> translating the Kernel's documents takes a lot of time[1].
More than non-existing the file *should* be there, only that it says the
translation is pending. So the tool should find the file without complaining.
I did not pay enough attention; I was not aware about the existence of that
tool. Now that I filled my ignorance with a bit of knowledge I will use to fix
those documents. Thank you
>
> [1] If I was doing a translation, I would probably have opted to keep
> pointing to the English doc and have a script to point me links to
> non-translated docs, but your way also works. The only drawback is that
> the script will keep pinpointing to translations with broken links,
> while the translation is not complete.
>
> Thanks,
> Mauro
^ permalink raw reply
* Re: [PATCH] Fix comments with paths pointing to renamed or moved files.
From: Joe Perches @ 2019-05-22 18:54 UTC (permalink / raw)
To: Pavel Machek, Lukas Prause
Cc: lizefan, tj, hannes, peterz, mingo, will.deacon, rjw, len.brown,
rostedt, linux-doc, linux-kernel, cgroups, linux-pm,
Lennart Glauer
In-Reply-To: <20190522183614.GD10003@amd>
On Wed, 2019-05-22 at 20:36 +0200, Pavel Machek wrote:
> On Tue 2019-05-21 17:54:30, Lukas Prause wrote:
> > This patch corrects renamed or moved paths in comments.
> >
> > Signed-off-by: Lukas Prause <langspielplatte@black-mesa.xyz>
> > Signed-off-by: Lennart Glauer <mail@lennart-glauer.de>
>
> Acked-by: Pavel Machek <pavel@ucw.cz>
>
> > diff --git a/kernel/power/power.h b/kernel/power/power.h
> > index 9e58bdc8a562..5de8b0c7f657 100644
> > --- a/kernel/power/power.h
> > +++ b/kernel/power/power.h
> > @@ -182,7 +182,7 @@ extern int swsusp_unmark(void);
> > #endif
> >
> > struct timeval;
> > -/* kernel/power/swsusp.c */
> > +/* kernel/power/hibernate.c */
> > extern void swsusp_show_speed(ktime_t, ktime_t, unsigned int, char *);
> >
> > #ifdef CONFIG_SUSPEND
I think all of these markings should be removed instead.
Why are these useful?
It seems many of these filenames in power.h aren't correct anyway.
For instance power.h has:
/* kernel/power/hibernate.c */
extern int swsusp_check(void);
extern void swsusp_free(void);
extern int swsusp_read(unsigned int *flags_p);
extern int swsusp_write(unsigned int flags);
extern void swsusp_close(fmode_t);
#ifdef CONFIG_SUSPEND
extern int swsusp_unmark(void);
#endif
but:
swsusp_check is in swap.c
swsusp_free is in snapshot.c
swsusp_read is in swap.c
etc...
Perhaps:
---
kernel/power/power.h | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 9e58bdc8a562..52bcb72564e5 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -16,7 +16,6 @@ struct swsusp_info {
} __aligned(PAGE_SIZE);
#ifdef CONFIG_HIBERNATION
-/* kernel/power/snapshot.c */
extern void __init hibernate_reserved_size_init(void);
extern void __init hibernate_image_size_init(void);
@@ -55,7 +54,6 @@ extern int hibernate_resume_nonboot_cpu_disable(void);
asmlinkage int swsusp_save(void);
-/* kernel/power/hibernate.c */
extern bool freezer_test_done;
extern int hibernation_snapshot(int platform_mode);
@@ -63,7 +61,6 @@ extern int hibernation_restore(int platform_mode);
extern int hibernation_platform_enter(void);
#ifdef CONFIG_STRICT_KERNEL_RWX
-/* kernel/power/snapshot.c */
extern void enable_restore_image_protection(void);
#else
static inline void enable_restore_image_protection(void) {}
@@ -171,7 +168,6 @@ extern int swsusp_swap_in_use(void);
#define SF_NOCOMPRESS_MODE 2
#define SF_CRC32_MODE 4
-/* kernel/power/hibernate.c */
extern int swsusp_check(void);
extern void swsusp_free(void);
extern int swsusp_read(unsigned int *flags_p);
@@ -182,11 +178,9 @@ extern int swsusp_unmark(void);
#endif
struct timeval;
-/* kernel/power/swsusp.c */
extern void swsusp_show_speed(ktime_t, ktime_t, unsigned int, char *);
#ifdef CONFIG_SUSPEND
-/* kernel/power/suspend.c */
extern const char * const pm_labels[];
extern const char *pm_states[];
extern const char *mem_sleep_states[];
@@ -202,7 +196,6 @@ static inline int suspend_devices_and_enter(suspend_state_t state)
#endif /* !CONFIG_SUSPEND */
#ifdef CONFIG_PM_TEST_SUSPEND
-/* kernel/power/suspend_test.c */
extern void suspend_test_start(void);
extern void suspend_test_finish(const char *label);
#else /* !CONFIG_PM_TEST_SUSPEND */
@@ -211,7 +204,6 @@ static inline void suspend_test_finish(const char *label) {}
#endif /* !CONFIG_PM_TEST_SUSPEND */
#ifdef CONFIG_PM_SLEEP
-/* kernel/power/main.c */
extern int __pm_notifier_call_chain(unsigned long val, int nr_to_call,
int *nr_calls);
extern int pm_notifier_call_chain(unsigned long val);
@@ -289,7 +281,6 @@ static inline void suspend_thaw_processes(void)
#ifdef CONFIG_PM_AUTOSLEEP
-/* kernel/power/autosleep.c */
extern int pm_autosleep_init(void);
extern int pm_autosleep_lock(void);
extern void pm_autosleep_unlock(void);
@@ -307,7 +298,6 @@ static inline suspend_state_t pm_autosleep_state(void) { return PM_SUSPEND_ON; }
#ifdef CONFIG_PM_WAKELOCKS
-/* kernel/power/wakelock.c */
extern ssize_t pm_show_wakelocks(char *buf, bool show_active);
extern int pm_wake_lock(const char *buf);
extern int pm_wake_unlock(const char *buf);
^ permalink raw reply related
* Re: [PATCH] Fix comments with paths pointing to renamed or moved files.
From: Pavel Machek @ 2019-05-22 18:36 UTC (permalink / raw)
To: Lukas Prause
Cc: lizefan, tj, hannes, peterz, mingo, will.deacon, rjw, len.brown,
rostedt, linux-doc, linux-kernel, cgroups, linux-pm,
Lennart Glauer
In-Reply-To: <20190521155430.14941-1-langspielplatte@black-mesa.xyz>
[-- Attachment #1: Type: text/plain, Size: 845 bytes --]
On Tue 2019-05-21 17:54:30, Lukas Prause wrote:
> This patch corrects renamed or moved paths in comments.
>
> Signed-off-by: Lukas Prause <langspielplatte@black-mesa.xyz>
> Signed-off-by: Lennart Glauer <mail@lennart-glauer.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 9e58bdc8a562..5de8b0c7f657 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -182,7 +182,7 @@ extern int swsusp_unmark(void);
> #endif
>
> struct timeval;
> -/* kernel/power/swsusp.c */
> +/* kernel/power/hibernate.c */
> extern void swsusp_show_speed(ktime_t, ktime_t, unsigned int, char *);
>
> #ifdef CONFIG_SUSPEND
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH] scripts/sphinx-pre-install: make it handle Sphinx versions
From: Mauro Carvalho Chehab @ 2019-05-22 17:28 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Mauro Carvalho Chehab, Markus Heiser, Jani Nikula, linux-doc,
linux-kernel
As we want to switch to a newer Sphinx version in the future,
add some version detected logic, checking if the current
version meets the requirement and suggesting upgrade it the
version is supported but too old.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
scripts/sphinx-pre-install | 81 ++++++++++++++++++++++++++++++++++----
1 file changed, 74 insertions(+), 7 deletions(-)
diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index f6a5c0bae31e..e667db230d0a 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -13,7 +13,7 @@ use strict;
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
-my $virtenv_dir = "sphinx_1.4";
+my $conf = "Documentation/conf.py";
my $requirement_file = "Documentation/sphinx/requirements.txt";
#
@@ -26,7 +26,9 @@ my $need = 0;
my $optional = 0;
my $need_symlink = 0;
my $need_sphinx = 0;
+my $rec_sphinx_upgrade = 0;
my $install = "";
+my $virtenv_dir = "sphinx_";
#
# Command line arguments
@@ -201,13 +203,15 @@ sub check_missing_tex($)
}
}
-sub check_sphinx()
+sub get_sphinx_fname()
{
- return if findprog("sphinx-build");
+ my $fname = "sphinx-build";
+ return $fname if findprog($fname);
- if (findprog("sphinx-build-3")) {
+ $fname = "sphinx-build-3";
+ if (findprog($fname)) {
$need_symlink = 1;
- return;
+ return $fname;
}
if ($virtualenv) {
@@ -219,6 +223,68 @@ sub check_sphinx()
} else {
add_package("python-sphinx", 0);
}
+
+ return "";
+}
+
+sub check_sphinx()
+{
+ my $min_version;
+ my $rec_version;
+ my $cur_version;
+
+ open IN, $conf or die "Can't open $conf";
+ while (<IN>) {
+ if (m/^\s*needs_sphinx\s*=\s*[\'\"]([\d\.]+)[\'\"]/) {
+ $min_version=$1;
+ last;
+ }
+ }
+ close IN;
+
+ die "Can't get needs_sphinx version from $conf" if (!$min_version);
+
+ open IN, $requirement_file or die "Can't open $requirement_file";
+ while (<IN>) {
+ if (m/^\s*Sphinx\s*==\s*([\d\.]+)$/) {
+ $rec_version=$1;
+ last;
+ }
+ }
+ close IN;
+
+ die "Can't get recommended sphinx version from $requirement_file" if (!$min_version);
+
+ my $sphinx = get_sphinx_fname();
+ return if ($sphinx eq "");
+
+ open IN, "$sphinx --version 2>&1 |" or die "$sphinx returned an error";
+ while (<IN>) {
+ if (m/^\s*sphinx-build\s+([\d\.]+)$/) {
+ $cur_version=$1;
+ last;
+ }
+ }
+ close IN;
+
+ $virtenv_dir .= $rec_version;
+
+ die "$sphinx didn't return its version" if (!$cur_version);
+
+ printf "Sphinx version %s (minimal: %s, recommended >= %s)\n",
+ $cur_version, $min_version, $rec_version;
+
+ if ($cur_version lt $min_version) {
+ print "Warning: Sphinx version should be >= $min_version\n\n";
+ $need_sphinx = 1;
+ return;
+ }
+
+ if ($cur_version lt $rec_version) {
+ print "Warning: It is recommended at least Sphinx version $rec_version.\n";
+ print " To upgrade, use:\n\n";
+ $rec_sphinx_upgrade = 1;
+ }
}
#
@@ -540,7 +606,7 @@ sub check_needs()
printf "\tsudo ln -sf %s /usr/bin/sphinx-build\n\n",
which("sphinx-build-3");
}
- if ($need_sphinx) {
+ if ($need_sphinx || $rec_sphinx_upgrade) {
my $activate = "$virtenv_dir/bin/activate";
if (-e "$ENV{'PWD'}/$activate") {
printf "\nNeed to activate virtualenv with:\n";
@@ -554,7 +620,8 @@ sub check_needs()
printf "\t$virtualenv $virtenv_dir\n";
printf "\t. $activate\n";
printf "\tpip install -r $requirement_file\n";
- $need++;
+
+ $need++ if (!$rec_sphinx_upgrade);
}
}
printf "\n";
--
2.21.0
^ permalink raw reply related
* Re: [PATCH RFC 0/2] docs: Deal with some Sphinx deprecation warnings
From: Mauro Carvalho Chehab @ 2019-05-22 16:40 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Markus Heiser, Jani Nikula, linux-doc, linux-kernel
In-Reply-To: <20190522130408.5d8258de@coco.lan>
Em Wed, 22 May 2019 13:04:08 -0300
Mauro Carvalho Chehab <mchehab@kernel.org> escreveu:
> Em Wed, 22 May 2019 09:45:59 -0600
> Jonathan Corbet <corbet@lwn.net> escreveu:
>
> > On Wed, 22 May 2019 15:25:36 +0200
> > Markus Heiser <markus.heiser@darmarit.de> wrote:
> >
> > > Lets use 1.7 :
> > >
> > > - no need for Use_SSI wrapper
> > > - new log should work with 1.7 [1] --> no need for kernellog.py and
> > > additional imports, instead include on top of python modules ::
> > >
> > > from sphinx.util import logging
> > > logger = logging.getLogger('kerneldoc')
> >
> > I think we're going to have to drag things forward at some point in the
> > not-too-distant future, but I think I'd rather not do that quite yet. The
> > cost of supporting older sphinx for a few releases while we warn people is
> > not all that high. So I think we should:
> >
> > - Put in (a future version of) my hacks for now, plus whatever else might
> > be needed to make 2.0 work right.
> >
> > - Fix the fallout with regard to out-of-toctree .rst files so that we can
> > actually build again with current sphinx.
> >
> > - Update Documentation/sphinx/requirements.txt to ask for something a wee
> > bit more recent than 1.4.9.
>
> You should remember to also update conf.py (with currently points to 1.3):
>
> # If your documentation needs a minimal Sphinx version, state it here.
> needs_sphinx = '1.3'
>
> Also, if you touch there, you should also touch:
>
> ./scripts/sphinx-pre-install
>
> The change there won't be as trivial as just changing this line:
>
> $virtenv_dir = "sphinx_1.4";
>
> as the script should now run sphinx-build --version, in order to check
> if the version is lower than the new minimal version. It probably makes
> sense to make it grep the version from needs_sphinx at conf.py.
>
> > - Add a warning when building with an older version that (say) 1.7 will
> > be required as of (say) 5.5.
>
> It probably makes sense to add such check at the pre-install script,
> and add a:
>
> SPHINXOPTS="-jauto"
>
> somewhere if version is 1.7 or upper.
>
I'm meaning something like the enclosed patch.
(PS.: I'm still working at the patch)
Thanks,
Mauro
[RFC PATCH] scripts/sphinx-pre-install: make it handle Sphinx versions
As we want to switch to a newer Sphinx version in the future,
add some version detected logic.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index f6a5c0bae31e..8835aede4c61 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -13,7 +13,7 @@ use strict;
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
-my $virtenv_dir = "sphinx_1.4";
+my $conf = "Documentation/conf.py";
my $requirement_file = "Documentation/sphinx/requirements.txt";
#
@@ -27,6 +27,10 @@ my $optional = 0;
my $need_symlink = 0;
my $need_sphinx = 0;
my $install = "";
+my $min_version;
+my $rec_version;
+my $cur_version;
+my $virtenv_dir = "sphinx_";
#
# Command line arguments
@@ -76,6 +80,52 @@ my %texlive = (
# Subroutines that checks if a feature exists
#
+sub handle_sphinx_version()
+{
+ open IN, $conf;
+ while (<IN>) {
+ if (m/^\s*needs_sphinx\s*=\s*[\'\"]([\d\.]+)[\'\"]/) {
+ $min_version=$1;
+ last;
+ }
+ }
+ close IN;
+
+ die "Can't get needs_sphinx version from $conf" if (!$min_version);
+
+ open IN, $requirement_file;
+ while (<IN>) {
+ if (m/^\s*Sphinx\s*==\s*([\d\.]+)$/) {
+ $rec_version=$1;
+ last;
+ }
+ }
+ close IN;
+
+ open IN, "sphinx-build --version 2>&1 |";
+ while (<IN>) {
+ if (m/^\s*sphinx-build\s+([\d\.]+)$/) {
+ $cur_version=$1;
+ last;
+ }
+ }
+ close IN;
+
+ $virtenv_dir .= $rec_version;
+
+ # Sphinx is not installed
+ return if (!$cur_version);
+
+ if ($cur_version lt $min_version) {
+ print "Sphinx version older than $min_version! We recommend at least $rec_version";
+ exit -1;
+ }
+
+ if ($cur_version lt $rec_version) {
+ print "Warning: we recommend at least Sphinx version $rec_version";
+ }
+}
+
sub check_missing(%)
{
my %map = %{$_[0]};
@@ -587,6 +637,8 @@ while (@ARGV) {
}
}
+handle_sphinx_version();
+
#
# Determine the system type. There's no standard unique way that would
# work with all distros with a minimal package install. So, several
^ permalink raw reply related
* Re: [PATCH RFC 0/2] docs: Deal with some Sphinx deprecation warnings
From: Mauro Carvalho Chehab @ 2019-05-22 16:04 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Markus Heiser, Jani Nikula, linux-doc, linux-kernel
In-Reply-To: <20190522094559.5ed8021e@lwn.net>
Em Wed, 22 May 2019 09:45:59 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Wed, 22 May 2019 15:25:36 +0200
> Markus Heiser <markus.heiser@darmarit.de> wrote:
>
> > Lets use 1.7 :
> >
> > - no need for Use_SSI wrapper
> > - new log should work with 1.7 [1] --> no need for kernellog.py and
> > additional imports, instead include on top of python modules ::
> >
> > from sphinx.util import logging
> > logger = logging.getLogger('kerneldoc')
>
> I think we're going to have to drag things forward at some point in the
> not-too-distant future, but I think I'd rather not do that quite yet. The
> cost of supporting older sphinx for a few releases while we warn people is
> not all that high. So I think we should:
>
> - Put in (a future version of) my hacks for now, plus whatever else might
> be needed to make 2.0 work right.
>
> - Fix the fallout with regard to out-of-toctree .rst files so that we can
> actually build again with current sphinx.
>
> - Update Documentation/sphinx/requirements.txt to ask for something a wee
> bit more recent than 1.4.9.
You should remember to also update conf.py (with currently points to 1.3):
# If your documentation needs a minimal Sphinx version, state it here.
needs_sphinx = '1.3'
Also, if you touch there, you should also touch:
./scripts/sphinx-pre-install
The change there won't be as trivial as just changing this line:
$virtenv_dir = "sphinx_1.4";
as the script should now run sphinx-build --version, in order to check
if the version is lower than the new minimal version. It probably makes
sense to make it grep the version from needs_sphinx at conf.py.
> - Add a warning when building with an older version that (say) 1.7 will
> be required as of (say) 5.5.
It probably makes sense to add such check at the pre-install script,
and add a:
SPHINXOPTS="-jauto"
somewhere if version is 1.7 or upper.
>
> Does this make sense?
It makes sense to me.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH RFC 0/2] docs: Deal with some Sphinx deprecation warnings
From: Jonathan Corbet @ 2019-05-22 15:45 UTC (permalink / raw)
To: Markus Heiser; +Cc: Mauro Carvalho Chehab, Jani Nikula, linux-doc, linux-kernel
In-Reply-To: <39b12927-9bf9-a304-4108-8f471a204f89@darmarit.de>
On Wed, 22 May 2019 15:25:36 +0200
Markus Heiser <markus.heiser@darmarit.de> wrote:
> Lets use 1.7 :
>
> - no need for Use_SSI wrapper
> - new log should work with 1.7 [1] --> no need for kernellog.py and
> additional imports, instead include on top of python modules ::
>
> from sphinx.util import logging
> logger = logging.getLogger('kerneldoc')
I think we're going to have to drag things forward at some point in the
not-too-distant future, but I think I'd rather not do that quite yet. The
cost of supporting older sphinx for a few releases while we warn people is
not all that high. So I think we should:
- Put in (a future version of) my hacks for now, plus whatever else might
be needed to make 2.0 work right.
- Fix the fallout with regard to out-of-toctree .rst files so that we can
actually build again with current sphinx.
- Update Documentation/sphinx/requirements.txt to ask for something a wee
bit more recent than 1.4.9.
- Add a warning when building with an older version that (say) 1.7 will
be required as of (say) 5.5.
Does this make sense?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH RFC 0/2] docs: Deal with some Sphinx deprecation warnings
From: Markus Heiser @ 2019-05-22 13:25 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Jani Nikula
Cc: Jonathan Corbet, linux-doc, linux-kernel
In-Reply-To: <20190522071909.050bb227@coco.lan>
22.05.19 um 12:19 schrieb Mauro Carvalho Chehab:
> Em Wed, 22 May 2019 10:36:45 +0300
> Jani Nikula <jani.nikula@linux.intel.com> escreveu:
>
>> On Tue, 21 May 2019, Jonathan Corbet <corbet@lwn.net> wrote:
>>> The Sphinx folks are deprecating some interfaces in the upcoming 2.0
>>> release; one immediate result of that is a bunch of warnings that show up
>>> when building with 1.8. These two patches make those warnings go away,
>>> but at a cost:
>>>
>>> - It introduces a couple of Sphinx version checks, which are always
>>> ugly, but the alternative would be to stop supporting versions
>>> before 1.7. For now, I think we can carry that cruft.
>>
>> Frankly, I'd just require Sphinx 1.7+, available even in Debian stable
>> through stretch-backports.
>
> We can raise the bar and force a 1.7 or even 1.8 (Fedora 30 comes
> with version 1.8.4), but I would prefer to keep support older versions,
> at least while we don't depend on some new features introduced after
> the version we're using, and while our extensions won't require a major
> rework due to a new version.
Lets use 1.7 :
- no need for Use_SSI wrapper
- new log should work with 1.7 [1] --> no need for kernellog.py and
additional imports, instead include on top of python modules ::
from sphinx.util import logging
logger = logging.getLogger('kerneldoc')
[1]
https://github.com/sphinx-doc/sphinx/commit/6d4e6454093953943e79d4db6efeb17390870e62
BTW we can drop other (old) sphinx-version issues e.g.
Documentation/conf.py which fails with version 2.0:
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 72647a38b5c2..ba82715b6715 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -34,13 +34,7 @@ needs_sphinx = '1.3'
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
-extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain',
'kfigure', 'sphinx.ext.ifconfig']
-
-# The name of the math extension changed on Sphinx 1.4
-if major == 1 and minor > 3:
- extensions.append("sphinx.ext.imgmath")
-else:
- extensions.append("sphinx.ext.pngmath")
+extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain',
'kfigure', 'sphinx.ext.ifconfig', 'sphinx.ext.imgmath']
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
-- Markus --
^ permalink raw reply related
* Re: [PATCH v12 09/13] MIPS: jz4740: Add DTS nodes for the TCU drivers
From: Paul Cercueil @ 2019-05-22 11:15 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Rob Herring, Mark Rutland, Ralf Baechle, Paul Burton, James Hogan,
Jonathan Corbet, Daniel Lezcano, Thomas Gleixner,
Michael Turquette, Stephen Boyd, Jason Cooper, Marc Zyngier,
Lee Jones, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-mips, linux-doc, linux-clk, od
In-Reply-To: <CA+7wUsxe4DLmAGNnnXZ3UokguMJ0cOGtu=opQpuAPvN_SH4KUw@mail.gmail.com>
On Wed, May 22, 2019 at 11:21 AM, Mathieu Malaterre <malat@debian.org>
wrote:
> On Tue, May 21, 2019 at 4:52 PM Paul Cercueil <paul@crapouillou.net>
> wrote:
>>
>> Add DTS nodes for the JZ4780, JZ4770 and JZ4740 devicetree files.
>>
>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>> ---
>>
>> Notes:
>> v5: New patch
>>
>> v6: Fix register lengths in watchdog/pwm nodes
>>
>> v7: No change
>>
>> v8: - Fix wrong start address for PWM node
>> - Add system timer and clocksource sub-nodes
>>
>> v9: Drop timer and clocksource sub-nodes
>>
>> v10-v11: No change
>>
>> v12: Drop PWM/watchdog/OST sub-nodes, for now.
>>
>> arch/mips/boot/dts/ingenic/jz4740.dtsi | 22 ++++++++++++++++++++++
>> arch/mips/boot/dts/ingenic/jz4770.dtsi | 21 +++++++++++++++++++++
>> arch/mips/boot/dts/ingenic/jz4780.dtsi | 21 +++++++++++++++++++++
>> 3 files changed, 64 insertions(+)
>>
>> diff --git a/arch/mips/boot/dts/ingenic/jz4740.dtsi
>> b/arch/mips/boot/dts/ingenic/jz4740.dtsi
>> index 2beb78a62b7d..807d9702d4cf 100644
>> --- a/arch/mips/boot/dts/ingenic/jz4740.dtsi
>> +++ b/arch/mips/boot/dts/ingenic/jz4740.dtsi
>> @@ -53,6 +53,28 @@
>> clock-names = "rtc";
>> };
>>
>> + tcu: timer@10002000 {
>> + compatible = "ingenic,jz4740-tcu";
>> + reg = <0x10002000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x10002000 0x1000>;
>> +
>> + #clock-cells = <1>;
>> +
>> + clocks = <&cgu JZ4740_CLK_RTC
>> + &cgu JZ4740_CLK_EXT
>> + &cgu JZ4740_CLK_PCLK
>> + &cgu JZ4740_CLK_TCU>;
>> + clock-names = "rtc", "ext", "pclk", "tcu";
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> +
>> + interrupt-parent = <&intc>;
>> + interrupts = <23 22 21>;
>> + };
>> +
>> rtc_dev: rtc@10003000 {
>> compatible = "ingenic,jz4740-rtc";
>> reg = <0x10003000 0x40>;
>> diff --git a/arch/mips/boot/dts/ingenic/jz4770.dtsi
>> b/arch/mips/boot/dts/ingenic/jz4770.dtsi
>> index 49ede6c14ff3..70932fd90902 100644
>> --- a/arch/mips/boot/dts/ingenic/jz4770.dtsi
>> +++ b/arch/mips/boot/dts/ingenic/jz4770.dtsi
>> @@ -46,6 +46,27 @@
>> #clock-cells = <1>;
>> };
>>
>> + tcu: timer@10002000 {
>> + compatible = "ingenic,jz4770-tcu";
>> + reg = <0x10002000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x10002000 0x1000>;
>> +
>> + #clock-cells = <1>;
>> +
>> + clocks = <&cgu JZ4770_CLK_RTC
>> + &cgu JZ4770_CLK_EXT
>> + &cgu JZ4770_CLK_PCLK>;
>> + clock-names = "rtc", "ext", "pclk";
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> +
>> + interrupt-parent = <&intc>;
>> + interrupts = <27 26 25>;
>> + };
>> +
>> pinctrl: pin-controller@10010000 {
>> compatible = "ingenic,jz4770-pinctrl";
>> reg = <0x10010000 0x600>;
>> diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
>> b/arch/mips/boot/dts/ingenic/jz4780.dtsi
>> index b03cdec56de9..495082ce7fc5 100644
>> --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
>> +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
>> @@ -46,6 +46,27 @@
>> #clock-cells = <1>;
>> };
>>
>> + tcu: timer@10002000 {
>
> With W=1, I see:
>
> ../arch/mips/boot/dts/ingenic/jz4780.dtsi:64.22-83.4: Warning
> (unique_unit_address): /timer@10002000: duplicate unit-address (also
> used in node /watchdog@1000
> 2000)
That didn't happen in V11 because there I was also migrating the
watchdog and PWM drivers to children nodes of the TCU. It was more
atomic, but it also was a 27-patches bomb touching a lot of
subsystems that nobody was ever going to merge.
Is the address conflict OK, knowing that the watchdog node will
move out of the way as soon as this patchset is merged?
Should I add an extra patch to remove the watchdog node instead?
(and yes, devicetree ABI will break, which is sort-of OK in this
case - as on Ingenic boards the devicetree blobs are always
compiled within the kernel, so I think we should make this
much-needed change while we still can).
>> + compatible = "ingenic,jz4770-tcu";
>> + reg = <0x10002000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x10002000 0x1000>;
>> +
>> + #clock-cells = <1>;
>> +
>> + clocks = <&cgu JZ4780_CLK_RTCLK
>> + &cgu JZ4780_CLK_EXCLK
>> + &cgu JZ4780_CLK_PCLK>;
>> + clock-names = "rtc", "ext", "pclk";
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> +
>> + interrupt-parent = <&intc>;
>> + interrupts = <27 26 25>;
>> + };
>> +
>> rtc_dev: rtc@10003000 {
>> compatible = "ingenic,jz4780-rtc";
>> reg = <0x10003000 0x4c>;
>> --
>> 2.21.0.593.g511ec345e18
>>
^ permalink raw reply
* Re: [PATCH RFC 0/2] docs: Deal with some Sphinx deprecation warnings
From: Mauro Carvalho Chehab @ 2019-05-22 10:19 UTC (permalink / raw)
To: Jani Nikula; +Cc: Jonathan Corbet, linux-doc, linux-kernel, Markus Heiser
In-Reply-To: <87d0kb7xf6.fsf@intel.com>
Em Wed, 22 May 2019 10:36:45 +0300
Jani Nikula <jani.nikula@linux.intel.com> escreveu:
> On Tue, 21 May 2019, Jonathan Corbet <corbet@lwn.net> wrote:
> > The Sphinx folks are deprecating some interfaces in the upcoming 2.0
> > release; one immediate result of that is a bunch of warnings that show up
> > when building with 1.8. These two patches make those warnings go away,
> > but at a cost:
> >
> > - It introduces a couple of Sphinx version checks, which are always
> > ugly, but the alternative would be to stop supporting versions
> > before 1.7. For now, I think we can carry that cruft.
>
> Frankly, I'd just require Sphinx 1.7+, available even in Debian stable
> through stretch-backports.
We can raise the bar and force a 1.7 or even 1.8 (Fedora 30 comes
with version 1.8.4), but I would prefer to keep support older versions,
at least while we don't depend on some new features introduced after
the version we're using, and while our extensions won't require a major
rework due to a new version.
>
> > - The second patch causes the build to fail horribly on newer
> > Sphinx installations. The change to switch_source_input() seems
> > to make the parser much more finicky, increasing warnings and
> > eventually failing the build altogether. In particular, it will
> > scream about problems in .rst files that are not included in the
> > TOC tree at all. The complaints appear to be legitimate, but it's
> > a bunch of stuff to clean up.
There is a flag to cleanup the warning about a file not included at
a TOC tree (:orphan:), but it will still try to parse it. There's also
a conf.py way of doing it. For example, you can exclude an entire dir:
exclude_patterns = ['includes/*.rst']
But using exclude_patterns will likely be too messy.
> I can understand Sphinx complaining that a file is not included in a TOC
> tree, but I don't understand why it goes on to parse them anyway.
Yeah, this is, IMHO, a very bad behavior.
>
> BR,
> Jani.
>
>
> >
> > I've tested these with 1.4 and 1.8, but not various versions in between.
> >
> > Jonathan Corbet (2):
> > doc: Cope with Sphinx logging deprecations
> > doc: Cope with the deprecation of AutoReporter
> >
> > Documentation/sphinx/kerneldoc.py | 48 ++++++++++++++++++++++++-------
> > Documentation/sphinx/kernellog.py | 28 ++++++++++++++++++
> > Documentation/sphinx/kfigure.py | 38 +++++++++++++-----------
> > 3 files changed, 87 insertions(+), 27 deletions(-)
> > create mode 100644 Documentation/sphinx/kernellog.py
>
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH RFC 0/2] docs: Deal with some Sphinx deprecation warnings
From: Oleksandr Natalenko @ 2019-05-22 9:49 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, linux-kernel, Jani Nikula, Markus Heiser,
Mauro Carvalho Chehab
In-Reply-To: <20190522094354.mnolo6bh6yeiza5h@butterfly.localdomain>
On Wed, May 22, 2019 at 11:43:54AM +0200, Oleksandr Natalenko wrote:
> On Tue, May 21, 2019 at 03:17:12PM -0600, Jonathan Corbet wrote:
> > The Sphinx folks are deprecating some interfaces in the upcoming 2.0
> > release; one immediate result of that is a bunch of warnings that show up
> > when building with 1.8. These two patches make those warnings go away,
> > but at a cost:
>
> A minor correction, if I may and if I understand this correctly: 2.0 is
> not an upcoming release, but a current one (2.0.1, to be precise), and
> this means that in some distros (like, Arch [1]) `make htmldocs` is
> already broken for quite some time.
>
> [1] https://bugs.archlinux.org/task/59688
^^ this was the initial Bug for introducing the doc, but it got reverted
in [2].
[2] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=cfe52e9aa8168d9571bedf8a376e2cfbd25223fd
>
> >
> > - It introduces a couple of Sphinx version checks, which are always
> > ugly, but the alternative would be to stop supporting versions
> > before 1.7. For now, I think we can carry that cruft.
> >
> > - The second patch causes the build to fail horribly on newer
> > Sphinx installations. The change to switch_source_input() seems
> > to make the parser much more finicky, increasing warnings and
> > eventually failing the build altogether. In particular, it will
> > scream about problems in .rst files that are not included in the
> > TOC tree at all. The complaints appear to be legitimate, but it's
> > a bunch of stuff to clean up.
> >
> > I've tested these with 1.4 and 1.8, but not various versions in between.
> >
> > Jonathan Corbet (2):
> > doc: Cope with Sphinx logging deprecations
> > doc: Cope with the deprecation of AutoReporter
> >
> > Documentation/sphinx/kerneldoc.py | 48 ++++++++++++++++++++++++-------
> > Documentation/sphinx/kernellog.py | 28 ++++++++++++++++++
> > Documentation/sphinx/kfigure.py | 38 +++++++++++++-----------
> > 3 files changed, 87 insertions(+), 27 deletions(-)
> > create mode 100644 Documentation/sphinx/kernellog.py
> >
> > --
> > 2.21.0
> >
>
> --
> Best regards,
> Oleksandr Natalenko (post-factum)
> Senior Software Maintenance Engineer
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
^ permalink raw reply
* Re: [PATCH RFC 0/2] docs: Deal with some Sphinx deprecation warnings
From: Oleksandr Natalenko @ 2019-05-22 9:43 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, linux-kernel, Jani Nikula, Markus Heiser,
Mauro Carvalho Chehab
In-Reply-To: <20190521211714.1395-1-corbet@lwn.net>
On Tue, May 21, 2019 at 03:17:12PM -0600, Jonathan Corbet wrote:
> The Sphinx folks are deprecating some interfaces in the upcoming 2.0
> release; one immediate result of that is a bunch of warnings that show up
> when building with 1.8. These two patches make those warnings go away,
> but at a cost:
A minor correction, if I may and if I understand this correctly: 2.0 is
not an upcoming release, but a current one (2.0.1, to be precise), and
this means that in some distros (like, Arch [1]) `make htmldocs` is
already broken for quite some time.
[1] https://bugs.archlinux.org/task/59688
>
> - It introduces a couple of Sphinx version checks, which are always
> ugly, but the alternative would be to stop supporting versions
> before 1.7. For now, I think we can carry that cruft.
>
> - The second patch causes the build to fail horribly on newer
> Sphinx installations. The change to switch_source_input() seems
> to make the parser much more finicky, increasing warnings and
> eventually failing the build altogether. In particular, it will
> scream about problems in .rst files that are not included in the
> TOC tree at all. The complaints appear to be legitimate, but it's
> a bunch of stuff to clean up.
>
> I've tested these with 1.4 and 1.8, but not various versions in between.
>
> Jonathan Corbet (2):
> doc: Cope with Sphinx logging deprecations
> doc: Cope with the deprecation of AutoReporter
>
> Documentation/sphinx/kerneldoc.py | 48 ++++++++++++++++++++++++-------
> Documentation/sphinx/kernellog.py | 28 ++++++++++++++++++
> Documentation/sphinx/kfigure.py | 38 +++++++++++++-----------
> 3 files changed, 87 insertions(+), 27 deletions(-)
> create mode 100644 Documentation/sphinx/kernellog.py
>
> --
> 2.21.0
>
--
Best regards,
Oleksandr Natalenko (post-factum)
Senior Software Maintenance Engineer
^ permalink raw reply
* Re: [PATCH v12 09/13] MIPS: jz4740: Add DTS nodes for the TCU drivers
From: Mathieu Malaterre @ 2019-05-22 9:21 UTC (permalink / raw)
To: Paul Cercueil
Cc: Rob Herring, Mark Rutland, Ralf Baechle, Paul Burton, James Hogan,
Jonathan Corbet, Daniel Lezcano, Thomas Gleixner,
Michael Turquette, Stephen Boyd, Jason Cooper, Marc Zyngier,
Lee Jones, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-mips, linux-doc, linux-clk, od
In-Reply-To: <20190521145141.9813-10-paul@crapouillou.net>
On Tue, May 21, 2019 at 4:52 PM Paul Cercueil <paul@crapouillou.net> wrote:
>
> Add DTS nodes for the JZ4780, JZ4770 and JZ4740 devicetree files.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>
> Notes:
> v5: New patch
>
> v6: Fix register lengths in watchdog/pwm nodes
>
> v7: No change
>
> v8: - Fix wrong start address for PWM node
> - Add system timer and clocksource sub-nodes
>
> v9: Drop timer and clocksource sub-nodes
>
> v10-v11: No change
>
> v12: Drop PWM/watchdog/OST sub-nodes, for now.
>
> arch/mips/boot/dts/ingenic/jz4740.dtsi | 22 ++++++++++++++++++++++
> arch/mips/boot/dts/ingenic/jz4770.dtsi | 21 +++++++++++++++++++++
> arch/mips/boot/dts/ingenic/jz4780.dtsi | 21 +++++++++++++++++++++
> 3 files changed, 64 insertions(+)
>
> diff --git a/arch/mips/boot/dts/ingenic/jz4740.dtsi b/arch/mips/boot/dts/ingenic/jz4740.dtsi
> index 2beb78a62b7d..807d9702d4cf 100644
> --- a/arch/mips/boot/dts/ingenic/jz4740.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4740.dtsi
> @@ -53,6 +53,28 @@
> clock-names = "rtc";
> };
>
> + tcu: timer@10002000 {
> + compatible = "ingenic,jz4740-tcu";
> + reg = <0x10002000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x10002000 0x1000>;
> +
> + #clock-cells = <1>;
> +
> + clocks = <&cgu JZ4740_CLK_RTC
> + &cgu JZ4740_CLK_EXT
> + &cgu JZ4740_CLK_PCLK
> + &cgu JZ4740_CLK_TCU>;
> + clock-names = "rtc", "ext", "pclk", "tcu";
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <23 22 21>;
> + };
> +
> rtc_dev: rtc@10003000 {
> compatible = "ingenic,jz4740-rtc";
> reg = <0x10003000 0x40>;
> diff --git a/arch/mips/boot/dts/ingenic/jz4770.dtsi b/arch/mips/boot/dts/ingenic/jz4770.dtsi
> index 49ede6c14ff3..70932fd90902 100644
> --- a/arch/mips/boot/dts/ingenic/jz4770.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4770.dtsi
> @@ -46,6 +46,27 @@
> #clock-cells = <1>;
> };
>
> + tcu: timer@10002000 {
> + compatible = "ingenic,jz4770-tcu";
> + reg = <0x10002000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x10002000 0x1000>;
> +
> + #clock-cells = <1>;
> +
> + clocks = <&cgu JZ4770_CLK_RTC
> + &cgu JZ4770_CLK_EXT
> + &cgu JZ4770_CLK_PCLK>;
> + clock-names = "rtc", "ext", "pclk";
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <27 26 25>;
> + };
> +
> pinctrl: pin-controller@10010000 {
> compatible = "ingenic,jz4770-pinctrl";
> reg = <0x10010000 0x600>;
> diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> index b03cdec56de9..495082ce7fc5 100644
> --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> @@ -46,6 +46,27 @@
> #clock-cells = <1>;
> };
>
> + tcu: timer@10002000 {
With W=1, I see:
../arch/mips/boot/dts/ingenic/jz4780.dtsi:64.22-83.4: Warning
(unique_unit_address): /timer@10002000: duplicate unit-address (also
used in node /watchdog@1000
2000)
> + compatible = "ingenic,jz4770-tcu";
> + reg = <0x10002000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x10002000 0x1000>;
> +
> + #clock-cells = <1>;
> +
> + clocks = <&cgu JZ4780_CLK_RTCLK
> + &cgu JZ4780_CLK_EXCLK
> + &cgu JZ4780_CLK_PCLK>;
> + clock-names = "rtc", "ext", "pclk";
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <27 26 25>;
> + };
> +
> rtc_dev: rtc@10003000 {
> compatible = "ingenic,jz4780-rtc";
> reg = <0x10003000 0x4c>;
> --
> 2.21.0.593.g511ec345e18
>
^ permalink raw reply
* [PATCH v2 2/2] tracing/kprobe: Add kprobe_event= boot parameter
From: Masami Hiramatsu @ 2019-05-22 8:32 UTC (permalink / raw)
To: Steven Rostedt
Cc: Ingo Molnar, Naveen N . Rao, Anil S Keshavamurthy,
David S . Miller, Masami Hiramatsu, linux-kernel, linux-doc
In-Reply-To: <155851393823.15728.9489409117921369593.stgit@devnote2>
Add kprobe_event= boot parameter to define kprobe events
at boot time.
The definition syntax is similar to tracefs/kprobe_events
interface, but use ',' and ';' instead of ' ' and '\n'
respectively. e.g.
kprobe_event=p,vfs_read,$arg1,$arg2
This puts a probe on vfs_read with argument1 and 2, and
enable the new event.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
---
Documentation/admin-guide/kernel-parameters.txt | 13 ++++++
Documentation/trace/kprobetrace.rst | 14 ++++++
kernel/trace/trace_kprobe.c | 54 +++++++++++++++++++++++
3 files changed, 81 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 2b8ee90bb644..96b22db7f763 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2002,6 +2002,19 @@
Built with CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y,
the default is off.
+ kprobe_event=[probe-list]
+ [FTRACE] Add kprobe events and enable at boot time.
+ The probe-list is a semicolon delimited list of probe
+ definitions. Each definition is same as kprobe_events
+ interface, but the parameters are comma delimited.
+ For example, to add a kprobe event on vfs_read with
+ arg1 and arg2, add to the command line;
+
+ kprobe_event=p,vfs_read,$arg1,$arg2
+
+ See also Documentation/trace/kprobetrace.rst "Kernel
+ Boot Parameter" section.
+
kpti= [ARM64] Control page table isolation of user
and kernel address spaces.
Default: enabled on cores which need mitigation.
diff --git a/Documentation/trace/kprobetrace.rst b/Documentation/trace/kprobetrace.rst
index 235ce2ab131a..5b129215ba33 100644
--- a/Documentation/trace/kprobetrace.rst
+++ b/Documentation/trace/kprobetrace.rst
@@ -124,6 +124,20 @@ You can check the total number of probe hits and probe miss-hits via
The first column is event name, the second is the number of probe hits,
the third is the number of probe miss-hits.
+Kernel Boot Parameter
+---------------------
+You can add and enable new kprobe events when booting up the kernel by
+"kprobe_event=" parameter. The parameter accepts a semicolon-delimited
+kprobe events, which format is similar to the kprobe_events.
+The difference is that the probe definition parameters are comma-delimited
+instead of space. For example, adding myprobe event on do_sys_open like below
+
+ p:myprobe do_sys_open dfd=%ax filename=%dx flags=%cx mode=+4($stack)
+
+should be below for kernel boot parameter (just replace spaces with comma)
+
+ p:myprobe,do_sys_open,dfd=%ax,filename=%dx,flags=%cx,mode=+4($stack)
+
Usage examples
--------------
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 7d736248a070..6983435ff017 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -12,6 +12,8 @@
#include <linux/rculist.h>
#include <linux/error-injection.h>
+#include <asm/setup.h> /* for COMMAND_LINE_SIZE */
+
#include "trace_dynevent.h"
#include "trace_kprobe_selftest.h"
#include "trace_probe.h"
@@ -19,6 +21,17 @@
#define KPROBE_EVENT_SYSTEM "kprobes"
#define KRETPROBE_MAXACTIVE_MAX 4096
+#define MAX_KPROBE_CMDLINE_SIZE 1024
+
+/* Kprobe early definition from command line */
+static char kprobe_boot_events_buf[COMMAND_LINE_SIZE] __initdata;
+
+static int __init set_kprobe_boot_events(char *str)
+{
+ strlcpy(kprobe_boot_events_buf, str, COMMAND_LINE_SIZE);
+ return 0;
+}
+__setup("kprobe_event=", set_kprobe_boot_events);
static int trace_kprobe_create(int argc, const char **argv);
static int trace_kprobe_show(struct seq_file *m, struct dyn_event *ev);
@@ -1450,6 +1463,44 @@ void destroy_local_trace_kprobe(struct trace_event_call *event_call)
}
#endif /* CONFIG_PERF_EVENTS */
+static __init void enable_boot_kprobe_events(void)
+{
+ struct trace_array *tr = top_trace_array();
+ struct trace_event_file *file;
+ struct trace_kprobe *tk;
+ struct dyn_event *pos;
+
+ mutex_lock(&event_mutex);
+ for_each_trace_kprobe(tk, pos) {
+ list_for_each_entry(file, &tr->events, list)
+ if (file->event_call == &tk->tp.call)
+ trace_event_enable_disable(file, 1, 0);
+ }
+ mutex_unlock(&event_mutex);
+}
+
+static __init void setup_boot_kprobe_events(void)
+{
+ char *p, *cmd = kprobe_boot_events_buf;
+ int ret;
+
+ strreplace(kprobe_boot_events_buf, ',', ' ');
+
+ while (cmd && *cmd != '\0') {
+ p = strchr(cmd, ';');
+ if (p)
+ *p++ = '\0';
+
+ ret = trace_run_command(cmd, create_or_delete_trace_kprobe);
+ if (ret)
+ pr_warn("Failed to add event(%d): %s\n", ret, cmd);
+
+ cmd = p;
+ }
+
+ enable_boot_kprobe_events();
+}
+
/* Make a tracefs interface for controlling probe points */
static __init int init_kprobe_trace(void)
{
@@ -1481,6 +1532,9 @@ static __init int init_kprobe_trace(void)
if (!entry)
pr_warn("Could not create tracefs 'kprobe_profile' entry\n");
+
+ setup_boot_kprobe_events();
+
return 0;
}
fs_initcall(init_kprobe_trace);
^ permalink raw reply related
* [PATCH v2 1/2] kprobes: Initialize kprobes at postcore_initcall
From: Masami Hiramatsu @ 2019-05-22 8:32 UTC (permalink / raw)
To: Steven Rostedt
Cc: Ingo Molnar, Naveen N . Rao, Anil S Keshavamurthy,
David S . Miller, Masami Hiramatsu, linux-kernel, linux-doc
In-Reply-To: <155851393823.15728.9489409117921369593.stgit@devnote2>
Initialize kprobes at postcore_initcall level instead of module_init
since kprobes is not a module, and it depends on only subsystems
initialized in core_initcall.
This will allow ftrace kprobe event to add new events when it is
initializing because ftrace kprobe event is initialized at
later initcall level.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
---
Changes in v2
- use postcore_initcall instead of subsys_initcall
---
kernel/kprobes.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index c83e54727131..5d51dd84b1a2 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2291,6 +2291,7 @@ static int __init init_kprobes(void)
init_test_probes();
return err;
}
+postcore_initcall(init_kprobes);
#ifdef CONFIG_DEBUG_FS
static void report_probe(struct seq_file *pi, struct kprobe *p,
@@ -2616,5 +2617,3 @@ static int __init debugfs_kprobe_init(void)
late_initcall(debugfs_kprobe_init);
#endif /* CONFIG_DEBUG_FS */
-
-module_init(init_kprobes);
^ permalink raw reply related
* [PATCH v2 0/2] Enable new kprobe event at boot
From: Masami Hiramatsu @ 2019-05-22 8:32 UTC (permalink / raw)
To: Steven Rostedt
Cc: Ingo Molnar, Naveen N . Rao, Anil S Keshavamurthy,
David S . Miller, Masami Hiramatsu, linux-kernel, linux-doc
Hi,
This v2 series adds a kernel parameter, 'kprobe_event=' to add and enable
new kprobe events at boot time.
In this version, I changed to use postcore_initcall() instead of
subsys_initcall() for kprobes initialization.
Currently ftrace can enable some existing trace events at boot time.
This also allows admin/developer to add new kprobe-events at boot
time to debug device drivers etc.
The syntax is similar to tracing/kprobe_events interface, but
uses ',' and ';' instead of ' ' and '\n' respectively. e.g.
kprobe_event=p,func1,$arg1,$arg2;p,func2,$arg1
will add probes on func1 with the 1st and the 2nd arguments and on
func2 with the 1st argument.
Note that 'trace_event=' option enables trace event at very early
timing, but the events added by 'kprobe_event=' are enabled right
before enabling device drivers at this point. It is enough for
tracing device driver initialization etc.
Thank you,
---
Masami Hiramatsu (2):
kprobes: Initialize kprobes at postcore_initcall
tracing/kprobe: Add kprobe_event= boot parameter
Documentation/admin-guide/kernel-parameters.txt | 13 ++++++
Documentation/trace/kprobetrace.rst | 14 ++++++
kernel/kprobes.c | 3 -
kernel/trace/trace_kprobe.c | 54 +++++++++++++++++++++++
4 files changed, 82 insertions(+), 2 deletions(-)
--
Masami Hiramatsu (Linaro)
^ permalink raw reply
* Re: [PATCH 0/2] Enable new kprobe event at boot
From: Masami Hiramatsu @ 2019-05-22 8:02 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Steven Rostedt, Ingo Molnar, Naveen N . Rao, Anil S Keshavamurthy,
David S . Miller, linux-kernel, linux-doc
In-Reply-To: <20190522163021.b8d08103dd5df01b2e472e46@kernel.org>
On Wed, 22 May 2019 16:30:21 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> On Wed, 22 May 2019 00:39:32 +0900
> Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> > > Perhaps we could enable kprobes at early init?
> >
> > It should be possible, I will try to find what blocks it. I guess after we
> > switch early_text_poke() to text_poke(), we can use kprobes on x86. But
> > for other archs, I need to investigate more.
>
> OK, I just follow the kernel init related to kprobes
>
> start_kernel()
> -> trace_init()
> -> rcu_init_nohz()
> -> perf_event_init()
> -> arch_call_rest_init()
> -> rest_init()
> -> rcu_scheduler_starting()
> -> kernel_thread(kernel_init)
> kernel_init()
> -> kernel_init_freeable()
> -> wait_for_completion(&kthreadd_done);
> -> workqueue_init()
> -> smp_init()
> -> do_basic_setup()
> -> do_initcalls()
> -> do_initcall_level()
> (in subsys-level)
> -> init_kprobes()
>
> Since optprobe uses workqueue, we can not move it before workqueue_init().
> (but maybe we can disable it in early stage)
> Also, since kprobes depends on rcu, I guess we can not move it before
> rcu_scheduler_starting().
It seems rcu is not initialized yet at this point. It is initialized fully
at core_initcall.
> for kretprobe, we need to get the possible cpus, we need a fix if we move
> it before before smp_init().
> However, there is no reason we need to run it in subsys level. We can
> move init_kprobes() in core or pure level safely.
Also, I missed ftrace (function tracer) is initialized at core_initcall().
So we can move init_kprobes() at postcore_initcall() safely.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] doc: Cope with the deprecation of AutoReporter
From: Jani Nikula @ 2019-05-22 7:38 UTC (permalink / raw)
To: Jonathan Corbet, linux-doc
Cc: linux-kernel, Markus Heiser, Mauro Carvalho Chehab,
Jonathan Corbet
In-Reply-To: <20190521211714.1395-3-corbet@lwn.net>
On Tue, 21 May 2019, Jonathan Corbet <corbet@lwn.net> wrote:
> AutoReporter is going away; recent versions of sphinx emit a warning like:
>
> /stuff/k/git/kernel/Documentation/sphinx/kerneldoc.py:125:
> RemovedInSphinx20Warning: AutodocReporter is now deprecated.
> Use sphinx.util.docutils.switch_source_input() instead.
>
> Make the switch. But switch_source_input() only showed up in 1.7, so we
> have to do ugly version checks to keep things working in older versions.
> ---
> Documentation/sphinx/kerneldoc.py | 38 ++++++++++++++++++++++++-------
> 1 file changed, 30 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/sphinx/kerneldoc.py b/Documentation/sphinx/kerneldoc.py
> index e8891e63e001..d3216f7b4170 100644
> --- a/Documentation/sphinx/kerneldoc.py
> +++ b/Documentation/sphinx/kerneldoc.py
> @@ -37,7 +37,17 @@ import glob
> from docutils import nodes, statemachine
> from docutils.statemachine import ViewList
> from docutils.parsers.rst import directives, Directive
> -from sphinx.ext.autodoc import AutodocReporter
> +
> +#
> +# AutodocReporter is only good up to Sphinx 1.7
> +#
> +import sphinx
> +
> +Use_SSI = sphinx.__version__[:3] >= '1.7'
> +if Use_SSI:
> + from sphinx.util.docutils import switch_source_input
> +else:
> + from sphinx.ext.autodoc import AutodocReporter
>
> import kernellog
>
> @@ -125,13 +135,7 @@ class KernelDocDirective(Directive):
> lineoffset += 1
>
> node = nodes.section()
> - buf = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter
> - self.state.memo.reporter = AutodocReporter(result, self.state.memo.reporter)
> - self.state.memo.title_styles, self.state.memo.section_level = [], 0
> - try:
> - self.state.nested_parse(result, 0, node, match_titles=1)
> - finally:
> - self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = buf
> + self.do_parse(result, node)
>
> return node.children
>
> @@ -140,6 +144,24 @@ class KernelDocDirective(Directive):
> (" ".join(cmd), str(e)))
> return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))]
>
> + def do_parse(self, result, node):
> + if Use_SSI:
> + save = self.state.memo.title_styles, self.state.memo.section_level
> + try:
> + with switch_source_input(self.state, result):
> + self.state.nested_parse(result, 0, node, match_titles=1)
IIUC you don't need to save the state anymore, so the above two lines
should be sufficient when using switch_source_input.
BR,
Jani.
> + finally:
> + self.state.memo.title_styles, self.state.memo.section_level = save
> + else:
> + save = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter
> + self.state.memo.reporter = AutodocReporter(result, self.state.memo.reporter)
> + self.state.memo.title_styles, self.state.memo.section_level = [], 0
> + try:
> + self.state.nested_parse(result, 0, node, match_titles=1)
> + finally:
> + self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = save
> +
> +
> def setup(app):
> app.add_config_value('kerneldoc_bin', None, 'env')
> app.add_config_value('kerneldoc_srctree', None, 'env')
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH RFC 0/2] docs: Deal with some Sphinx deprecation warnings
From: Jani Nikula @ 2019-05-22 7:36 UTC (permalink / raw)
To: Jonathan Corbet, linux-doc
Cc: linux-kernel, Markus Heiser, Mauro Carvalho Chehab,
Jonathan Corbet
In-Reply-To: <20190521211714.1395-1-corbet@lwn.net>
On Tue, 21 May 2019, Jonathan Corbet <corbet@lwn.net> wrote:
> The Sphinx folks are deprecating some interfaces in the upcoming 2.0
> release; one immediate result of that is a bunch of warnings that show up
> when building with 1.8. These two patches make those warnings go away,
> but at a cost:
>
> - It introduces a couple of Sphinx version checks, which are always
> ugly, but the alternative would be to stop supporting versions
> before 1.7. For now, I think we can carry that cruft.
Frankly, I'd just require Sphinx 1.7+, available even in Debian stable
through stretch-backports.
> - The second patch causes the build to fail horribly on newer
> Sphinx installations. The change to switch_source_input() seems
> to make the parser much more finicky, increasing warnings and
> eventually failing the build altogether. In particular, it will
> scream about problems in .rst files that are not included in the
> TOC tree at all. The complaints appear to be legitimate, but it's
> a bunch of stuff to clean up.
I can understand Sphinx complaining that a file is not included in a TOC
tree, but I don't understand why it goes on to parse them anyway.
BR,
Jani.
>
> I've tested these with 1.4 and 1.8, but not various versions in between.
>
> Jonathan Corbet (2):
> doc: Cope with Sphinx logging deprecations
> doc: Cope with the deprecation of AutoReporter
>
> Documentation/sphinx/kerneldoc.py | 48 ++++++++++++++++++++++++-------
> Documentation/sphinx/kernellog.py | 28 ++++++++++++++++++
> Documentation/sphinx/kfigure.py | 38 +++++++++++++-----------
> 3 files changed, 87 insertions(+), 27 deletions(-)
> create mode 100644 Documentation/sphinx/kernellog.py
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH 0/2] Enable new kprobe event at boot
From: Masami Hiramatsu @ 2019-05-22 7:30 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Steven Rostedt, Ingo Molnar, Naveen N . Rao, Anil S Keshavamurthy,
David S . Miller, linux-kernel, linux-doc
In-Reply-To: <20190522003932.34367dcae6d9de27e254e174@kernel.org>
On Wed, 22 May 2019 00:39:32 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> > Perhaps we could enable kprobes at early init?
>
> It should be possible, I will try to find what blocks it. I guess after we
> switch early_text_poke() to text_poke(), we can use kprobes on x86. But
> for other archs, I need to investigate more.
OK, I just follow the kernel init related to kprobes
start_kernel()
-> trace_init()
-> rcu_init_nohz()
-> perf_event_init()
-> arch_call_rest_init()
-> rest_init()
-> rcu_scheduler_starting()
-> kernel_thread(kernel_init)
kernel_init()
-> kernel_init_freeable()
-> wait_for_completion(&kthreadd_done);
-> workqueue_init()
-> smp_init()
-> do_basic_setup()
-> do_initcalls()
-> do_initcall_level()
(in subsys-level)
-> init_kprobes()
Since optprobe uses workqueue, we can not move it before workqueue_init().
(but maybe we can disable it in early stage)
Also, since kprobes depends on rcu, I guess we can not move it before
rcu_scheduler_starting().
for kretprobe, we need to get the possible cpus, we need a fix if we move
it before before smp_init().
However, there is no reason we need to run it in subsys level. We can
move init_kprobes() in core or pure level safely.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH] docs: reorder memory-hotplug documentation
From: David Hildenbrand @ 2019-05-22 7:29 UTC (permalink / raw)
To: Oscar Salvador
Cc: Mike Rapoport, Jonathan Corbet, linux-doc, linux-mm, linux-kernel
In-Reply-To: <20190521161101.GA2372@linux>
On 21.05.19 18:11, Oscar Salvador wrote:
> On Tue, May 21, 2019 at 12:41:50PM +0200, David Hildenbrand wrote:
>>> +Future Work
>>> +===========
>>> +
>>> + - allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like
>>> + sysctl or new control file.
>>
>> ... that already works if I am not completely missing the point here
>
> It does.
>
>>> + - support HugeTLB page migration and offlining.
>>
>> ... I remember that Oscar was doing something in that area, Oscar?
>
> Yes, in general offlinining on hugetlb pages was already working, but we did not
> allow to offline 1GB-hugetlb pages on x86_64.
> I removed that limitation with
> ("commit: 10eeadf3045c mm,memory_hotplug: unlock 1GB-hugetlb on x86_64") , so now
> offlining on hugetlb pages should be fully operative.
>
>> I'd vote for removing the future work part, this is pretty outdated.
>
> Instead of removing it, I would rather make it consistent with the present.
> E.g:
>
> - Move page handling from memory-hotremove to offline stage
> - Enable a way to allocate vmemmap pages from hot-added memory
> etc.
>
>
Fair enough, but at least the current content is absolutely useless and
confusing/misleading.
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH v3] doc: kernel-parameters.txt: fix documentation of nmi_watchdog parameter
From: Zhenzhong Duan @ 2019-05-21 2:32 UTC (permalink / raw)
To: linux-kernel, linux-doc
Cc: paulmck, josh, rostedt, mathieu.desnoyers, jiangshanlai, joel,
corbet, tglx, mingo, gregkh, keescook, srinivas.eeda,
Zhenzhong Duan
The default behavior of hardlockup depends on the config of
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC.
Fix the description of nmi_watchdog to make it clear.
Suggested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-doc@vger.kernel.org
---
v3: add Suggested-by and Acked-by
v2: fix description using words suggested by Steven Rostedt
Documentation/admin-guide/kernel-parameters.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 08df588..b9d4358 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2805,8 +2805,9 @@
0 - turn hardlockup detector in nmi_watchdog off
1 - turn hardlockup detector in nmi_watchdog on
When panic is specified, panic when an NMI watchdog
- timeout occurs (or 'nopanic' to override the opposite
- default). To disable both hard and soft lockup detectors,
+ timeout occurs (or 'nopanic' to not panic on an NMI
+ watchdog, if CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is set)
+ To disable both hard and soft lockup detectors,
please see 'nowatchdog'.
This is useful when you use a panic=... timeout and
need the box quickly up again.
--
1.8.3.1
^ permalink raw reply related
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