Merge tag 'docs-5.14' of git://git.lwn.net/linux

Pull documentation updates from Jonathan Corbet:
 "This was a reasonably active cycle for documentation; this includes:

   - Some kernel-doc cleanups. That script is still regex onslaught from
     hell, but it has gotten a little better.

   - Improvements to the checkpatch docs, which are also used by the
     tool itself.

   - A major update to the pathname lookup documentation.

   - Elimination of :doc: markup, since our automarkup magic can create
     references from filenames without all the extra noise.

   - The flurry of Chinese translation activity continues.

  Plus, of course, the usual collection of updates, typo fixes, and
  warning fixes"

* tag 'docs-5.14' of git://git.lwn.net/linux: (115 commits)
  docs: path-lookup: use bare function() rather than literals
  docs: path-lookup: update symlink description
  docs: path-lookup: update get_link() ->follow_link description
  docs: path-lookup: update WALK_GET, WALK_PUT desc
  docs: path-lookup: no get_link()
  docs: path-lookup: update i_op->put_link and cookie description
  docs: path-lookup: i_op->follow_link replaced with i_op->get_link
  docs: path-lookup: Add macro name to symlink limit description
  docs: path-lookup: remove filename_mountpoint
  docs: path-lookup: update do_last() part
  docs: path-lookup: update path_mountpoint() part
  docs: path-lookup: update path_to_nameidata() part
  docs: path-lookup: update follow_managed() part
  docs: Makefile: Use CONFIG_SHELL not SHELL
  docs: Take a little noise out of the build process
  docs: x86: avoid using ReST :doc:`foo` markup
  docs: virt: kvm: s390-pv-boot.rst: avoid using ReST :doc:`foo` markup
  docs: userspace-api: landlock.rst: avoid using ReST :doc:`foo` markup
  docs: trace: ftrace.rst: avoid using ReST :doc:`foo` markup
  docs: trace: coresight: coresight.rst: avoid using ReST :doc:`foo` markup
  ...

diff --cc Documentation/admin-guide/kernel-parameters.txt
Simple merge

diff --cc Documentation/admin-guide/sysctl/kernel.rst
Simple merge

diff --cc Documentation/virt/kvm/api.rst
index b9ddce5,e86fe34..c7b165c
--- 1/Documentation/virt/kvm/api.rst
--- 2/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@@ -6620,68 -6360,8 +6620,68 @@@ system fingerprint.  To prevent userspa
  by running an enclave in a VM, KVM prevents access to privileged attributes by
  default.
  
- See Documentation/x86/sgx/2.Kernel-internals.rst for more details.
+ See Documentation/x86/sgx.rst for more details.
  
 +7.26 KVM_CAP_PPC_RPT_INVALIDATE
 +-------------------------------
 +
 +:Capability: KVM_CAP_PPC_RPT_INVALIDATE
 +:Architectures: ppc
 +:Type: vm
 +
 +This capability indicates that the kernel is capable of handling
 +H_RPT_INVALIDATE hcall.
 +
 +In order to enable the use of H_RPT_INVALIDATE in the guest,
 +user space might have to advertise it for the guest. For example,
 +IBM pSeries (sPAPR) guest starts using it if "hcall-rpt-invalidate" is
 +present in the "ibm,hypertas-functions" device-tree property.
 +
 +This capability is enabled for hypervisors on platforms like POWER9
 +that support radix MMU.
 +
 +7.27 KVM_CAP_EXIT_ON_EMULATION_FAILURE
 +--------------------------------------
 +
 +:Architectures: x86
 +:Parameters: args[0] whether the feature should be enabled or not
 +
 +When this capability is enabled, an emulation failure will result in an exit
 +to userspace with KVM_INTERNAL_ERROR (except when the emulator was invoked
 +to handle a VMware backdoor instruction). Furthermore, KVM will now provide up
 +to 15 instruction bytes for any exit to userspace resulting from an emulation
 +failure.  When these exits to userspace occur use the emulation_failure struct
 +instead of the internal struct.  They both have the same layout, but the
 +emulation_failure struct matches the content better.  It also explicitly
 +defines the 'flags' field which is used to describe the fields in the struct
 +that are valid (ie: if KVM_INTERNAL_ERROR_EMULATION_FLAG_INSTRUCTION_BYTES is
 +set in the 'flags' field then both 'insn_size' and 'insn_bytes' have valid data
 +in them.)
 +
 +7.28 KVM_CAP_ARM_MTE
 +--------------------
 +
 +:Architectures: arm64
 +:Parameters: none
 +
 +This capability indicates that KVM (and the hardware) supports exposing the
 +Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the
 +VMM before creating any VCPUs to allow the guest access. Note that MTE is only
 +available to a guest running in AArch64 mode and enabling this capability will
 +cause attempts to create AArch32 VCPUs to fail.
 +
 +When enabled the guest is able to access tags associated with any memory given
 +to the guest. KVM will ensure that the tags are maintained during swap or
 +hibernation of the host; however the VMM needs to manually save/restore the
 +tags as appropriate if the VM is migrated.
 +
 +When this capability is enabled all memory in memslots must be mapped as
 +not-shareable (no MAP_SHARED), attempts to create a memslot with a
 +MAP_SHARED mmap will result in an -EINVAL return.
 +
 +When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to
 +perform a bulk copy of tags to/from the guest.
 +
  8. Other capabilities.
  ======================
  

diff --cc Documentation/virt/kvm/vcpu-requests.rst
Simple merge

diff --cc include/linux/device.h
Simple merge

diff --cc samples/kprobes/kprobe_example.c
Simple merge