Commit e68ce947 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

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

Pull more documentation updates from Jonathan Corbet:
 "A few late-arriving fixes, plus two more significant changes that were
  *almost* ready at the beginning of the merge window:

   - A new document on debugging techniques from Sebastian Fricke

   - A clarification on MODULE_LICENSE terms meant to head off the sort
     of confusion that led to the recent Tuxedo Computers mess"

* tag 'docs-6.13-2' of git://git.lwn.net/linux:
  docs: Add debugging guide for the media subsystem
  docs: Add debugging section to process
  docs/licensing: Clarify wording about "GPL" and "Proprietary"
  docs: core-api/gfp_mask-from-fs-io: indicate that vmalloc supports GFP_NOFS/GFP_NOIO
  Documentation: kernel-doc: enumerate identifier *type*s
  Documentation: pwrseq: Fix trivial misspellings
  Documentation: filesystems: update filename extensions
parents 6daf0882 83a474c1

Documentation/admin-guide/media/index.rst

+5 −0
Original line number Diff line number Diff line
@@ -20,6 +20,11 @@ Documentation/driver-api/media/index.rst 
  - for driver development information and Kernel APIs used by

    media devices;



Documentation/process/debugging/media_specific_debugging_guide.rst



  - for advice about essential tools and techniques to debug drivers on this

    subsystem



.. toctree::

	:caption: Table of Contents

	:maxdepth: 2

Documentation/core-api/gfp_mask-from-fs-io.rst

+11 −9
Original line number Diff line number Diff line
@@ -55,14 +55,16 @@ scope. 
What about __vmalloc(GFP_NOFS)

==============================



vmalloc doesn't support GFP_NOFS semantic because there are hardcoded

GFP_KERNEL allocations deep inside the allocator which are quite non-trivial

to fix up. That means that calling ``vmalloc`` with GFP_NOFS/GFP_NOIO is

almost always a bug. The good news is that the NOFS/NOIO semantic can be

achieved by the scope API.

Since v5.17, and specifically after the commit 451769ebb7e79 ("mm/vmalloc:

alloc GFP_NO{FS,IO} for vmalloc"), GFP_NOFS/GFP_NOIO are now supported in

``[k]vmalloc`` by implicitly using scope API.



In earlier kernels ``vmalloc`` didn't support GFP_NOFS semantic because there

were hardcoded GFP_KERNEL allocations deep inside the allocator. That means

that calling ``vmalloc`` with GFP_NOFS/GFP_NOIO was almost always a bug.



In the ideal world, upper layers should already mark dangerous contexts

and so no special care is required and vmalloc should be called without

any problems. Sometimes if the context is not really clear or there are

layering violations then the recommended way around that is to wrap ``vmalloc``

by the scope API with a comment explaining the problem.
 
and so no special care is required and ``vmalloc`` should be called without any

problems. Sometimes if the context is not really clear or there are layering

violations then the recommended way around that (on pre-v5.17 kernels) is to

wrap ``vmalloc`` by the scope API with a comment explaining the problem.

Documentation/doc-guide/kernel-doc.rst

+1 −0
Original line number Diff line number Diff line
@@ -533,6 +533,7 @@ identifiers: *[ function/type ...]* 
  Include documentation for each *function* and *type* in *source*.

  If no *function* is specified, the documentation for all functions

  and types in the *source* will be included.

  *type* can be a struct, union, enum, or typedef identifier.



  Examples::

Documentation/driver-api/pwrseq.rst

+4 −4
Original line number Diff line number Diff line
@@ -11,7 +11,7 @@ Introduction 
============



This framework is designed to abstract complex power-up sequences that are

shared between multiple logical devices in the linux kernel.

shared between multiple logical devices in the Linux kernel.



The intention is to allow consumers to obtain a power sequencing handle

exposed by the power sequence provider and delegate the actual requesting and
@@ -25,7 +25,7 @@ The power sequencing API uses a number of terms specific to the subsystem: 


Unit



    A unit is a discreet chunk of a power sequence. For instance one unit may

    A unit is a discrete chunk of a power sequence. For instance one unit may

    enable a set of regulators, another may enable a specific GPIO. Units can

    define dependencies in the form of other units that must be enabled before

    it itself can be.
@@ -62,7 +62,7 @@ Provider interface 
The provider API is admittedly not nearly as straightforward as the one for

consumers but it makes up for it in flexibility.



Each provider can logically split the power-up sequence into descrete chunks

Each provider can logically split the power-up sequence into discrete chunks

(units) and define their dependencies. They can then expose named targets that

consumers may use as the final point in the sequence that they wish to reach.
@@ -72,7 +72,7 @@ register with the pwrseq subsystem by calling pwrseq_device_register(). 
Dynamic consumer matching

-------------------------



The main difference between pwrseq and other linux kernel providers is the

The main difference between pwrseq and other Linux kernel providers is the

mechanism for dynamic matching of consumers and providers. Every power sequence

provider driver must implement the `match()` callback and pass it to the pwrseq

core when registering with the subsystems.

Documentation/filesystems/autofs.rst

+1 −1
Original line number Diff line number Diff line
@@ -442,7 +442,7 @@ which can be used to communicate directly with the autofs filesystem. 
It requires CAP_SYS_ADMIN for access.



The 'ioctl's that can be used on this device are described in a separate

document `autofs-mount-control.txt`, and are summarised briefly here.

document `autofs-mount-control.rst`, and are summarised briefly here.

Each ioctl is passed a pointer to an `autofs_dev_ioctl` structure::



        struct autofs_dev_ioctl {