tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
Merge tag 'docs-6.5-2' of git://git.lwn.net/linux
Pull mode documentation updates from Jonathan Corbet:
"A half-dozen late arriving docs patches. They are mostly fixes, but we
also have a kernel-doc tweak for enums and the long-overdue removal of
the outdated and redundant patch-submission comments at the top of the
MAINTAINERS file"
* tag 'docs-6.5-2' of git://git.lwn.net/linux:
scripts: kernel-doc: support private / public marking for enums
Documentation: KVM: SEV: add a missing backtick
Documentation: ACPI: fix typo in ssdt-overlays.rst
Fix documentation of panic_on_warn
docs: remove the tips on how to submit patches from MAINTAINERS
docs: fix typo in zh_TW and zh_CN translation
+24
-90
+1
-1
Documentation/admin-guide/acpi/ssdt-overlays.rst
+1
-1
Documentation/admin-guide/acpi/ssdt-overlays.rst
···
103
103
is also work underway to implement EFI support for loading user defined SSDTs
104
104
and using this method will make it easier to convert to the EFI loading
105
105
mechanism when that will arrive. To enable it, the
106
-
CONFIG_EFI_CUSTOM_SSDT_OVERLAYS shoyld be chosen to y.
106
+
CONFIG_EFI_CUSTOM_SSDT_OVERLAYS should be chosen to y.
107
107
108
108
In order to load SSDTs from an EFI variable the ``"efivar_ssdt=..."`` kernel
109
109
command line parameter can be used (the name has a limitation of 16 characters).
+1
-1
Documentation/admin-guide/kernel-parameters.txt
+1
-1
Documentation/admin-guide/kernel-parameters.txt
···
4064
4064
extra details on the taint flags that users can pick
4065
4065
to compose the bitmask to assign to panic_on_taint.
4066
4066
4067
-
panic_on_warn panic() instead of WARN(). Useful to cause kdump
4067
+
panic_on_warn=1 panic() instead of WARN(). Useful to cause kdump
4068
4068
on a WARN().
4069
4069
4070
4070
parkbd.port= [HW] Parallel port number the keyboard adapter is
+7
Documentation/process/6.Followthrough.rst
+7
Documentation/process/6.Followthrough.rst
···
51
51
working toward the creation of the best kernel they can; they are not
52
52
trying to create discomfort for their employers' competitors.
53
53
54
+
- Be prepared for seemingly silly requests for coding style changes
55
+
and requests to factor out some of your code to shared parts of
56
+
the kernel. One job the maintainers do is to keep things looking
57
+
the same. Sometimes this means that the clever hack in your driver
58
+
to get around a problem actually needs to become a generalized
59
+
kernel feature ready for next time.
60
+
54
61
What all of this comes down to is that, when reviewers send you comments,
55
62
you need to pay attention to the technical observations that they are
56
63
making. Do not let their form of expression or your own pride keep that
+1
-1
Documentation/translations/zh_CN/process/2.Process.rst
+1
-1
Documentation/translations/zh_CN/process/2.Process.rst
+1
-1
Documentation/translations/zh_CN/process/3.Early-stage.rst
+1
-1
Documentation/translations/zh_CN/process/3.Early-stage.rst
+1
-1
Documentation/translations/zh_CN/process/4.Coding.rst
+1
-1
Documentation/translations/zh_CN/process/4.Coding.rst
+1
-1
Documentation/translations/zh_CN/process/7.AdvancedTopics.rst
+1
-1
Documentation/translations/zh_CN/process/7.AdvancedTopics.rst
+1
-1
Documentation/translations/zh_TW/process/2.Process.rst
+1
-1
Documentation/translations/zh_TW/process/2.Process.rst
+1
-1
Documentation/translations/zh_TW/process/3.Early-stage.rst
+1
-1
Documentation/translations/zh_TW/process/3.Early-stage.rst
+1
-1
Documentation/translations/zh_TW/process/4.Coding.rst
+1
-1
Documentation/translations/zh_TW/process/4.Coding.rst
+1
-1
Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
+1
-1
Documentation/translations/zh_TW/process/7.AdvancedTopics.rst
+1
-1
Documentation/virt/kvm/x86/amd-memory-encryption.rst
+1
-1
Documentation/virt/kvm/x86/amd-memory-encryption.rst
···
57
57
58
58
The main ioctl to access SEV is KVM_MEMORY_ENCRYPT_OP. If the argument
59
59
to KVM_MEMORY_ENCRYPT_OP is NULL, the ioctl returns 0 if SEV is enabled
60
-
and ``ENOTTY` if it is disabled (on some older versions of Linux,
60
+
and ``ENOTTY`` if it is disabled (on some older versions of Linux,
61
61
the ioctl runs normally even with a NULL argument, and therefore will
62
62
likely return ``EFAULT``). If non-NULL, the argument to KVM_MEMORY_ENCRYPT_OP
63
63
must be a struct kvm_sev_cmd::
+2
-78
MAINTAINERS
+2
-78
MAINTAINERS
···
1
-
List of maintainers and how to submit kernel changes
2
-
====================================================
3
-
4
-
Please try to follow the guidelines below. This will make things
5
-
easier on the maintainers. Not all of these guidelines matter for every
6
-
trivial patch so apply some common sense.
7
-
8
-
Tips for patch submitters
9
-
-------------------------
10
-
11
-
1. Always *test* your changes, however small, on at least 4 or
12
-
5 people, preferably many more.
13
-
14
-
2. Try to release a few ALPHA test versions to the net. Announce
15
-
them onto the kernel channel and await results. This is especially
16
-
important for device drivers, because often that's the only way
17
-
you will find things like the fact version 3 firmware needs
18
-
a magic fix you didn't know about, or some clown changed the
19
-
chips on a board and not its name. (Don't laugh! Look at the
20
-
SMC etherpower for that.)
21
-
22
-
3. Make sure your changes compile correctly in multiple
23
-
configurations. In particular check that changes work both as a
24
-
module and built into the kernel.
25
-
26
-
4. When you are happy with a change make it generally available for
27
-
testing and await feedback.
28
-
29
-
5. Make a patch available to the relevant maintainer in the list. Use
30
-
``diff -u`` to make the patch easy to merge. Be prepared to get your
31
-
changes sent back with seemingly silly requests about formatting
32
-
and variable names. These aren't as silly as they seem. One
33
-
job the maintainers (and especially Linus) do is to keep things
34
-
looking the same. Sometimes this means that the clever hack in
35
-
your driver to get around a problem actually needs to become a
36
-
generalized kernel feature ready for next time.
37
-
38
-
PLEASE check your patch with the automated style checker
39
-
(scripts/checkpatch.pl) to catch trivial style violations.
40
-
See Documentation/process/coding-style.rst for guidance here.
41
-
42
-
PLEASE CC: the maintainers and mailing lists that are generated
43
-
by ``scripts/get_maintainer.pl.`` The results returned by the
44
-
script will be best if you have git installed and are making
45
-
your changes in a branch derived from Linus' latest git tree.
46
-
See Documentation/process/submitting-patches.rst for details.
47
-
48
-
PLEASE try to include any credit lines you want added with the
49
-
patch. It avoids people being missed off by mistake and makes
50
-
it easier to know who wants adding and who doesn't.
51
-
52
-
PLEASE document known bugs. If it doesn't work for everything
53
-
or does something very odd once a month document it.
54
-
55
-
PLEASE remember that submissions must be made under the terms
56
-
of the Linux Foundation certificate of contribution and should
57
-
include a Signed-off-by: line. The current version of this
58
-
"Developer's Certificate of Origin" (DCO) is listed in the file
59
-
Documentation/process/submitting-patches.rst.
60
-
61
-
6. Make sure you have the right to send any changes you make. If you
62
-
do changes at work you may find your employer owns the patch
63
-
not you.
64
-
65
-
7. When sending security related changes or reports to a maintainer
66
-
please Cc: security@kernel.org, especially if the maintainer
67
-
does not respond. Please keep in mind that the security team is
68
-
a small set of people who can be efficient only when working on
69
-
verified bugs. Please only Cc: this list when you have identified
70
-
that the bug would present a short-term risk to other users if it
71
-
were publicly disclosed. For example, reports of address leaks do
72
-
not represent an immediate threat and are better handled publicly,
73
-
and ideally, should come with a patch proposal. Please do not send
74
-
automated reports to this list either. Such bugs will be handled
75
-
better and faster in the usual public places. See
76
-
Documentation/process/security-bugs.rst for details.
77
-
78
-
8. Happy hacking.
1
+
List of maintainers
2
+
===================
79
3
80
4
Descriptions of section entries and preferred order
81
5
---------------------------------------------------
+3
scripts/kernel-doc
+3
scripts/kernel-doc
···
1319
1319
my $file = shift;
1320
1320
my $members;
1321
1321
1322
+
# ignore members marked private:
1323
+
$x =~ s/\/\*\s*private:.*?\/\*\s*public:.*?\*\///gosi;
1324
+
$x =~ s/\/\*\s*private:.*}/}/gosi;
1322
1325
1323
1326
$x =~ s@/\*.*?\*/@@gos; # strip comments.
1324
1327
# strip #define macros inside enums
+1
-1
tools/testing/selftests/rcutorture/bin/kvm.sh
+1
-1
tools/testing/selftests/rcutorture/bin/kvm.sh
···
655
655
# Control buffer size: --bootargs trace_buf_size=3k
656
656
# Get trace-buffer dumps on all oopses: --bootargs ftrace_dump_on_oops
657
657
# Ditto, but dump only the oopsing CPU: --bootargs ftrace_dump_on_oops=orig_cpu
658
-
# Heavy-handed way to also dump on warnings: --bootargs panic_on_warn
658
+
# Heavy-handed way to also dump on warnings: --bootargs panic_on_warn=1