€•-      Œsphinx.addnodes”Œdocument”“”)”}”(Œ	rawsource”Œ ”Œchildren”]”(Œtranslations”ŒLanguagesNode”“”)”}”(hhh]”(h Œpending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒChinese (Simplified)”…””}”Œparent”hsbaŒ
attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ	refdomain”Œstd”Œreftype”Œdoc”Œ	reftarget”Œ*/translations/zh_CN/process/maintainer-tip”Œmodname”NŒ	classname”NŒrefexplicit”ˆuŒtagname”hhhubh)”}”(hhh]”hŒChinese (Traditional)”…””}”hh2sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ*/translations/zh_TW/process/maintainer-tip”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒItalian”…””}”hhFsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ*/translations/it_IT/process/maintainer-tip”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒJapanese”…””}”hhZsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ*/translations/ja_JP/process/maintainer-tip”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒKorean”…””}”hhnsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ*/translations/ko_KR/process/maintainer-tip”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒPortuguese (Brazilian)”…””}”hh‚sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ*/translations/pt_BR/process/maintainer-tip”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒSpanish”…””}”hh–sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ*/translations/sp_SP/process/maintainer-tip”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒEnglish”uh1h
hhŒ	_document”hŒsource”NŒline”NubhŒcomment”“”)”}”(hŒ SPDX-License-Identifier: GPL-2.0”h]”hŒ SPDX-License-Identifier: GPL-2.0”…””}”hh·sbah}”(h]”h ]”h"]”h$]”h&]”Œ	xml:space”Œpreserve”uh1hµhhh²hh³ŒD/var/lib/git/docbuild/linux/Documentation/process/maintainer-tip.rst”h´KubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒThe tip tree handbook”h]”hŒThe tip tree handbook”…””}”(hhÏh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhhÊh²hh³hÇh´KubhÉ)”}”(hhh]”(hÎ)”}”(hŒWhat is the tip tree?”h]”hŒWhat is the tip tree?”…””}”(hhàh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhhÝh²hh³hÇh´KubhŒ	paragraph”“”)”}”(hX  The tip tree is a collection of several subsystems and areas of
development. The tip tree is both a direct development tree and an
aggregation tree for several sub-maintainer trees. The tip tree gitweb URL
is: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git”h]”(hŒÒThe tip tree is a collection of several subsystems and areas of
development. The tip tree is both a direct development tree and an
aggregation tree for several sub-maintainer trees. The tip tree gitweb URL
is: ”…””}”(hhðh²hh³Nh´NubhŒ	reference”“”)”}”(hŒ;https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git”h]”hŒ;https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git”…””}”(hhúh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”hüuh1høhhðubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K	hhÝh²hubhï)”}”(hŒ/The tip tree contains the following subsystems:”h]”hŒ/The tip tree contains the following subsystems:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KhhÝh²hubhŒblock_quote”“”)”}”(hX  - **x86 architecture**

  The x86 architecture development takes place in the tip tree except
  for the x86 KVM and XEN specific parts which are maintained in the
  corresponding subsystems and routed directly to mainline from
  there. It's still good practice to Cc the x86 maintainers on
  x86-specific KVM and XEN patches.

  Some x86 subsystems have their own maintainers in addition to the
  overall x86 maintainers.  Please Cc the overall x86 maintainers on
  patches touching files in arch/x86 even when they are not called out
  by the MAINTAINER file.

  Note, that ``x86@kernel.org`` is not a mailing list. It is merely a
  mail alias which distributes mails to the x86 top-level maintainer
  team. Please always Cc the Linux Kernel mailing list (LKML)
  ``linux-kernel@vger.kernel.org``, otherwise your mail ends up only in
  the private inboxes of the maintainers.

- **Scheduler**

  Scheduler development takes place in the -tip tree, in the
  sched/core branch - with occasional sub-topic trees for
  work-in-progress patch-sets.

- **Locking and atomics**

  Locking development (including atomics and other synchronization
  primitives that are connected to locking) takes place in the -tip
  tree, in the locking/core branch - with occasional sub-topic trees
  for work-in-progress patch-sets.

- **Generic interrupt subsystem and interrupt chip drivers**:

  - interrupt core development happens in the irq/core branch

  - interrupt chip driver development also happens in the irq/core
    branch, but the patches are usually applied in a separate maintainer
    tree and then aggregated into irq/core

- **Time, timers, timekeeping, NOHZ and related chip drivers**:

  - timekeeping, clocksource core, NTP and alarmtimer development
    happens in the timers/core branch, but patches are usually applied in
    a separate maintainer tree and then aggregated into timers/core

  - clocksource/event driver development happens in the timers/core
    branch, but patches are mostly applied in a separate maintainer tree
    and then aggregated into timers/core

- **Performance counters core, architecture support and tooling**:

  - perf core and architecture support development happens in the
    perf/core branch

  - perf tooling development happens in the perf tools maintainer
    tree and is aggregated into the tip tree.

- **CPU hotplug core**

- **RAS core**

  Mostly x86-specific RAS patches are collected in the tip ras/core
  branch.

- **EFI core**

  EFI development in the efi git tree. The collected patches are
  aggregated in the tip efi/core branch.

- **RCU**

  RCU development happens in the linux-rcu tree. The resulting changes
  are aggregated into the tip core/rcu branch.

- **Various core code components**:

    - debugobjects

    - objtool

    - random bits and pieces

”h]”hŒbullet_list”“”)”}”(hhh]”(hŒ	list_item”“”)”}”(hXO  **x86 architecture**

The x86 architecture development takes place in the tip tree except
for the x86 KVM and XEN specific parts which are maintained in the
corresponding subsystems and routed directly to mainline from
there. It's still good practice to Cc the x86 maintainers on
x86-specific KVM and XEN patches.

Some x86 subsystems have their own maintainers in addition to the
overall x86 maintainers.  Please Cc the overall x86 maintainers on
patches touching files in arch/x86 even when they are not called out
by the MAINTAINER file.

Note, that ``x86@kernel.org`` is not a mailing list. It is merely a
mail alias which distributes mails to the x86 top-level maintainer
team. Please always Cc the Linux Kernel mailing list (LKML)
``linux-kernel@vger.kernel.org``, otherwise your mail ends up only in
the private inboxes of the maintainers.
”h]”(hï)”}”(hŒ**x86 architecture**”h]”hŒstrong”“”)”}”(hj0  h]”hŒx86 architecture”…””}”(hj4  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hj.  ubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Khj*  ubhï)”}”(hX#  The x86 architecture development takes place in the tip tree except
for the x86 KVM and XEN specific parts which are maintained in the
corresponding subsystems and routed directly to mainline from
there. It's still good practice to Cc the x86 maintainers on
x86-specific KVM and XEN patches.”h]”hX%  The x86 architecture development takes place in the tip tree except
for the x86 KVM and XEN specific parts which are maintained in the
corresponding subsystems and routed directly to mainline from
there. Itâ€™s still good practice to Cc the x86 maintainers on
x86-specific KVM and XEN patches.”…””}”(hjG  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Khj*  ubhï)”}”(hŒáSome x86 subsystems have their own maintainers in addition to the
overall x86 maintainers.  Please Cc the overall x86 maintainers on
patches touching files in arch/x86 even when they are not called out
by the MAINTAINER file.”h]”hŒáSome x86 subsystems have their own maintainers in addition to the
overall x86 maintainers.  Please Cc the overall x86 maintainers on
patches touching files in arch/x86 even when they are not called out
by the MAINTAINER file.”…””}”(hjU  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Khj*  ubhï)”}”(hX0  Note, that ``x86@kernel.org`` is not a mailing list. It is merely a
mail alias which distributes mails to the x86 top-level maintainer
team. Please always Cc the Linux Kernel mailing list (LKML)
``linux-kernel@vger.kernel.org``, otherwise your mail ends up only in
the private inboxes of the maintainers.”h]”(hŒNote, that ”…””}”(hjc  h²hh³Nh´NubhŒliteral”“”)”}”(hŒ``x86@kernel.org``”h]”hŒx86@kernel.org”…””}”(hjm  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjc  ubhŒ¦ is not a mailing list. It is merely a
mail alias which distributes mails to the x86 top-level maintainer
team. Please always Cc the Linux Kernel mailing list (LKML)
”…””}”(hjc  h²hh³Nh´Nubjl  )”}”(hŒ ``linux-kernel@vger.kernel.org``”h]”hŒlinux-kernel@vger.kernel.org”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjc  ubhŒM, otherwise your mail ends up only in
the private inboxes of the maintainers.”…””}”(hjc  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Khj*  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj%  ubj)  )”}”(hŒŸ**Scheduler**

Scheduler development takes place in the -tip tree, in the
sched/core branch - with occasional sub-topic trees for
work-in-progress patch-sets.
”h]”(hï)”}”(hŒ**Scheduler**”h]”j3  )”}”(hj£  h]”hŒ	Scheduler”…””}”(hj¥  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hj¡  ubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K#hj  ubhï)”}”(hŒScheduler development takes place in the -tip tree, in the
sched/core branch - with occasional sub-topic trees for
work-in-progress patch-sets.”h]”hŒScheduler development takes place in the -tip tree, in the
sched/core branch - with occasional sub-topic trees for
work-in-progress patch-sets.”…””}”(hj¸  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K%hj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj%  ubj)  )”}”(hX   **Locking and atomics**

Locking development (including atomics and other synchronization
primitives that are connected to locking) takes place in the -tip
tree, in the locking/core branch - with occasional sub-topic trees
for work-in-progress patch-sets.
”h]”(hï)”}”(hŒ**Locking and atomics**”h]”j3  )”}”(hjÒ  h]”hŒLocking and atomics”…””}”(hjÔ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hjÐ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K)hjÌ  ubhï)”}”(hŒæLocking development (including atomics and other synchronization
primitives that are connected to locking) takes place in the -tip
tree, in the locking/core branch - with occasional sub-topic trees
for work-in-progress patch-sets.”h]”hŒæLocking development (including atomics and other synchronization
primitives that are connected to locking) takes place in the -tip
tree, in the locking/core branch - with occasional sub-topic trees
for work-in-progress patch-sets.”…””}”(hjç  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K+hjÌ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj%  ubj)  )”}”(hX+  **Generic interrupt subsystem and interrupt chip drivers**:

- interrupt core development happens in the irq/core branch

- interrupt chip driver development also happens in the irq/core
  branch, but the patches are usually applied in a separate maintainer
  tree and then aggregated into irq/core
”h]”(hï)”}”(hŒ;**Generic interrupt subsystem and interrupt chip drivers**:”h]”(j3  )”}”(hŒ:**Generic interrupt subsystem and interrupt chip drivers**”h]”hŒ6Generic interrupt subsystem and interrupt chip drivers”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hjÿ  ubhŒ:”…””}”(hjÿ  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K0hjû  ubj$  )”}”(hhh]”(j)  )”}”(hŒ:interrupt core development happens in the irq/core branch
”h]”hï)”}”(hŒ9interrupt core development happens in the irq/core branch”h]”hŒ9interrupt core development happens in the irq/core branch”…””}”(hj"  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K2hj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj  ubj)  )”}”(hŒ«interrupt chip driver development also happens in the irq/core
branch, but the patches are usually applied in a separate maintainer
tree and then aggregated into irq/core
”h]”hï)”}”(hŒªinterrupt chip driver development also happens in the irq/core
branch, but the patches are usually applied in a separate maintainer
tree and then aggregated into irq/core”h]”hŒªinterrupt chip driver development also happens in the irq/core
branch, but the patches are usually applied in a separate maintainer
tree and then aggregated into irq/core”…””}”(hj:  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K4hj6  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ-”uh1j#  h³hÇh´K2hjû  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj%  ubj)  )”}”(hXº  **Time, timers, timekeeping, NOHZ and related chip drivers**:

- timekeeping, clocksource core, NTP and alarmtimer development
  happens in the timers/core branch, but patches are usually applied in
  a separate maintainer tree and then aggregated into timers/core

- clocksource/event driver development happens in the timers/core
  branch, but patches are mostly applied in a separate maintainer tree
  and then aggregated into timers/core
”h]”(hï)”}”(hŒ=**Time, timers, timekeeping, NOHZ and related chip drivers**:”h]”(j3  )”}”(hŒ<**Time, timers, timekeeping, NOHZ and related chip drivers**”h]”hŒ8Time, timers, timekeeping, NOHZ and related chip drivers”…””}”(hjd  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hj`  ubhŒ:”…””}”(hj`  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K8hj\  ubj$  )”}”(hhh]”(j)  )”}”(hŒÄtimekeeping, clocksource core, NTP and alarmtimer development
happens in the timers/core branch, but patches are usually applied in
a separate maintainer tree and then aggregated into timers/core
”h]”hï)”}”(hŒÃtimekeeping, clocksource core, NTP and alarmtimer development
happens in the timers/core branch, but patches are usually applied in
a separate maintainer tree and then aggregated into timers/core”h]”hŒÃtimekeeping, clocksource core, NTP and alarmtimer development
happens in the timers/core branch, but patches are usually applied in
a separate maintainer tree and then aggregated into timers/core”…””}”(hjƒ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K:hj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj|  ubj)  )”}”(hŒªclocksource/event driver development happens in the timers/core
branch, but patches are mostly applied in a separate maintainer tree
and then aggregated into timers/core
”h]”hï)”}”(hŒ©clocksource/event driver development happens in the timers/core
branch, but patches are mostly applied in a separate maintainer tree
and then aggregated into timers/core”h]”hŒ©clocksource/event driver development happens in the timers/core
branch, but patches are mostly applied in a separate maintainer tree
and then aggregated into timers/core”…””}”(hj›  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K>hj—  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj|  ubeh}”(h]”h ]”h"]”h$]”h&]”jT  jU  uh1j#  h³hÇh´K:hj\  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj%  ubj)  )”}”(hX  **Performance counters core, architecture support and tooling**:

- perf core and architecture support development happens in the
  perf/core branch

- perf tooling development happens in the perf tools maintainer
  tree and is aggregated into the tip tree.
”h]”(hï)”}”(hŒ@**Performance counters core, architecture support and tooling**:”h]”(j3  )”}”(hŒ?**Performance counters core, architecture support and tooling**”h]”hŒ;Performance counters core, architecture support and tooling”…””}”(hjÃ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hj¿  ubhŒ:”…””}”(hj¿  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KBhj»  ubj$  )”}”(hhh]”(j)  )”}”(hŒOperf core and architecture support development happens in the
perf/core branch
”h]”hï)”}”(hŒNperf core and architecture support development happens in the
perf/core branch”h]”hŒNperf core and architecture support development happens in the
perf/core branch”…””}”(hjâ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KDhjÞ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjÛ  ubj)  )”}”(hŒhperf tooling development happens in the perf tools maintainer
tree and is aggregated into the tip tree.
”h]”hï)”}”(hŒgperf tooling development happens in the perf tools maintainer
tree and is aggregated into the tip tree.”h]”hŒgperf tooling development happens in the perf tools maintainer
tree and is aggregated into the tip tree.”…””}”(hjú  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KGhjö  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjÛ  ubeh}”(h]”h ]”h"]”h$]”h&]”jT  jU  uh1j#  h³hÇh´KDhj»  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj%  ubj)  )”}”(hŒ**CPU hotplug core**
”h]”hï)”}”(hŒ**CPU hotplug core**”h]”j3  )”}”(hj   h]”hŒCPU hotplug core”…””}”(hj"  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KJhj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj%  ubj)  )”}”(hŒX**RAS core**

Mostly x86-specific RAS patches are collected in the tip ras/core
branch.
”h]”(hï)”}”(hŒ**RAS core**”h]”j3  )”}”(hjA  h]”hŒRAS core”…””}”(hjC  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hj?  ubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KLhj;  ubhï)”}”(hŒIMostly x86-specific RAS patches are collected in the tip ras/core
branch.”h]”hŒIMostly x86-specific RAS patches are collected in the tip ras/core
branch.”…””}”(hjV  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KNhj;  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj%  ubj)  )”}”(hŒt**EFI core**

EFI development in the efi git tree. The collected patches are
aggregated in the tip efi/core branch.
”h]”(hï)”}”(hŒ**EFI core**”h]”j3  )”}”(hjp  h]”hŒEFI core”…””}”(hjr  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hjn  ubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KQhjj  ubhï)”}”(hŒeEFI development in the efi git tree. The collected patches are
aggregated in the tip efi/core branch.”h]”hŒeEFI development in the efi git tree. The collected patches are
aggregated in the tip efi/core branch.”…””}”(hj…  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KShjj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj%  ubj)  )”}”(hŒ{**RCU**

RCU development happens in the linux-rcu tree. The resulting changes
are aggregated into the tip core/rcu branch.
”h]”(hï)”}”(hŒ**RCU**”h]”j3  )”}”(hjŸ  h]”hŒRCU”…””}”(hj¡  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KVhj™  ubhï)”}”(hŒqRCU development happens in the linux-rcu tree. The resulting changes
are aggregated into the tip core/rcu branch.”h]”hŒqRCU development happens in the linux-rcu tree. The resulting changes
are aggregated into the tip core/rcu branch.”…””}”(hj´  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KXhj™  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj%  ubj)  )”}”(hŒ^**Various core code components**:

  - debugobjects

  - objtool

  - random bits and pieces

”h]”(hï)”}”(hŒ!**Various core code components**:”h]”(j3  )”}”(hŒ **Various core code components**”h]”hŒVarious core code components”…””}”(hjÐ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hjÌ  ubhŒ:”…””}”(hjÌ  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K[hjÈ  ubj  )”}”(hŒ5- debugobjects

- objtool

- random bits and pieces

”h]”j$  )”}”(hhh]”(j)  )”}”(hŒdebugobjects
”h]”hï)”}”(hŒdebugobjects”h]”hŒdebugobjects”…””}”(hjó  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K]hjï  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjì  ubj)  )”}”(hŒobjtool
”h]”hï)”}”(hŒobjtool”h]”hŒobjtool”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K_hj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjì  ubj)  )”}”(hŒrandom bits and pieces

”h]”hï)”}”(hŒrandom bits and pieces”h]”hŒrandom bits and pieces”…””}”(hj#  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Kahj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjì  ubeh}”(h]”h ]”h"]”h$]”h&]”jT  jU  uh1j#  h³hÇh´K]hjè  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  h³hÇh´K]hjÈ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj%  ubeh}”(h]”h ]”h"]”h$]”h&]”jT  jU  uh1j#  h³hÇh´Khj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  h³hÇh´KhhÝh²hubeh}”(h]”Œwhat-is-the-tip-tree”ah ]”h"]”Œwhat is the tip tree?”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´KubhÉ)”}”(hhh]”(hÎ)”}”(hŒPatch submission notes”h]”hŒPatch submission notes”…””}”(hj`  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj]  h²hh³hÇh´KeubhÉ)”}”(hhh]”(hÎ)”}”(hŒSelecting the tree/branch”h]”hŒSelecting the tree/branch”…””}”(hjq  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjn  h²hh³hÇh´Khubhï)”}”(hX  In general, development against the head of the tip tree master branch is
fine, but for the subsystems which are maintained separately, have their
own git tree and are only aggregated into the tip tree, development should
take place against the relevant subsystem tree or branch.”h]”hX  In general, development against the head of the tip tree master branch is
fine, but for the subsystems which are maintained separately, have their
own git tree and are only aggregated into the tip tree, development should
take place against the relevant subsystem tree or branch.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Kjhjn  h²hubhï)”}”(hŒÊBug fixes which target mainline should always be applicable against the
mainline kernel tree. Potential conflicts against changes which are already
queued in the tip tree are handled by the maintainers.”h]”hŒÊBug fixes which target mainline should always be applicable against the
mainline kernel tree. Potential conflicts against changes which are already
queued in the tip tree are handled by the maintainers.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Kohjn  h²hubeh}”(h]”Œselecting-the-tree-branch”ah ]”h"]”Œselecting the tree/branch”ah$]”h&]”uh1hÈhj]  h²hh³hÇh´KhubhÉ)”}”(hhh]”(hÎ)”}”(hŒPatch subject”h]”hŒPatch subject”…””}”(hj¦  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj£  h²hh³hÇh´Ktubhï)”}”(hX  The tip tree preferred format for patch subject prefixes is
'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:',
'genirq/core:'. Please do not use file names or complete file paths as
prefix. 'git log path/to/file' should give you a reasonable hint in most
cases.”h]”hX1  The tip tree preferred format for patch subject prefixes is
â€˜subsys/component:â€™, e.g. â€˜x86/apic:â€™, â€˜x86/mm/fault:â€™, â€˜sched/fair:â€™,
â€˜genirq/core:â€™. Please do not use file names or complete file paths as
prefix. â€˜git log path/to/fileâ€™ should give you a reasonable hint in most
cases.”…””}”(hj´  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Kvhj£  h²hubhï)”}”(hŒƒThe condensed patch description in the subject line should start with an
uppercase letter and should be written in imperative tone.”h]”hŒƒThe condensed patch description in the subject line should start with an
uppercase letter and should be written in imperative tone.”…””}”(hjÂ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K|hj£  h²hubeh}”(h]”Œpatch-subject”ah ]”h"]”Œpatch subject”ah$]”h&]”uh1hÈhj]  h²hh³hÇh´KtubhÉ)”}”(hhh]”(hÎ)”}”(hŒ	Changelog”h]”hŒ	Changelog”…””}”(hjÛ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjØ  h²hh³hÇh´Kubhï)”}”(hŒdThe general rules about changelogs in the :ref:`Submitting patches guide
<describe_changes>`, apply.”h]”(hŒ*The general rules about changelogs in the ”…””}”(hjé  h²hh³Nh´Nubh)”}”(hŒ2:ref:`Submitting patches guide
<describe_changes>`”h]”hŒinline”“”)”}”(hjó  h]”hŒSubmitting patches guide”…””}”(hj÷  h²hh³Nh´Nubah}”(h]”h ]”(Œxref”Œstd”Œstd-ref”eh"]”h$]”h&]”uh1jõ  hjñ  ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”Œprocess/maintainer-tip”Œ	refdomain”j  Œreftype”Œref”Œrefexplicit”ˆŒrefwarn”ˆŒ	reftarget”Œdescribe_changes”uh1hh³hÇh´Kƒhjé  ubhŒ, apply.”…””}”(hjé  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KƒhjØ  h²hubhï)”}”(hXZ  The tip tree maintainers set value on following these rules, especially on
the request to write changelogs in imperative mood and not impersonating
code or the execution of it. This is not just a whim of the
maintainers. Changelogs written in abstract words are more precise and
tend to be less confusing than those written in the form of novels.”h]”hXZ  The tip tree maintainers set value on following these rules, especially on
the request to write changelogs in imperative mood and not impersonating
code or the execution of it. This is not just a whim of the
maintainers. Changelogs written in abstract words are more precise and
tend to be less confusing than those written in the form of novels.”…””}”(hj   h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K†hjØ  h²hubhï)”}”(hŒçIt's also useful to structure the changelog into several paragraphs and not
lump everything together into a single one. A good structure is to explain
the context, the problem and the solution in separate paragraphs and this
order.”h]”hŒéItâ€™s also useful to structure the changelog into several paragraphs and not
lump everything together into a single one. A good structure is to explain
the context, the problem and the solution in separate paragraphs and this
order.”…””}”(hj.  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KŒhjØ  h²hubhï)”}”(hŒExamples for illustration:”h]”hŒExamples for illustration:”…””}”(hj<  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K‘hjØ  h²hubj  )”}”(hXY	  Example 1::

  x86/intel_rdt/mbm: Fix MBM overflow handler during hot cpu

  When a CPU is dying, we cancel the worker and schedule a new worker on a
  different CPU on the same domain. But if the timer is already about to
  expire (say 0.99s) then we essentially double the interval.

  We modify the hot cpu handling to cancel the delayed work on the dying
  cpu and run the worker immediately on a different cpu in same domain. We
  do not flush the worker because the MBM overflow worker reschedules the
  worker on same CPU and scans the domain->cpu_mask to get the domain
  pointer.

Improved version::

  x86/intel_rdt/mbm: Fix MBM overflow handler during CPU hotplug

  When a CPU is dying, the overflow worker is canceled and rescheduled on a
  different CPU in the same domain. But if the timer is already about to
  expire this essentially doubles the interval which might result in a non
  detected overflow.

  Cancel the overflow worker and reschedule it immediately on a different CPU
  in the same domain. The work could be flushed as well, but that would
  reschedule it on the same CPU.

Example 2::

  time: POSIX CPU timers: Ensure that variable is initialized

  If cpu_timer_sample_group returns -EINVAL, it will not have written into
  *sample. Checking for cpu_timer_sample_group's return value precludes the
  potential use of an uninitialized value of now in the following block.
  Given an invalid clock_idx, the previous code could otherwise overwrite
  *oldval in an undefined manner. This is now prevented. We also exploit
  short-circuiting of && to sample the timer only if the result will
  actually be used to update *oldval.

Improved version::

  posix-cpu-timers: Make set_process_cpu_timer() more robust

  Because the return value of cpu_timer_sample_group() is not checked,
  compilers and static checkers can legitimately warn about a potential use
  of the uninitialized variable 'now'. This is not a runtime issue as all
  call sites hand in valid clock ids.

  Also cpu_timer_sample_group() is invoked unconditionally even when the
  result is not used because *oldval is NULL.

  Make the invocation conditional and check the return value.

Example 3::

  The entity can also be used for other purposes.

  Let's rename it to be more generic.

Improved version::

  The entity can also be used for other purposes.

  Rename it to be more generic.

”h]”(hï)”}”(hŒExample 1::”h]”hŒ
Example 1:”…””}”(hjN  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K“hjJ  ubhŒliteral_block”“”)”}”(hX-  x86/intel_rdt/mbm: Fix MBM overflow handler during hot cpu

When a CPU is dying, we cancel the worker and schedule a new worker on a
different CPU on the same domain. But if the timer is already about to
expire (say 0.99s) then we essentially double the interval.

We modify the hot cpu handling to cancel the delayed work on the dying
cpu and run the worker immediately on a different cpu in same domain. We
do not flush the worker because the MBM overflow worker reschedules the
worker on same CPU and scans the domain->cpu_mask to get the domain
pointer.”h]”hX-  x86/intel_rdt/mbm: Fix MBM overflow handler during hot cpu

When a CPU is dying, we cancel the worker and schedule a new worker on a
different CPU on the same domain. But if the timer is already about to
expire (say 0.99s) then we essentially double the interval.

We modify the hot cpu handling to cancel the delayed work on the dying
cpu and run the worker immediately on a different cpu in same domain. We
do not flush the worker because the MBM overflow worker reschedules the
worker on same CPU and scans the domain->cpu_mask to get the domain
pointer.”…””}”hj^  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´K•hjJ  ubhï)”}”(hŒImproved version::”h]”hŒImproved version:”…””}”(hjl  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K¡hjJ  ubj]  )”}”(hXÞ  x86/intel_rdt/mbm: Fix MBM overflow handler during CPU hotplug

When a CPU is dying, the overflow worker is canceled and rescheduled on a
different CPU in the same domain. But if the timer is already about to
expire this essentially doubles the interval which might result in a non
detected overflow.

Cancel the overflow worker and reschedule it immediately on a different CPU
in the same domain. The work could be flushed as well, but that would
reschedule it on the same CPU.”h]”hXÞ  x86/intel_rdt/mbm: Fix MBM overflow handler during CPU hotplug

When a CPU is dying, the overflow worker is canceled and rescheduled on a
different CPU in the same domain. But if the timer is already about to
expire this essentially doubles the interval which might result in a non
detected overflow.

Cancel the overflow worker and reschedule it immediately on a different CPU
in the same domain. The work could be flushed as well, but that would
reschedule it on the same CPU.”…””}”hjz  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´K£hjJ  ubhï)”}”(hŒExample 2::”h]”hŒ
Example 2:”…””}”(hjˆ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´K®hjJ  ubj]  )”}”(hX  time: POSIX CPU timers: Ensure that variable is initialized

If cpu_timer_sample_group returns -EINVAL, it will not have written into
*sample. Checking for cpu_timer_sample_group's return value precludes the
potential use of an uninitialized value of now in the following block.
Given an invalid clock_idx, the previous code could otherwise overwrite
*oldval in an undefined manner. This is now prevented. We also exploit
short-circuiting of && to sample the timer only if the result will
actually be used to update *oldval.”h]”hX  time: POSIX CPU timers: Ensure that variable is initialized

If cpu_timer_sample_group returns -EINVAL, it will not have written into
*sample. Checking for cpu_timer_sample_group's return value precludes the
potential use of an uninitialized value of now in the following block.
Given an invalid clock_idx, the previous code could otherwise overwrite
*oldval in an undefined manner. This is now prevented. We also exploit
short-circuiting of && to sample the timer only if the result will
actually be used to update *oldval.”…””}”hj–  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´K°hjJ  ubhï)”}”(hŒImproved version::”h]”hŒImproved version:”…””}”(hj¤  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KºhjJ  ubj]  )”}”(hXç  posix-cpu-timers: Make set_process_cpu_timer() more robust

Because the return value of cpu_timer_sample_group() is not checked,
compilers and static checkers can legitimately warn about a potential use
of the uninitialized variable 'now'. This is not a runtime issue as all
call sites hand in valid clock ids.

Also cpu_timer_sample_group() is invoked unconditionally even when the
result is not used because *oldval is NULL.

Make the invocation conditional and check the return value.”h]”hXç  posix-cpu-timers: Make set_process_cpu_timer() more robust

Because the return value of cpu_timer_sample_group() is not checked,
compilers and static checkers can legitimately warn about a potential use
of the uninitialized variable 'now'. This is not a runtime issue as all
call sites hand in valid clock ids.

Also cpu_timer_sample_group() is invoked unconditionally even when the
result is not used because *oldval is NULL.

Make the invocation conditional and check the return value.”…””}”hj²  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´K¼hjJ  ubhï)”}”(hŒExample 3::”h]”hŒ
Example 3:”…””}”(hjÀ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KÈhjJ  ubj]  )”}”(hŒTThe entity can also be used for other purposes.

Let's rename it to be more generic.”h]”hŒTThe entity can also be used for other purposes.

Let's rename it to be more generic.”…””}”hjÎ  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´KÊhjJ  ubhï)”}”(hŒImproved version::”h]”hŒImproved version:”…””}”(hjÜ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KÎhjJ  ubj]  )”}”(hŒNThe entity can also be used for other purposes.

Rename it to be more generic.”h]”hŒNThe entity can also be used for other purposes.

Rename it to be more generic.”…””}”hjê  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´KÐhjJ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j  h³hÇh´K“hjØ  h²hubhï)”}”(hŒÓFor complex scenarios, especially race conditions and memory ordering
issues, it is valuable to depict the scenario with a table which shows
the parallelism and the temporal order of events. Here is an example::”h]”hŒÒFor complex scenarios, especially race conditions and memory ordering
issues, it is valuable to depict the scenario with a table which shows
the parallelism and the temporal order of events. Here is an example:”…””}”(hjþ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KÕhjØ  h²hubj]  )”}”(hXá  CPU0                            CPU1
free_irq(X)                     interrupt X
                                spin_lock(desc->lock)
                                wake irq thread()
                                spin_unlock(desc->lock)
spin_lock(desc->lock)
remove action()
shutdown_irq()
release_resources()             thread_handler()
spin_unlock(desc->lock)           access released resources.
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^
synchronize_irq()”h]”hXá  CPU0                            CPU1
free_irq(X)                     interrupt X
                                spin_lock(desc->lock)
                                wake irq thread()
                                spin_unlock(desc->lock)
spin_lock(desc->lock)
remove action()
shutdown_irq()
release_resources()             thread_handler()
spin_unlock(desc->lock)           access released resources.
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^
synchronize_irq()”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´KÙhjØ  h²hubhï)”}”(hŒOLockdep provides similar useful output to depict a possible deadlock
scenario::”h]”hŒNLockdep provides similar useful output to depict a possible deadlock
scenario:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´KæhjØ  h²hubj]  )”}”(hXd  CPU0                                    CPU1
rtmutex_lock(&rcu->rt_mutex)
  spin_lock(&rcu->rt_mutex.wait_lock)
                                        local_irq_disable()
                                        spin_lock(&timer->it_lock)
                                        spin_lock(&rcu->mutex.wait_lock)
--> Interrupt
    spin_lock(&timer->it_lock)”h]”hXd  CPU0                                    CPU1
rtmutex_lock(&rcu->rt_mutex)
  spin_lock(&rcu->rt_mutex.wait_lock)
                                        local_irq_disable()
                                        spin_lock(&timer->it_lock)
                                        spin_lock(&rcu->mutex.wait_lock)
--> Interrupt
    spin_lock(&timer->it_lock)”…””}”hj(  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´KéhjØ  h²hubeh}”(h]”Œ	changelog”ah ]”h"]”Œ	changelog”ah$]”h&]”uh1hÈhj]  h²hh³hÇh´KubhÉ)”}”(hhh]”(hÎ)”}”(hŒ!Function references in changelogs”h]”hŒ!Function references in changelogs”…””}”(hjA  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj>  h²hh³hÇh´Kôubhï)”}”(hŒÂWhen a function is mentioned in the changelog, either the text body or the
subject line, please use the format 'function_name()'. Omitting the
brackets after the function name can be ambiguous::”h]”hŒÅWhen a function is mentioned in the changelog, either the text body or the
subject line, please use the format â€˜function_name()â€™. Omitting the
brackets after the function name can be ambiguous:”…””}”(hjO  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Köhj>  h²hubj]  )”}”(hŒ~Subject: subsys/component: Make reservation_count static

reservation_count is only used in reservation_stats. Make it static.”h]”hŒ~Subject: subsys/component: Make reservation_count static

reservation_count is only used in reservation_stats. Make it static.”…””}”hj]  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Kúhj>  h²hubhï)”}”(hŒ+The variant with brackets is more precise::”h]”hŒ*The variant with brackets is more precise:”…””}”(hjk  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Kþhj>  h²hubj]  )”}”(hŒˆSubject: subsys/component: Make reservation_count() static

reservation_count() is only called from reservation_stats(). Make it
static.”h]”hŒˆSubject: subsys/component: Make reservation_count() static

reservation_count() is only called from reservation_stats(). Make it
static.”…””}”hjy  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M hj>  h²hubeh}”(h]”Œ!function-references-in-changelogs”ah ]”h"]”Œ!function references in changelogs”ah$]”h&]”uh1hÈhj]  h²hh³hÇh´KôubhÉ)”}”(hhh]”(hÎ)”}”(hŒBacktraces in changelogs”h]”hŒBacktraces in changelogs”…””}”(hj’  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj  h²hh³hÇh´Mubhï)”}”(hŒSee :ref:`backtraces`.”h]”(hŒSee ”…””}”(hj   h²hh³Nh´Nubh)”}”(hŒ:ref:`backtraces`”h]”jö  )”}”(hjª  h]”hŒ
backtraces”…””}”(hj¬  h²hh³Nh´Nubah}”(h]”h ]”(j  Œstd”Œstd-ref”eh"]”h$]”h&]”uh1jõ  hj¨  ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”j  Œ	refdomain”j¶  Œreftype”Œref”Œrefexplicit”‰Œrefwarn”ˆj  Œ
backtraces”uh1hh³hÇh´M	hj   ubhŒ.”…””}”(hj   h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M	hj  h²hubeh}”(h]”Œbacktraces-in-changelogs”ah ]”h"]”Œbacktraces in changelogs”ah$]”h&]”uh1hÈhj]  h²hh³hÇh´MubhÉ)”}”(hhh]”(hÎ)”}”(hŒOrdering of commit tags”h]”hŒOrdering of commit tags”…””}”(hjÝ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjÚ  h²hh³hÇh´Mubhï)”}”(hŒeTo have a uniform view of the commit tags, the tip maintainers use the
following tag ordering scheme:”h]”hŒeTo have a uniform view of the commit tags, the tip maintainers use the
following tag ordering scheme:”…””}”(hjë  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MhjÚ  h²hubj  )”}”(hXz  - Fixes: 12+char-SHA1 ("sub/sys: Original subject line")

  A Fixes tag should be added even for changes which do not need to be
  backported to stable kernels, i.e. when addressing a recently introduced
  issue which only affects tip or the current head of mainline. These tags
  are helpful to identify the original commit and are much more valuable
  than prominently mentioning the commit which introduced a problem in the
  text of the changelog itself because they can be automatically
  extracted.

  The following example illustrates the difference::

    Commit

      abcdef012345678 ("x86/xxx: Replace foo with bar")

    left an unused instance of variable foo around. Remove it.

    Signed-off-by: J.Dev <j.dev@mail>

  Please say instead::

    The recent replacement of foo with bar left an unused instance of
    variable foo around. Remove it.

    Fixes: abcdef012345678 ("x86/xxx: Replace foo with bar")
    Signed-off-by: J.Dev <j.dev@mail>

  The latter puts the information about the patch into the focus and
  amends it with the reference to the commit which introduced the issue
  rather than putting the focus on the original commit in the first place.

- Reported-by: ``Reporter <reporter@mail>``

- Closes: ``URL or Message-ID of the bug report this is fixing``

- Originally-by: ``Original author <original-author@mail>``

- Suggested-by: ``Suggester <suggester@mail>``

- Co-developed-by: ``Co-author <co-author@mail>``

  Signed-off-by: ``Co-author <co-author@mail>``

  Note, that Co-developed-by and Signed-off-by of the co-author(s) must
  come in pairs.

- Signed-off-by: ``Author <author@mail>``

  The first Signed-off-by (SOB) after the last Co-developed-by/SOB pair is the
  author SOB, i.e. the person flagged as author by git.

- Signed-off-by: ``Patch handler <handler@mail>``

  SOBs after the author SOB are from people handling and transporting
  the patch, but were not involved in development. SOB chains should
  reflect the **real** route a patch took as it was propagated to us,
  with the first SOB entry signalling primary authorship of a single
  author. Acks should be given as Acked-by lines and review approvals
  as Reviewed-by lines.

  If the handler made modifications to the patch or the changelog, then
  this should be mentioned **after** the changelog text and **above**
  all commit tags in the following format::

    ... changelog text ends.

    [ handler: Replaced foo by bar and updated changelog ]

    First-tag: .....

  Note the two empty new lines which separate the changelog text and the
  commit tags from that notice.

  If a patch is sent to the mailing list by a handler then the author has
  to be noted in the first line of the changelog with::

    From: Author <author@mail>

    Changelog text starts here....

  so the authorship is preserved. The 'From:' line has to be followed
  by an empty newline. If that 'From:' line is missing, then the patch
  would be attributed to the person who sent (transported, handled) it.
  The 'From:' line is automatically removed when the patch is applied
  and does not show up in the final git changelog. It merely affects
  the authorship information of the resulting Git commit.

- Tested-by: ``Tester <tester@mail>``

- Reviewed-by: ``Reviewer <reviewer@mail>``

- Acked-by: ``Acker <acker@mail>``

- Cc: ``cc-ed-person <person@mail>``

  If the patch should be backported to stable, then please add a '``Cc:
  stable@vger.kernel.org``' tag, but do not Cc stable when sending your
  mail.

- Link: ``https://link/to/information``

  For referring to an email posted to the kernel mailing lists, please
  use the lore.kernel.org redirector URL::

    Link: https://lore.kernel.org/email-message-id@here

  This URL should be used when referring to relevant mailing list
  topics, related patch sets, or other notable discussion threads.
  A convenient way to associate ``Link:`` trailers with the commit
  message is to use markdown-like bracketed notation, for example::

    A similar approach was attempted before as part of a different
    effort [1], but the initial implementation caused too many
    regressions [2], so it was backed out and reimplemented.

    Link: https://lore.kernel.org/some-msgid@here # [1]
    Link: https://bugzilla.example.org/bug/12345  # [2]

  You can also use ``Link:`` trailers to indicate the origin of the
  patch when applying it to your git tree. In that case, please use the
  dedicated ``patch.msgid.link`` domain instead of ``lore.kernel.org``.
  This practice makes it possible for automated tooling to identify
  which link to use to retrieve the original patch submission. For
  example::

    Link: https://patch.msgid.link/patch-source-message-id@here
”h]”j$  )”}”(hhh]”(j)  )”}”(hXq  Fixes: 12+char-SHA1 ("sub/sys: Original subject line")

A Fixes tag should be added even for changes which do not need to be
backported to stable kernels, i.e. when addressing a recently introduced
issue which only affects tip or the current head of mainline. These tags
are helpful to identify the original commit and are much more valuable
than prominently mentioning the commit which introduced a problem in the
text of the changelog itself because they can be automatically
extracted.

The following example illustrates the difference::

  Commit

    abcdef012345678 ("x86/xxx: Replace foo with bar")

  left an unused instance of variable foo around. Remove it.

  Signed-off-by: J.Dev <j.dev@mail>

Please say instead::

  The recent replacement of foo with bar left an unused instance of
  variable foo around. Remove it.

  Fixes: abcdef012345678 ("x86/xxx: Replace foo with bar")
  Signed-off-by: J.Dev <j.dev@mail>

The latter puts the information about the patch into the focus and
amends it with the reference to the commit which introduced the issue
rather than putting the focus on the original commit in the first place.
”h]”(hï)”}”(hŒ6Fixes: 12+char-SHA1 ("sub/sys: Original subject line")”h]”hŒ:Fixes: 12+char-SHA1 (â€œsub/sys: Original subject lineâ€)”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mhj   ubhï)”}”(hX°  A Fixes tag should be added even for changes which do not need to be
backported to stable kernels, i.e. when addressing a recently introduced
issue which only affects tip or the current head of mainline. These tags
are helpful to identify the original commit and are much more valuable
than prominently mentioning the commit which introduced a problem in the
text of the changelog itself because they can be automatically
extracted.”h]”hX°  A Fixes tag should be added even for changes which do not need to be
backported to stable kernels, i.e. when addressing a recently introduced
issue which only affects tip or the current head of mainline. These tags
are helpful to identify the original commit and are much more valuable
than prominently mentioning the commit which introduced a problem in the
text of the changelog itself because they can be automatically
extracted.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mhj   ubhï)”}”(hŒ2The following example illustrates the difference::”h]”hŒ1The following example illustrates the difference:”…””}”(hj   h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mhj   ubj]  )”}”(hŒšCommit

  abcdef012345678 ("x86/xxx: Replace foo with bar")

left an unused instance of variable foo around. Remove it.

Signed-off-by: J.Dev <j.dev@mail>”h]”hŒšCommit

  abcdef012345678 ("x86/xxx: Replace foo with bar")

left an unused instance of variable foo around. Remove it.

Signed-off-by: J.Dev <j.dev@mail>”…””}”hj.  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Mhj   ubhï)”}”(hŒPlease say instead::”h]”hŒPlease say instead:”…””}”(hj<  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M%hj   ubj]  )”}”(hŒ½The recent replacement of foo with bar left an unused instance of
variable foo around. Remove it.

Fixes: abcdef012345678 ("x86/xxx: Replace foo with bar")
Signed-off-by: J.Dev <j.dev@mail>”h]”hŒ½The recent replacement of foo with bar left an unused instance of
variable foo around. Remove it.

Fixes: abcdef012345678 ("x86/xxx: Replace foo with bar")
Signed-off-by: J.Dev <j.dev@mail>”…””}”hjJ  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M'hj   ubhï)”}”(hŒÑThe latter puts the information about the patch into the focus and
amends it with the reference to the commit which introduced the issue
rather than putting the focus on the original commit in the first place.”h]”hŒÑThe latter puts the information about the patch into the focus and
amends it with the reference to the commit which introduced the issue
rather than putting the focus on the original commit in the first place.”…””}”(hjX  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M-hj   ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjý  ubj)  )”}”(hŒ*Reported-by: ``Reporter <reporter@mail>``
”h]”hï)”}”(hŒ)Reported-by: ``Reporter <reporter@mail>``”h]”(hŒReported-by: ”…””}”(hjp  h²hh³Nh´Nubjl  )”}”(hŒ``Reporter <reporter@mail>``”h]”hŒReporter <reporter@mail>”…””}”(hjx  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjp  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M1hjl  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjý  ubj)  )”}”(hŒ?Closes: ``URL or Message-ID of the bug report this is fixing``
”h]”hï)”}”(hŒ>Closes: ``URL or Message-ID of the bug report this is fixing``”h]”(hŒCloses: ”…””}”(hj–  h²hh³Nh´Nubjl  )”}”(hŒ6``URL or Message-ID of the bug report this is fixing``”h]”hŒ2URL or Message-ID of the bug report this is fixing”…””}”(hjž  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hj–  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M3hj’  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjý  ubj)  )”}”(hŒ:Originally-by: ``Original author <original-author@mail>``
”h]”hï)”}”(hŒ9Originally-by: ``Original author <original-author@mail>``”h]”(hŒOriginally-by: ”…””}”(hj¼  h²hh³Nh´Nubjl  )”}”(hŒ*``Original author <original-author@mail>``”h]”hŒ&Original author <original-author@mail>”…””}”(hjÄ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hj¼  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M5hj¸  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjý  ubj)  )”}”(hŒ-Suggested-by: ``Suggester <suggester@mail>``
”h]”hï)”}”(hŒ,Suggested-by: ``Suggester <suggester@mail>``”h]”(hŒSuggested-by: ”…””}”(hjâ  h²hh³Nh´Nubjl  )”}”(hŒ``Suggester <suggester@mail>``”h]”hŒSuggester <suggester@mail>”…””}”(hjê  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjâ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M7hjÞ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjý  ubj)  )”}”(hŒµCo-developed-by: ``Co-author <co-author@mail>``

Signed-off-by: ``Co-author <co-author@mail>``

Note, that Co-developed-by and Signed-off-by of the co-author(s) must
come in pairs.
”h]”(hï)”}”(hŒ/Co-developed-by: ``Co-author <co-author@mail>``”h]”(hŒCo-developed-by: ”…””}”(hj  h²hh³Nh´Nubjl  )”}”(hŒ``Co-author <co-author@mail>``”h]”hŒCo-author <co-author@mail>”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M9hj  ubhï)”}”(hŒ-Signed-off-by: ``Co-author <co-author@mail>``”h]”(hŒSigned-off-by: ”…””}”(hj$  h²hh³Nh´Nubjl  )”}”(hŒ``Co-author <co-author@mail>``”h]”hŒCo-author <co-author@mail>”…””}”(hj,  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hj$  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M;hj  ubhï)”}”(hŒTNote, that Co-developed-by and Signed-off-by of the co-author(s) must
come in pairs.”h]”hŒTNote, that Co-developed-by and Signed-off-by of the co-author(s) must
come in pairs.”…””}”(hj@  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M=hj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjý  ubj)  )”}”(hŒ¬Signed-off-by: ``Author <author@mail>``

The first Signed-off-by (SOB) after the last Co-developed-by/SOB pair is the
author SOB, i.e. the person flagged as author by git.
”h]”(hï)”}”(hŒ'Signed-off-by: ``Author <author@mail>``”h]”(hŒSigned-off-by: ”…””}”(hjX  h²hh³Nh´Nubjl  )”}”(hŒ``Author <author@mail>``”h]”hŒAuthor <author@mail>”…””}”(hj`  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjX  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M@hjT  ubhï)”}”(hŒ‚The first Signed-off-by (SOB) after the last Co-developed-by/SOB pair is the
author SOB, i.e. the person flagged as author by git.”h]”hŒ‚The first Signed-off-by (SOB) after the last Co-developed-by/SOB pair is the
author SOB, i.e. the person flagged as author by git.”…””}”(hjt  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MBhjT  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjý  ubj)  )”}”(hXl  Signed-off-by: ``Patch handler <handler@mail>``

SOBs after the author SOB are from people handling and transporting
the patch, but were not involved in development. SOB chains should
reflect the **real** route a patch took as it was propagated to us,
with the first SOB entry signalling primary authorship of a single
author. Acks should be given as Acked-by lines and review approvals
as Reviewed-by lines.

If the handler made modifications to the patch or the changelog, then
this should be mentioned **after** the changelog text and **above**
all commit tags in the following format::

  ... changelog text ends.

  [ handler: Replaced foo by bar and updated changelog ]

  First-tag: .....

Note the two empty new lines which separate the changelog text and the
commit tags from that notice.

If a patch is sent to the mailing list by a handler then the author has
to be noted in the first line of the changelog with::

  From: Author <author@mail>

  Changelog text starts here....

so the authorship is preserved. The 'From:' line has to be followed
by an empty newline. If that 'From:' line is missing, then the patch
would be attributed to the person who sent (transported, handled) it.
The 'From:' line is automatically removed when the patch is applied
and does not show up in the final git changelog. It merely affects
the authorship information of the resulting Git commit.
”h]”(hï)”}”(hŒ/Signed-off-by: ``Patch handler <handler@mail>``”h]”(hŒSigned-off-by: ”…””}”(hjŒ  h²hh³Nh´Nubjl  )”}”(hŒ ``Patch handler <handler@mail>``”h]”hŒPatch handler <handler@mail>”…””}”(hj”  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjŒ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MEhjˆ  ubhï)”}”(hXg  SOBs after the author SOB are from people handling and transporting
the patch, but were not involved in development. SOB chains should
reflect the **real** route a patch took as it was propagated to us,
with the first SOB entry signalling primary authorship of a single
author. Acks should be given as Acked-by lines and review approvals
as Reviewed-by lines.”h]”(hŒ“SOBs after the author SOB are from people handling and transporting
the patch, but were not involved in development. SOB chains should
reflect the ”…””}”(hj¨  h²hh³Nh´Nubj3  )”}”(hŒ**real**”h]”hŒreal”…””}”(hj°  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hj¨  ubhŒÌ route a patch took as it was propagated to us,
with the first SOB entry signalling primary authorship of a single
author. Acks should be given as Acked-by lines and review approvals
as Reviewed-by lines.”…””}”(hj¨  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MGhjˆ  ubhï)”}”(hŒ³If the handler made modifications to the patch or the changelog, then
this should be mentioned **after** the changelog text and **above**
all commit tags in the following format::”h]”(hŒ_If the handler made modifications to the patch or the changelog, then
this should be mentioned ”…””}”(hjÈ  h²hh³Nh´Nubj3  )”}”(hŒ	**after**”h]”hŒafter”…””}”(hjÐ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hjÈ  ubhŒ the changelog text and ”…””}”(hjÈ  h²hh³Nh´Nubj3  )”}”(hŒ	**above**”h]”hŒabove”…””}”(hjâ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j2  hjÈ  ubhŒ)
all commit tags in the following format:”…””}”(hjÈ  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MNhjˆ  ubj]  )”}”(hŒb... changelog text ends.

[ handler: Replaced foo by bar and updated changelog ]

First-tag: .....”h]”hŒb... changelog text ends.

[ handler: Replaced foo by bar and updated changelog ]

First-tag: .....”…””}”hjú  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´MRhjˆ  ubhï)”}”(hŒdNote the two empty new lines which separate the changelog text and the
commit tags from that notice.”h]”hŒdNote the two empty new lines which separate the changelog text and the
commit tags from that notice.”…””}”(hj	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MXhjˆ  ubhï)”}”(hŒ}If a patch is sent to the mailing list by a handler then the author has
to be noted in the first line of the changelog with::”h]”hŒ|If a patch is sent to the mailing list by a handler then the author has
to be noted in the first line of the changelog with:”…””}”(hj	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M[hjˆ  ubj]  )”}”(hŒ:From: Author <author@mail>

Changelog text starts here....”h]”hŒ:From: Author <author@mail>

Changelog text starts here....”…””}”hj$	  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M^hjˆ  ubhï)”}”(hX  so the authorship is preserved. The 'From:' line has to be followed
by an empty newline. If that 'From:' line is missing, then the patch
would be attributed to the person who sent (transported, handled) it.
The 'From:' line is automatically removed when the patch is applied
and does not show up in the final git changelog. It merely affects
the authorship information of the resulting Git commit.”h]”hX™  so the authorship is preserved. The â€˜From:â€™ line has to be followed
by an empty newline. If that â€˜From:â€™ line is missing, then the patch
would be attributed to the person who sent (transported, handled) it.
The â€˜From:â€™ line is automatically removed when the patch is applied
and does not show up in the final git changelog. It merely affects
the authorship information of the resulting Git commit.”…””}”(hj2	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mbhjˆ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjý  ubj)  )”}”(hŒ$Tested-by: ``Tester <tester@mail>``
”h]”hï)”}”(hŒ#Tested-by: ``Tester <tester@mail>``”h]”(hŒTested-by: ”…””}”(hjJ	  h²hh³Nh´Nubjl  )”}”(hŒ``Tester <tester@mail>``”h]”hŒTester <tester@mail>”…””}”(hjR	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjJ	  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MihjF	  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjý  ubj)  )”}”(hŒ*Reviewed-by: ``Reviewer <reviewer@mail>``
”h]”hï)”}”(hŒ)Reviewed-by: ``Reviewer <reviewer@mail>``”h]”(hŒReviewed-by: ”…””}”(hjp	  h²hh³Nh´Nubjl  )”}”(hŒ``Reviewer <reviewer@mail>``”h]”hŒReviewer <reviewer@mail>”…””}”(hjx	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjp	  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mkhjl	  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjý  ubj)  )”}”(hŒ!Acked-by: ``Acker <acker@mail>``
”h]”hï)”}”(hŒ Acked-by: ``Acker <acker@mail>``”h]”(hŒ
Acked-by: ”…””}”(hj–	  h²hh³Nh´Nubjl  )”}”(hŒ``Acker <acker@mail>``”h]”hŒAcker <acker@mail>”…””}”(hjž	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hj–	  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mmhj’	  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjý  ubj)  )”}”(hŒ¶Cc: ``cc-ed-person <person@mail>``

If the patch should be backported to stable, then please add a '``Cc:
stable@vger.kernel.org``' tag, but do not Cc stable when sending your
mail.
”h]”(hï)”}”(hŒ"Cc: ``cc-ed-person <person@mail>``”h]”(hŒCc: ”…””}”(hj¼	  h²hh³Nh´Nubjl  )”}”(hŒ``cc-ed-person <person@mail>``”h]”hŒcc-ed-person <person@mail>”…””}”(hjÄ	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hj¼	  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mohj¸	  ubhï)”}”(hŒ‘If the patch should be backported to stable, then please add a '``Cc:
stable@vger.kernel.org``' tag, but do not Cc stable when sending your
mail.”h]”(hŒBIf the patch should be backported to stable, then please add a â€˜”…””}”(hjØ	  h²hh³Nh´Nubjl  )”}”(hŒ``Cc:
stable@vger.kernel.org``”h]”hŒCc:
stable@vger.kernel.org”…””}”(hjà	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjØ	  ubhŒ5â€™ tag, but do not Cc stable when sending your
mail.”…””}”(hjØ	  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mqhj¸	  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjý  ubj)  )”}”(hX“  Link: ``https://link/to/information``

For referring to an email posted to the kernel mailing lists, please
use the lore.kernel.org redirector URL::

  Link: https://lore.kernel.org/email-message-id@here

This URL should be used when referring to relevant mailing list
topics, related patch sets, or other notable discussion threads.
A convenient way to associate ``Link:`` trailers with the commit
message is to use markdown-like bracketed notation, for example::

  A similar approach was attempted before as part of a different
  effort [1], but the initial implementation caused too many
  regressions [2], so it was backed out and reimplemented.

  Link: https://lore.kernel.org/some-msgid@here # [1]
  Link: https://bugzilla.example.org/bug/12345  # [2]

You can also use ``Link:`` trailers to indicate the origin of the
patch when applying it to your git tree. In that case, please use the
dedicated ``patch.msgid.link`` domain instead of ``lore.kernel.org``.
This practice makes it possible for automated tooling to identify
which link to use to retrieve the original patch submission. For
example::

  Link: https://patch.msgid.link/patch-source-message-id@here
”h]”(hï)”}”(hŒ%Link: ``https://link/to/information``”h]”(hŒLink: ”…””}”(hj
  h²hh³Nh´Nubjl  )”}”(hŒ``https://link/to/information``”h]”hŒhttps://link/to/information”…””}”(hj

  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hj
  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Muhjþ	  ubhï)”}”(hŒmFor referring to an email posted to the kernel mailing lists, please
use the lore.kernel.org redirector URL::”h]”hŒlFor referring to an email posted to the kernel mailing lists, please
use the lore.kernel.org redirector URL:”…””}”(hj
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mwhjþ	  ubj]  )”}”(hŒ3Link: https://lore.kernel.org/email-message-id@here”h]”hŒ3Link: https://lore.kernel.org/email-message-id@here”…””}”hj,
  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Mzhjþ	  ubhï)”}”(hX  This URL should be used when referring to relevant mailing list
topics, related patch sets, or other notable discussion threads.
A convenient way to associate ``Link:`` trailers with the commit
message is to use markdown-like bracketed notation, for example::”h]”(hŒŸThis URL should be used when referring to relevant mailing list
topics, related patch sets, or other notable discussion threads.
A convenient way to associate ”…””}”(hj:
  h²hh³Nh´Nubjl  )”}”(hŒ	``Link:``”h]”hŒLink:”…””}”(hjB
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hj:
  ubhŒZ trailers with the commit
message is to use markdown-like bracketed notation, for example:”…””}”(hj:
  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M|hjþ	  ubj]  )”}”(hX  A similar approach was attempted before as part of a different
effort [1], but the initial implementation caused too many
regressions [2], so it was backed out and reimplemented.

Link: https://lore.kernel.org/some-msgid@here # [1]
Link: https://bugzilla.example.org/bug/12345  # [2]”h]”hX  A similar approach was attempted before as part of a different
effort [1], but the initial implementation caused too many
regressions [2], so it was backed out and reimplemented.

Link: https://lore.kernel.org/some-msgid@here # [1]
Link: https://bugzilla.example.org/bug/12345  # [2]”…””}”hjZ
  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Mhjþ	  ubhï)”}”(hXZ  You can also use ``Link:`` trailers to indicate the origin of the
patch when applying it to your git tree. In that case, please use the
dedicated ``patch.msgid.link`` domain instead of ``lore.kernel.org``.
This practice makes it possible for automated tooling to identify
which link to use to retrieve the original patch submission. For
example::”h]”(hŒYou can also use ”…””}”(hjh
  h²hh³Nh´Nubjl  )”}”(hŒ	``Link:``”h]”hŒLink:”…””}”(hjp
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjh
  ubhŒx trailers to indicate the origin of the
patch when applying it to your git tree. In that case, please use the
dedicated ”…””}”(hjh
  h²hh³Nh´Nubjl  )”}”(hŒ``patch.msgid.link``”h]”hŒpatch.msgid.link”…””}”(hj‚
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjh
  ubhŒ domain instead of ”…””}”(hjh
  h²hh³Nh´Nubjl  )”}”(hŒ``lore.kernel.org``”h]”hŒlore.kernel.org”…””}”(hj”
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjh
  ubhŒ.
This practice makes it possible for automated tooling to identify
which link to use to retrieve the original patch submission. For
example:”…””}”(hjh
  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mˆhjþ	  ubj]  )”}”(hŒ;Link: https://patch.msgid.link/patch-source-message-id@here”h]”hŒ;Link: https://patch.msgid.link/patch-source-message-id@here”…””}”hj¬
  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Mhjþ	  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j(  hjý  ubeh}”(h]”h ]”h"]”h$]”h&]”jT  jU  uh1j#  h³hÇh´Mhjù  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  h³hÇh´MhjÚ  h²hubhï)”}”(hŒwPlease do not use combined tags, e.g. ``Reported-and-tested-by``, as
they just complicate automated extraction of tags.”•>·      h]”(hŒ&Please do not use combined tags, e.g. ”…””}”(hjÌ
  h²hh³Nh´Nubjl  )”}”(hŒ``Reported-and-tested-by``”h]”hŒReported-and-tested-by”…””}”(hjÔ
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjÌ
  ubhŒ7, as
they just complicate automated extraction of tags.”…””}”(hjÌ
  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M‘hjÚ  h²hubeh}”(h]”Œordering-of-commit-tags”ah ]”h"]”Œordering of commit tags”ah$]”h&]”uh1hÈhj]  h²hh³hÇh´MubhÉ)”}”(hhh]”(hÎ)”}”(hŒLinks to documentation”h]”hŒLinks to documentation”…””}”(hj÷
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjô
  h²hh³hÇh´M–ubhï)”}”(hX  Providing links to documentation in the changelog is a great help to later
debugging and analysis.  Unfortunately, URLs often break very quickly
because companies restructure their websites frequently.  Non-'volatile'
exceptions include the Intel SDM and the AMD APM.”h]”hX  Providing links to documentation in the changelog is a great help to later
debugging and analysis.  Unfortunately, URLs often break very quickly
because companies restructure their websites frequently.  Non-â€˜volatileâ€™
exceptions include the Intel SDM and the AMD APM.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M˜hjô
  h²hubhï)”}”(hŒëTherefore, for 'volatile' documents, please create an entry in the kernel
bugzilla https://bugzilla.kernel.org and attach a copy of these documents
to the bugzilla entry. Finally, provide the URL of the bugzilla entry in
the changelog.”h]”(hŒWTherefore, for â€˜volatileâ€™ documents, please create an entry in the kernel
bugzilla ”…””}”(hj  h²hh³Nh´Nubhù)”}”(hŒhttps://bugzilla.kernel.org”h]”hŒhttps://bugzilla.kernel.org”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”j  uh1høhj  ubhŒ} and attach a copy of these documents
to the bugzilla entry. Finally, provide the URL of the bugzilla entry in
the changelog.”…””}”(hj  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mhjô
  h²hubeh}”(h]”Œlinks-to-documentation”ah ]”h"]”Œlinks to documentation”ah$]”h&]”uh1hÈhj]  h²hh³hÇh´M–ubhÉ)”}”(hhh]”(hÎ)”}”(hŒPatch resend or reminders”h]”hŒPatch resend or reminders”…””}”(hj?  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj<  h²hh³hÇh´M£ubhï)”}”(hŒSee :ref:`resend_reminders`.”h]”(hŒSee ”…””}”(hjM  h²hh³Nh´Nubh)”}”(hŒ:ref:`resend_reminders`”h]”jö  )”}”(hjW  h]”hŒresend_reminders”…””}”(hjY  h²hh³Nh´Nubah}”(h]”h ]”(j  Œstd”Œstd-ref”eh"]”h$]”h&]”uh1jõ  hjU  ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”j  Œ	refdomain”jc  Œreftype”Œref”Œrefexplicit”‰Œrefwarn”ˆj  Œresend_reminders”uh1hh³hÇh´M¥hjM  ubhŒ.”…””}”(hjM  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M¥hj<  h²hubeh}”(h]”Œpatch-resend-or-reminders”ah ]”h"]”Œpatch resend or reminders”ah$]”h&]”uh1hÈhj]  h²hh³hÇh´M£ubhÉ)”}”(hhh]”(hÎ)”}”(hŒMerge window”h]”hŒMerge window”…””}”(hjŠ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj‡  h²hh³hÇh´M¨ubhï)”}”(hŒþPlease do not expect patches to be reviewed or merged by tip
maintainers around or during the merge window.  The trees are closed
to all but urgent fixes during this time.  They reopen once the merge
window closes and a new -rc1 kernel has been released.”h]”hŒþPlease do not expect patches to be reviewed or merged by tip
maintainers around or during the merge window.  The trees are closed
to all but urgent fixes during this time.  They reopen once the merge
window closes and a new -rc1 kernel has been released.”…””}”(hj˜  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mªhj‡  h²hubhï)”}”(hŒþLarge series should be submitted in mergeable state *at* *least* a week
before the merge window opens.  Exceptions are made for bug fixes and
*sometimes* for small standalone drivers for new hardware or minimally
invasive patches for hardware enablement.”h]”(hŒ4Large series should be submitted in mergeable state ”…””}”(hj¦  h²hh³Nh´NubhŒemphasis”“”)”}”(hŒ*at*”h]”hŒat”…””}”(hj°  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j®  hj¦  ubhŒ ”…””}”(hj¦  h²hh³Nh´Nubj¯  )”}”(hŒ*least*”h]”hŒleast”…””}”(hjÂ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j®  hj¦  ubhŒN a week
before the merge window opens.  Exceptions are made for bug fixes and
”…””}”(hj¦  h²hh³Nh´Nubj¯  )”}”(hŒ*sometimes*”h]”hŒ	sometimes”…””}”(hjÔ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j®  hj¦  ubhŒe for small standalone drivers for new hardware or minimally
invasive patches for hardware enablement.”…””}”(hj¦  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M¯hj‡  h²hubhï)”}”(hŒÃDuring the merge window, the maintainers instead focus on following the
upstream changes, fixing merge window fallout, collecting bug fixes, and
allowing themselves a breath. Please respect that.”h]”hŒÃDuring the merge window, the maintainers instead focus on following the
upstream changes, fixing merge window fallout, collecting bug fixes, and
allowing themselves a breath. Please respect that.”…””}”(hjì  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M´hj‡  h²hubhï)”}”(hŒhSo called _urgent_ branches will be merged into mainline during the
stabilization phase of each release.”h]”hŒhSo called _urgent_ branches will be merged into mainline during the
stabilization phase of each release.”…””}”(hjú  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M¸hj‡  h²hubeh}”(h]”Œmerge-window”ah ]”h"]”Œmerge window”ah$]”h&]”uh1hÈhj]  h²hh³hÇh´M¨ubhÉ)”}”(hhh]”(hÎ)”}”(hŒGit”h]”hŒGit”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj  h²hh³hÇh´M½ubhï)”}”(hŒ|The tip maintainers accept git pull requests from maintainers who provide
subsystem changes for aggregation in the tip tree.”h]”hŒ|The tip maintainers accept git pull requests from maintainers who provide
subsystem changes for aggregation in the tip tree.”…””}”(hj!  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M¿hj  h²hubhï)”}”(hŒÅPull requests for new patch submissions are usually not accepted and do not
replace proper patch submission to the mailing list. The main reason for
this is that the review workflow is email based.”h]”hŒÅPull requests for new patch submissions are usually not accepted and do not
replace proper patch submission to the mailing list. The main reason for
this is that the review workflow is email based.”…””}”(hj/  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MÂhj  h²hubhï)”}”(hŒùIf you submit a larger patch series it is helpful to provide a git branch
in a private repository which allows interested people to easily pull the
series for testing. The usual way to offer this is a git URL in the cover
letter of the patch series.”h]”hŒùIf you submit a larger patch series it is helpful to provide a git branch
in a private repository which allows interested people to easily pull the
series for testing. The usual way to offer this is a git URL in the cover
letter of the patch series.”…””}”(hj=  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MÆhj  h²hubeh}”(h]”Œgit”ah ]”h"]”Œgit”ah$]”h&]”uh1hÈhj]  h²hh³hÇh´M½ubhÉ)”}”(hhh]”(hÎ)”}”(hŒTesting”h]”hŒTesting”…””}”(hjV  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjS  h²hh³hÇh´MÌubhï)”}”(hŒÌCode should be tested before submitting to the tip maintainers.  Anything
other than minor changes should be built, booted and tested with
comprehensive (and heavyweight) kernel debugging options enabled.”h]”hŒÌCode should be tested before submitting to the tip maintainers.  Anything
other than minor changes should be built, booted and tested with
comprehensive (and heavyweight) kernel debugging options enabled.”…””}”(hjd  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MÎhjS  h²hubhï)”}”(hŒThese debugging options can be found in kernel/configs/x86_debug.config
and can be added to an existing kernel config by running:”h]”hŒThese debugging options can be found in kernel/configs/x86_debug.config
and can be added to an existing kernel config by running:”…””}”(hjr  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MÒhjS  h²hubj  )”}”(hŒmake x86_debug.config
”h]”hï)”}”(hŒmake x86_debug.config”h]”hŒmake x86_debug.config”…””}”(hj„  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MÕhj€  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  h³hÇh´MÕhjS  h²hubhï)”}”(hŒ_Some of these options are x86-specific and can be left out when testing
on other architectures.”h]”hŒ_Some of these options are x86-specific and can be left out when testing
on other architectures.”…””}”(hj˜  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M×hjS  h²hubhŒtarget”“”)”}”(hŒ .. _maintainer-tip-coding-style:”h]”h}”(h]”h ]”h"]”h$]”h&]”Œrefid”Œmaintainer-tip-coding-style”uh1j¦  h´MÚhjS  h²hh³hÇubeh}”(h]”Œtesting”ah ]”h"]”Œtesting”ah$]”h&]”uh1hÈhj]  h²hh³hÇh´MÌubeh}”(h]”Œpatch-submission-notes”ah ]”h"]”Œpatch submission notes”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´KeubhÉ)”}”(hhh]”(hÎ)”}”(hŒCoding style notes”h]”hŒCoding style notes”…””}”(hjÇ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjÄ  h²hh³hÇh´MÝubhÉ)”}”(hhh]”(hÎ)”}”(hŒComment style”h]”hŒComment style”…””}”(hjØ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjÕ  h²hh³hÇh´Màubhï)”}”(hŒ5Sentences in comments start with an uppercase letter.”h]”hŒ5Sentences in comments start with an uppercase letter.”…””}”(hjæ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MâhjÕ  h²hubhï)”}”(hŒSingle line comments::”h]”hŒSingle line comments:”…””}”(hjô  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MähjÕ  h²hubj]  )”}”(hŒ#/* This is a single line comment */”h]”hŒ#/* This is a single line comment */”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´MæhjÕ  h²hubhï)”}”(hŒMulti-line comments::”h]”hŒMulti-line comments:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MèhjÕ  h²hubj]  )”}”(hŒ/*
 * This is a properly formatted
 * multi-line comment.
 *
 * Larger multi-line comments should be split into paragraphs.
 */”h]”hŒ/*
 * This is a properly formatted
 * multi-line comment.
 *
 * Larger multi-line comments should be split into paragraphs.
 */”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´MêhjÕ  h²hubhï)”}”(hŒNo tail comments (see below):”h]”hŒNo tail comments (see below):”…””}”(hj,  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MñhjÕ  h²hubj  )”}”(hXú  Please refrain from using tail comments. Tail comments disturb the
reading flow in almost all contexts, but especially in code::

      if (somecondition_is_true) /* Don't put a comment here */
              dostuff(); /* Neither here */

      seed = MAGIC_CONSTANT; /* Nor here */

Use freestanding comments instead::

      /* This condition is not obvious without a comment */
      if (somecondition_is_true) {
              /* This really needs to be documented */
              dostuff();
      }

      /* This magic initialization needs a comment. Maybe not? */
      seed = MAGIC_CONSTANT;

Use C++ style, tail comments when documenting structs in headers to
achieve a more compact layout and better readability::

      // eax
      u32     x2apic_shift    :  5, // Number of bits to shift APIC ID right
                                    // for the topology ID at the next level
                              : 27; // Reserved
      // ebx
      u32     num_processors  : 16, // Number of processors at current level
                              : 16; // Reserved

versus::

      /* eax */
              /*
               * Number of bits to shift APIC ID right for the topology ID
               * at the next level
               */
       u32     x2apic_shift    :  5,
               /* Reserved */
                               : 27;

      /* ebx */
              /* Number of processors at current level */
      u32     num_processors  : 16,
              /* Reserved */
                              : 16;
”h]”(hï)”}”(hŒ€Please refrain from using tail comments. Tail comments disturb the
reading flow in almost all contexts, but especially in code::”h]”hŒPlease refrain from using tail comments. Tail comments disturb the
reading flow in almost all contexts, but especially in code:”…””}”(hj>  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Móhj:  ubj]  )”}”(hŒ†if (somecondition_is_true) /* Don't put a comment here */
        dostuff(); /* Neither here */

seed = MAGIC_CONSTANT; /* Nor here */”h]”hŒ†if (somecondition_is_true) /* Don't put a comment here */
        dostuff(); /* Neither here */

seed = MAGIC_CONSTANT; /* Nor here */”…””}”hjL  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Möhj:  ubhï)”}”(hŒ#Use freestanding comments instead::”h]”hŒ"Use freestanding comments instead:”…””}”(hjZ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mûhj:  ubj]  )”}”(hŒì/* This condition is not obvious without a comment */
if (somecondition_is_true) {
        /* This really needs to be documented */
        dostuff();
}

/* This magic initialization needs a comment. Maybe not? */
seed = MAGIC_CONSTANT;”h]”hŒì/* This condition is not obvious without a comment */
if (somecondition_is_true) {
        /* This really needs to be documented */
        dostuff();
}

/* This magic initialization needs a comment. Maybe not? */
seed = MAGIC_CONSTANT;”…””}”hjh  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Mýhj:  ubhï)”}”(hŒzUse C++ style, tail comments when documenting structs in headers to
achieve a more compact layout and better readability::”h]”hŒyUse C++ style, tail comments when documenting structs in headers to
achieve a more compact layout and better readability:”…””}”(hjv  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mhj:  ubj]  )”}”(hX6  // eax
u32     x2apic_shift    :  5, // Number of bits to shift APIC ID right
                              // for the topology ID at the next level
                        : 27; // Reserved
// ebx
u32     num_processors  : 16, // Number of processors at current level
                        : 16; // Reserved”h]”hX6  // eax
u32     x2apic_shift    :  5, // Number of bits to shift APIC ID right
                              // for the topology ID at the next level
                        : 27; // Reserved
// ebx
u32     num_processors  : 16, // Number of processors at current level
                        : 16; // Reserved”…””}”hj„  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M	hj:  ubhï)”}”(hŒversus::”h]”hŒversus:”…””}”(hj’  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mhj:  ubj]  )”}”(hXj  /* eax */
        /*
         * Number of bits to shift APIC ID right for the topology ID
         * at the next level
         */
 u32     x2apic_shift    :  5,
         /* Reserved */
                         : 27;

/* ebx */
        /* Number of processors at current level */
u32     num_processors  : 16,
        /* Reserved */
                        : 16;”h]”hXj  /* eax */
        /*
         * Number of bits to shift APIC ID right for the topology ID
         * at the next level
         */
 u32     x2apic_shift    :  5,
         /* Reserved */
                         : 27;

/* ebx */
        /* Number of processors at current level */
u32     num_processors  : 16,
        /* Reserved */
                        : 16;”…””}”hj   sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Mhj:  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j  h³hÇh´MóhjÕ  h²hubhï)”}”(hŒComment the important things:”h]”hŒComment the important things:”…””}”(hj´  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M"hjÕ  h²hubj  )”}”(hX+  Comments should be added where the operation is not obvious. Documenting
the obvious is just a distraction::

      /* Decrement refcount and check for zero */
      if (refcount_dec_and_test(&p->refcnt)) {
              do;
              lots;
              of;
              magic;
              things;
      }

Instead, comments should explain the non-obvious details and document
constraints::

      if (refcount_dec_and_test(&p->refcnt)) {
              /*
               * Really good explanation why the magic things below
               * need to be done, ordering and locking constraints,
               * etc..
               */
              do;
              lots;
              of;
              magic;
              /* Needs to be the last operation because ... */
              things;
      }
”h]”(hï)”}”(hŒlComments should be added where the operation is not obvious. Documenting
the obvious is just a distraction::”h]”hŒkComments should be added where the operation is not obvious. Documenting
the obvious is just a distraction:”…””}”(hjÆ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M$hjÂ  ubj]  )”}”(hŒ›/* Decrement refcount and check for zero */
if (refcount_dec_and_test(&p->refcnt)) {
        do;
        lots;
        of;
        magic;
        things;
}”h]”hŒ›/* Decrement refcount and check for zero */
if (refcount_dec_and_test(&p->refcnt)) {
        do;
        lots;
        of;
        magic;
        things;
}”…””}”hjÔ  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M'hjÂ  ubhï)”}”(hŒSInstead, comments should explain the non-obvious details and document
constraints::”h]”hŒRInstead, comments should explain the non-obvious details and document
constraints:”…””}”(hjâ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M0hjÂ  ubj]  )”}”(hXL  if (refcount_dec_and_test(&p->refcnt)) {
        /*
         * Really good explanation why the magic things below
         * need to be done, ordering and locking constraints,
         * etc..
         */
        do;
        lots;
        of;
        magic;
        /* Needs to be the last operation because ... */
        things;
}”h]”hXL  if (refcount_dec_and_test(&p->refcnt)) {
        /*
         * Really good explanation why the magic things below
         * need to be done, ordering and locking constraints,
         * etc..
         */
        do;
        lots;
        of;
        magic;
        /* Needs to be the last operation because ... */
        things;
}”…””}”hjð  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M3hjÂ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j  h³hÇh´M$hjÕ  h²hubhï)”}”(hŒ Function documentation comments:”h]”hŒ Function documentation comments:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MAhjÕ  h²hubj  )”}”(hXC  To document functions and their arguments please use kernel-doc format
and not free form comments::

      /**
       * magic_function - Do lots of magic stuff
       * @magic:      Pointer to the magic data to operate on
       * @offset:     Offset in the data array of @magic
       *
       * Deep explanation of mysterious things done with @magic along
       * with documentation of the return values.
       *
       * Note, that the argument descriptors above are arranged
       * in a tabular fashion.
       */

This applies especially to globally visible functions and inline
functions in public header files. It might be overkill to use kernel-doc
format for every (static) function which needs a tiny explanation. The
usage of descriptive function names often replaces these tiny comments.
Apply common sense as always.

”h]”(hï)”}”(hŒcTo document functions and their arguments please use kernel-doc format
and not free form comments::”h]”hŒbTo document functions and their arguments please use kernel-doc format
and not free form comments:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MChj  ubj]  )”}”(hXb  /**
 * magic_function - Do lots of magic stuff
 * @magic:      Pointer to the magic data to operate on
 * @offset:     Offset in the data array of @magic
 *
 * Deep explanation of mysterious things done with @magic along
 * with documentation of the return values.
 *
 * Note, that the argument descriptors above are arranged
 * in a tabular fashion.
 */”h]”hXb  /**
 * magic_function - Do lots of magic stuff
 * @magic:      Pointer to the magic data to operate on
 * @offset:     Offset in the data array of @magic
 *
 * Deep explanation of mysterious things done with @magic along
 * with documentation of the return values.
 *
 * Note, that the argument descriptors above are arranged
 * in a tabular fashion.
 */”…””}”hj$  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´MFhj  ubhï)”}”(hX6  This applies especially to globally visible functions and inline
functions in public header files. It might be overkill to use kernel-doc
format for every (static) function which needs a tiny explanation. The
usage of descriptive function names often replaces these tiny comments.
Apply common sense as always.”h]”hX6  This applies especially to globally visible functions and inline
functions in public header files. It might be overkill to use kernel-doc
format for every (static) function which needs a tiny explanation. The
usage of descriptive function names often replaces these tiny comments.
Apply common sense as always.”…””}”(hj2  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MRhj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j  h³hÇh´MChjÕ  h²hubeh}”(h]”Œcomment-style”ah ]”h"]”Œcomment style”ah$]”h&]”uh1hÈhjÄ  h²hh³hÇh´MàubhÉ)”}”(hhh]”(hÎ)”}”(hŒ Documenting locking requirements”h]”hŒ Documenting locking requirements”…””}”(hjQ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjN  h²hh³hÇh´MZubj  )”}”(hXä  Documenting locking requirements is a good thing, but comments are not
necessarily the best choice. Instead of writing::

      /* Caller must hold foo->lock */
      void func(struct foo *foo)
      {
              ...
      }

Please use::

      void func(struct foo *foo)
      {
              lockdep_assert_held(&foo->lock);
              ...
      }

In PROVE_LOCKING kernels, lockdep_assert_held() emits a warning
if the caller doesn't hold the lock.  Comments can't do that.
”h]”(hï)”}”(hŒxDocumenting locking requirements is a good thing, but comments are not
necessarily the best choice. Instead of writing::”h]”hŒwDocumenting locking requirements is a good thing, but comments are not
necessarily the best choice. Instead of writing:”…””}”(hjc  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M[hj_  ubj]  )”}”(hŒK/* Caller must hold foo->lock */
void func(struct foo *foo)
{
        ...
}”h]”hŒK/* Caller must hold foo->lock */
void func(struct foo *foo)
{
        ...
}”…””}”hjq  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M^hj_  ubhï)”}”(hŒPlease use::”h]”hŒPlease use:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mdhj_  ubj]  )”}”(hŒSvoid func(struct foo *foo)
{
        lockdep_assert_held(&foo->lock);
        ...
}”h]”hŒSvoid func(struct foo *foo)
{
        lockdep_assert_held(&foo->lock);
        ...
}”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Mfhj_  ubhï)”}”(hŒ}In PROVE_LOCKING kernels, lockdep_assert_held() emits a warning
if the caller doesn't hold the lock.  Comments can't do that.”h]”hŒIn PROVE_LOCKING kernels, lockdep_assert_held() emits a warning
if the caller doesnâ€™t hold the lock.  Comments canâ€™t do that.”…””}”(hj›  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mlhj_  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j  h³hÇh´M[hjN  h²hubeh}”(h]”Œ documenting-locking-requirements”ah ]”h"]”Œ documenting locking requirements”ah$]”h&]”uh1hÈhjÄ  h²hh³hÇh´MZubhÉ)”}”(hhh]”(hÎ)”}”(hŒBracket rules”h]”hŒBracket rules”…””}”(hjº  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj·  h²hh³hÇh´Mpubhï)”}”(hŒqBrackets should be omitted only if the statement which follows 'if', 'for',
'while' etc. is truly a single line::”h]”hŒ|Brackets should be omitted only if the statement which follows â€˜ifâ€™, â€˜forâ€™,
â€˜whileâ€™ etc. is truly a single line:”…””}”(hjÈ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mrhj·  h²hubj]  )”}”(hŒ if (foo)
        do_something();”h]”hŒ if (foo)
        do_something();”…””}”hjÖ  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Muhj·  h²hubhï)”}”(hŒgThe following is not considered to be a single line statement even
though C does not require brackets::”h]”hŒfThe following is not considered to be a single line statement even
though C does not require brackets:”…””}”(hjä  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mxhj·  h²hubj]  )”}”(hŒSfor (i = 0; i < end; i++)
        if (foo[i])
                do_something(foo[i]);”h]”hŒSfor (i = 0; i < end; i++)
        if (foo[i])
                do_something(foo[i]);”…””}”hjò  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M{hj·  h²hubhï)”}”(hŒAAdding brackets around the outer loop enhances the reading flow::”h]”hŒ@Adding brackets around the outer loop enhances the reading flow:”…””}”(hj   h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mhj·  h²hubj]  )”}”(hŒWfor (i = 0; i < end; i++) {
        if (foo[i])
                do_something(foo[i]);
}”h]”hŒWfor (i = 0; i < end; i++) {
        if (foo[i])
                do_something(foo[i]);
}”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Mhj·  h²hubeh}”(h]”Œbracket-rules”ah ]”h"]”Œbracket rules”ah$]”h&]”uh1hÈhjÄ  h²hh³hÇh´MpubhÉ)”}”(hhh]”(hÎ)”}”(hŒVariable declarations”h]”hŒVariable declarations”…””}”(hj'  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj$  h²hh³hÇh´Mˆubhï)”}”(hŒjThe preferred ordering of variable declarations at the beginning of a
function is reverse fir tree order::”h]”hŒiThe preferred ordering of variable declarations at the beginning of a
function is reverse fir tree order:”…””}”(hj5  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MŠhj$  h²hubj]  )”}”(hŒ]struct long_struct_name *descriptive_name;
unsigned long foo, bar;
unsigned int tmp;
int ret;”h]”hŒ]struct long_struct_name *descriptive_name;
unsigned long foo, bar;
unsigned int tmp;
int ret;”…””}”hjC  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Mhj$  h²hubhï)”}”(hŒ8The above is faster to parse than the reverse ordering::”h]”hŒ7The above is faster to parse than the reverse ordering:”…””}”(hjQ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M’hj$  h²hubj]  )”}”(hŒ]int ret;
unsigned int tmp;
unsigned long foo, bar;
struct long_struct_name *descriptive_name;”h]”hŒ]int ret;
unsigned int tmp;
unsigned long foo, bar;
struct long_struct_name *descriptive_name;”…””}”hj_  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M”hj$  h²hubhï)”}”(hŒ'And even more so than random ordering::”h]”hŒ&And even more so than random ordering:”…””}”(hjm  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M™hj$  h²hubj]  )”}”(hŒ]unsigned long foo, bar;
int ret;
struct long_struct_name *descriptive_name;
unsigned int tmp;”h]”hŒ]unsigned long foo, bar;
int ret;
struct long_struct_name *descriptive_name;
unsigned int tmp;”…””}”hj{  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M›hj$  h²hubhï)”}”(hŒwAlso please try to aggregate variables of the same type into a single
line. There is no point in wasting screen space::”h]”hŒvAlso please try to aggregate variables of the same type into a single
line. There is no point in wasting screen space:”…””}”(hj‰  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M hj$  h²hubj]  )”}”(hŒCunsigned long a;
unsigned long b;
unsigned long c;
unsigned long d;”h]”hŒCunsigned long a;
unsigned long b;
unsigned long c;
unsigned long d;”…””}”hj—  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M£hj$  h²hubhï)”}”(hŒIt's really sufficient to do::”h]”hŒItâ€™s really sufficient to do:”…””}”(hj¥  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M¨hj$  h²hubj]  )”}”(hŒunsigned long a, b, c, d;”h]”hŒunsigned long a, b, c, d;”…””}”hj³  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Mªhj$  h²hubhï)”}”(hŒKPlease also refrain from introducing line splits in variable declarations::”h]”hŒJPlease also refrain from introducing line splits in variable declarations:”…””}”(hjÁ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M¬hj$  h²hubj]  )”}”(hŒÎstruct long_struct_name *descriptive_name = container_of(bar,
                                              struct long_struct_name,
                                              member);
struct foobar foo;”h]”hŒÎstruct long_struct_name *descriptive_name = container_of(bar,
                                              struct long_struct_name,
                                              member);
struct foobar foo;”…””}”hjÏ  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M®hj$  h²hubhï)”}”(hŒVIt's way better to move the initialization to a separate line after the
declarations::”h]”hŒWItâ€™s way better to move the initialization to a separate line after the
declarations:”…””}”(hjÝ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M³hj$  h²hubj]  )”}”(hŒ…struct long_struct_name *descriptive_name;
struct foobar foo;

descriptive_name = container_of(bar, struct long_struct_name, member);”h]”hŒ…struct long_struct_name *descriptive_name;
struct foobar foo;

descriptive_name = container_of(bar, struct long_struct_name, member);”…””}”hjë  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M¶hj$  h²hubeh}”(h]”Œvariable-declarations”ah ]”h"]”Œvariable declarations”ah$]”h&]”uh1hÈhjÄ  h²hh³hÇh´MˆubhÉ)”}”(hhh]”(hÎ)”}”(hŒVariable types”h]”hŒVariable types”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj  h²hh³hÇh´M½ubhï)”}”(hX  Please use the proper u8, u16, u32, u64 types for variables which are meant
to describe hardware or are used as arguments for functions which access
hardware. These types are clearly defining the bit width and avoid
truncation, expansion and 32/64-bit confusion.”h]”hX  Please use the proper u8, u16, u32, u64 types for variables which are meant
to describe hardware or are used as arguments for functions which access
hardware. These types are clearly defining the bit width and avoid
truncation, expansion and 32/64-bit confusion.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M¿hj  h²hubhï)”}”(hX7  u64 is also recommended in code which would become ambiguous for 32-bit
kernels when 'unsigned long' would be used instead. While in such
situations 'unsigned long long' could be used as well, u64 is shorter
and also clearly shows that the operation is required to be 64 bits wide
independent of the target CPU.”h]”hX?  u64 is also recommended in code which would become ambiguous for 32-bit
kernels when â€˜unsigned longâ€™ would be used instead. While in such
situations â€˜unsigned long longâ€™ could be used as well, u64 is shorter
and also clearly shows that the operation is required to be 64 bits wide
independent of the target CPU.”…””}”(hj   h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MÄhj  h²hubhï)”}”(hŒ0Please use 'unsigned int' instead of 'unsigned'.”h]”hŒ8Please use â€˜unsigned intâ€™ instead of â€˜unsignedâ€™.”…””}”(hj.  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MÊhj  h²hubeh}”(h]”Œvariable-types”ah ]”h"]”Œvariable types”ah$]”h&]”uh1hÈhjÄ  h²hh³hÇh´M½ubhÉ)”}”(hhh]”(hÎ)”}”(hŒ	Constants”h]”hŒ	Constants”…””}”(hjG  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjD  h²hh³hÇh´MÎubhï)”}”(hŒšPlease do not use literal (hexa)decimal numbers in code or initializers.
Either use proper defines which have descriptive names or consider using
an enum.”h]”hŒšPlease do not use literal (hexa)decimal numbers in code or initializers.
Either use proper defines which have descriptive names or consider using
an enum.”…””}”(hjU  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MÐhjD  h²hubeh}”(h]”Œ	constants”ah ]”h"]”Œ	constants”ah$]”h&]”uh1hÈhjÄ  h²hh³hÇh´MÎubhÉ)”}”(hhh]”(hÎ)”}”(hŒ$Struct declarations and initializers”h]”hŒ$Struct declarations and initializers”…””}”(hjn  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjk  h²hh³hÇh´MÖubhï)”}”(hŒOStruct declarations should align the struct member names in a tabular
fashion::”h]”hŒNStruct declarations should align the struct member names in a tabular
fashion:”…””}”(hj|  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MØhjk  h²hubj]  )”}”(hŒ|struct bar_order {
        unsigned int    guest_id;
        int             ordered_item;
        struct menu     *menu;
};”h]”hŒ|struct bar_order {
        unsigned int    guest_id;
        int             ordered_item;
        struct menu     *menu;
};”…””}”hjŠ  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´MÛhjk  h²hubhï)”}”(hŒ¥Please avoid documenting struct members within the declaration, because
this often results in strangely formatted comments and the struct members
become obfuscated::”h]”hŒ¤Please avoid documenting struct members within the declaration, because
this often results in strangely formatted comments and the struct members
become obfuscated:”…””}”(hj˜  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Máhjk  h²hubj]  )”}”(hŒÙstruct bar_order {
        unsigned int    guest_id; /* Unique guest id */
        int             ordered_item;
        /* Pointer to a menu instance which contains all the drinks */
        struct menu     *menu;
};”h]”hŒÙstruct bar_order {
        unsigned int    guest_id; /* Unique guest id */
        int             ordered_item;
        /* Pointer to a menu instance which contains all the drinks */
        struct menu     *menu;
};”…””}”hj¦  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Måhjk  h²hubhï)”}”(hŒëInstead, please consider using the kernel-doc format in a comment preceding
the struct declaration, which is easier to read and has the added advantage
of including the information in the kernel documentation, for example, as
follows::”h]”hŒêInstead, please consider using the kernel-doc format in a comment preceding
the struct declaration, which is easier to read and has the added advantage
of including the information in the kernel documentation, for example, as
follows:”…””}”(hj´  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mìhjk  h²hubj]  )”}”(hX  /**
 * struct bar_order - Description of a bar order
 * @guest_id:           Unique guest id
 * @ordered_item:       The item number from the menu
 * @menu:               Pointer to the menu from which the item
 *                      was ordered
 *
 * Supplementary information for using the struct.
 *
 * Note, that the struct member descriptors above are arranged
 * in a tabular fashion.
 */
struct bar_order {
        unsigned int    guest_id;
        int             ordered_item;
        struct menu     *menu;
};”h]”hX  /**
 * struct bar_order - Description of a bar order
 * @guest_id:           Unique guest id
 * @ordered_item:       The item number from the menu
 * @menu:               Pointer to the menu from which the item
 *                      was ordered
 *
 * Supplementary information for using the struct.
 *
 * Note, that the struct member descriptors above are arranged
 * in a tabular fashion.
 */
struct bar_order {
        unsigned int    guest_id;
        int             ordered_item;
        struct menu     *menu;
};”…””}”hjÂ  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Mòhjk  h²hubhï)”}”(hŒfStatic struct initializers must use C99 initializers and should also be
aligned in a tabular fashion::”h]”hŒeStatic struct initializers must use C99 initializers and should also be
aligned in a tabular fashion:”…””}”(hjÐ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mhjk  h²hubj]  )”}”(hŒ”static struct foo statfoo = {
        .a              = 0,
        .plain_integer  = CONSTANT_DEFINE_OR_ENUM,
        .bar            = &statbar,
};”h]”hŒ”static struct foo statfoo = {
        .a              = 0,
        .plain_integer  = CONSTANT_DEFINE_OR_ENUM,
        .bar            = &statbar,
};”…””}”hjÞ  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´Mhjk  h²hubhï)”}”(hŒðNote that while C99 syntax allows the omission of the final comma,
we recommend the use of a comma on the last line because it makes
reordering and addition of new lines easier, and makes such future
patches slightly easier to read as well.”h]”hŒðNote that while C99 syntax allows the omission of the final comma,
we recommend the use of a comma on the last line because it makes
reordering and addition of new lines easier, and makes such future
patches slightly easier to read as well.”…””}”(hjì  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mhjk  h²hubeh}”(h]”Œ$struct-declarations-and-initializers”ah ]”h"]”Œ$struct declarations and initializers”ah$]”h&]”uh1hÈhjÄ  h²hh³hÇh´MÖubhÉ)”}”(hhh]”(hÎ)”}”(hŒLine breaks”h]”hŒLine breaks”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj  h²hh³hÇh´Mubhï)”}”(hŒ¥Restricting line length to 80 characters makes deeply indented code hard to
read.  Consider breaking out code into helper functions to avoid excessive
line breaking.”h]”hŒ¥Restricting line length to 80 characters makes deeply indented code hard to
read.  Consider breaking out code into helper functions to avoid excessive
line breaking.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mhj  h²hubhï)”}”(hŒThe 80 character rule is not a strict rule, so please use common sense when
breaking lines. Especially format strings should never be broken up.”h]”hŒThe 80 character rule is not a strict rule, so please use common sense when
breaking lines. Especially format strings should never be broken up.”…””}”(hj!  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mhj  h²hubhï)”}”(hŒ›When splitting function declarations or function calls, then please align
the first argument in the second line with the first argument in the first
line::”h]”hŒšWhen splitting function declarations or function calls, then please align
the first argument in the second line with the first argument in the first
line:”…””}”(hj/  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´Mhj  h²hubj]  )”}”(hX  static int long_function_name(struct foobar *barfoo, unsigned int id,
                              unsigned int offset)
{

      if (!id) {
              ret = longer_function_name(barfoo, DEFAULT_BARFOO_ID,
                                         offset);
      ...”h]”hX  static int long_function_name(struct foobar *barfoo, unsigned int id,
                              unsigned int offset)
{

      if (!id) {
              ret = longer_function_name(barfoo, DEFAULT_BARFOO_ID,
                                         offset);
      ...”…””}”hj=  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1j\  h³hÇh´M hj  h²hubeh}”(h]”Œline-breaks”ah ]”h"]”Œline breaks”ah$]”h&]”uh1hÈhjÄ  h²hh³hÇh´MubhÉ)”}”(hhh]”(hÎ)”}”(hŒ
Namespaces”h]”hŒ
Namespaces”…””}”(hjV  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjS  h²hh³hÇh´M*ubhï)”}”(hX/  Function/variable namespaces improve readability and allow easy
grepping. These namespaces are string prefixes for globally visible
function and variable names, including inlines. These prefixes should
combine the subsystem and the component name such as 'x86_comp\_',
'sched\_', 'irq\_', and 'mutex\_'.”h]”hX?  Function/variable namespaces improve readability and allow easy
grepping. These namespaces are string prefixes for globally visible
function and variable names, including inlines. These prefixes should
combine the subsystem and the component name such as â€˜x86_comp _â€™,
â€˜sched _â€™, â€˜irq _â€™, and â€˜mutex _â€™.”…””}”(hjd  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M,hjS  h²hubhï)”}”(hŒÉThis also includes static file scope functions that are immediately put
into globally visible driver templates - it's useful for those symbols
to carry a good prefix as well, for backtrace readability.”h]”hŒËThis also includes static file scope functions that are immediately put
into globally visible driver templates - itâ€™s useful for those symbols
to carry a good prefix as well, for backtrace readability.”…””}”(hjr  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M2hjS  h²hubhï)”}”(hŒìNamespace prefixes may be omitted for local static functions and
variables. Truly local functions, only called by other local functions,
can have shorter descriptive names - our primary concern is greppability
and backtrace readability.”h]”hŒìNamespace prefixes may be omitted for local static functions and
variables. Truly local functions, only called by other local functions,
can have shorter descriptive names - our primary concern is greppability
and backtrace readability.”…””}”(hj€  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M6hjS  h²hubhï)”}”(hX  Please note that 'xxx_vendor\_' and 'vendor_xxx_` prefixes are not
helpful for static functions in vendor-specific files. After all, it
is already clear that the code is vendor-specific. In addition, vendor
names should only be for truly vendor-specific functionality.”h]”hX  Please note that â€˜xxx_vendor _â€™ and â€˜vendor_xxx_` prefixes are not
helpful for static functions in vendor-specific files. After all, it
is already clear that the code is vendor-specific. In addition, vendor
names should only be for truly vendor-specific functionality.”…””}”(hjŽ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M;hjS  h²hubhï)”}”(hŒEAs always apply common sense and aim for consistency and readability.”h]”hŒEAs always apply common sense and aim for consistency and readability.”…””}”(hjœ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´M@hjS  h²hubeh}”(h]”Œ
namespaces”ah ]”h"]”Œ
namespaces”ah$]”h&]”uh1hÈhjÄ  h²hh³hÇh´M*ubeh}”(h]”(Œcoding-style-notes”j³  eh ]”h"]”(Œcoding style notes”Œmaintainer-tip-coding-style”eh$]”h&]”uh1hÈhhÊh²hh³hÇh´MÝŒexpect_referenced_by_name”}”j¸  j¨  sŒexpect_referenced_by_id”}”j³  j¨  subhÉ)”}”(hhh]”(hÎ)”}”(hŒCommit notifications”h]”hŒCommit notifications”…””}”(hjÂ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj¿  h²hh³hÇh´MDubhï)”}”(hX–  The tip tree is monitored by a bot for new commits. The bot sends an email
for each new commit to a dedicated mailing list
(``linux-tip-commits@vger.kernel.org``) and Cc's all people who are
mentioned in one of the commit tags. It uses the email message ID from the
Link tag at the end of the tag list to set the In-Reply-To email header so
the message is properly threaded with the patch submission email.”h]”(hŒ|The tip tree is monitored by a bot for new commits. The bot sends an email
for each new commit to a dedicated mailing list
(”…””}”(hjÐ  h²hh³Nh´Nubjl  )”}”(hŒ%``linux-tip-commits@vger.kernel.org``”h]”hŒ!linux-tip-commits@vger.kernel.org”…””}”(hjØ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjÐ  ubhŒ÷) and Ccâ€™s all people who are
mentioned in one of the commit tags. It uses the email message ID from the
Link tag at the end of the tag list to set the In-Reply-To email header so
the message is properly threaded with the patch submission email.”…””}”(hjÐ  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MFhj¿  h²hubhï)”}”(hŒøThe tip maintainers and submaintainers try to reply to the submitter
when merging a patch, but they sometimes forget or it does not fit the
workflow of the moment. While the bot message is purely mechanical, it
also implies a 'Thank you! Applied.'.”h]”hŒüThe tip maintainers and submaintainers try to reply to the submitter
when merging a patch, but they sometimes forget or it does not fit the
workflow of the moment. While the bot message is purely mechanical, it
also implies a â€˜Thank you! Applied.â€™.”…””}”(hjð  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hîh³hÇh´MMhj¿  h²hubeh}”(h]”Œcommit-notifications”ah ]”h"]”Œcommit notifications”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´MDubeh}”(h]”Œthe-tip-tree-handbook”ah ]”h"]”Œthe tip tree handbook”ah$]”h&]”uh1hÈhhh²hh³hÇh´Kubeh}”(h]”h ]”h"]”h$]”h&]”Œsource”hÇuh1hŒcurrent_source”NŒcurrent_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(hÍNŒ	generator”NŒ	datestamp”NŒsource_link”NŒ
source_url”NŒtoc_backlinks”Œentry”Œfootnote_backlinks”KŒsectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒstrip_classes”NŒreport_level”KŒ
halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ	traceback”ˆŒinput_encoding”Œ	utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”Œutf-8”Œoutput_encoding_error_handler”j1  Œerror_encoding”Œutf-8”Œerror_encoding_error_handler”Œbackslashreplace”Œlanguage_code”Œen”Œrecord_dependencies”NŒconfig”NŒ	id_prefix”hŒauto_id_prefix”Œid”Œdump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”hÇŒ_destination”NŒ_config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒfile_insertion_enabled”ˆŒraw_enabled”KŒline_length_limit”M'Œpep_references”NŒpep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒrfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ	tab_width”KŒtrim_footnote_reference_space”‰Œsyntax_highlight”Œlong”Œsmart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œdocinfo_xform”KŒsectsubtitle_xform”‰Œimage_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”Œrefids”}”j³  ]”j¨  asŒnameids”}”(j  j  jZ  jW  jÁ  j¾  j   j  jÕ  jÒ  j;  j8  jŒ  j‰  j×  jÔ  jñ
  jî
  j9  j6  j„  j  j  j
  jP  jM  j¹  j¶  j¸  j³  j·  j´  jK  jH  j´  j±  j!  j  jþ  jû  jA  j>  jh  je  jÿ  jü  jP  jM  j¯  j¬  j  j   uŒ	nametypes”}”(j  ‰jZ  ‰jÁ  ‰j   ‰jÕ  ‰j;  ‰jŒ  ‰j×  ‰jñ
  ‰j9  ‰j„  ‰j  ‰jP  ‰j¹  ‰j¸  ˆj·  ‰jK  ‰j´  ‰j!  ‰jþ  ‰jA  ‰jh  ‰jÿ  ‰jP  ‰j¯  ‰j  ‰uh}”(j  hÊjW  hÝj¾  j]  j  jn  jÒ  j£  j8  jØ  j‰  j>  jÔ  j  jî
  jÚ  j6  jô
  j  j<  j
  j‡  jM  j  j¶  jS  j³  jÄ  j´  jÄ  jH  jÕ  j±  jN  j  j·  jû  j$  j>  j  je  jD  jü  jk  jM  j  j¬  jS  j   j¿  uŒfootnote_refs”}”Œcitation_refs”}”Œautofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ	footnotes”]”Œ	citations”]”Œautofootnote_start”KŒsymbol_footnote_start”K Œ
id_counter”Œcollections”ŒCounter”“”}”…”R”Œparse_messages”]”Œtransform_messages”]”hŒsystem_message”“”)”}”(hhh]”hï)”}”(hhh]”hŒAHyperlink target "maintainer-tip-coding-style" is not referenced.”…””}”hj›  sbah}”(h]”h ]”h"]”h$]”h&]”uh1hîhj˜  ubah}”(h]”h ]”h"]”h$]”h&]”Œlevel”KŒtype”ŒINFO”Œsource”hÇŒline”MÚuh1j–  ubaŒtransformer”NŒinclude_log”]”Œ
decoration”Nh²hub.