Commit 257e6524 authored by Jonathan Corbet's avatar Jonathan Corbet
Browse files

Merge branch 'mauro' into docs-next 

Mauro says:

> As discussed at:
> 	https://lore.kernel.org/linux-doc/871r9k6rmy.fsf@meer.lwn.net/
>
> It is better to avoid using :doc:`foo` to refer to Documentation/foo.rst, as the
> automarkup.py extension should handle it automatically, on most cases.
>
> There are a couple of exceptions to this rule:
>
> 1. when :doc:  tag is used to point to a kernel-doc DOC: markup;
> 2. when it is used with a named tag, e. g. :doc:`some name <foo>`;
>
> On this series:
>
> Patch 1 manually adjust the references inside driver-api/pm/devices.rst,
> as there it uses :file:`foo` to refer to some Documentation/ files;
>
> Patch 2 converts a table at Documentation/dev-tools/kunit/api/index.rst
> into a list, carefully avoiding the
>
> The remaining patches convert the other occurrences via a replace script.
> They were manually edited, in order to honour 80-columns where possible.
>
> This series based on docs-next branch. In order to avoid merge conflicts,
> I rebased it internally against yesterday's linux-next, dropping a patch
> and a hunk that would have caused conflicts there.
>
parents a557f67c 0ffd6438

Documentation/PCI/endpoint/pci-endpoint-cfs.rst

+1 −1
Original line number Diff line number Diff line
@@ -125,4 +125,4 @@ all the EPF devices are created and linked with the EPC device. 
						| interrupt_pin

						| function



[1] :doc:`pci-endpoint`
 
[1] Documentation/PCI/endpoint/pci-endpoint.rst

Documentation/PCI/pci.rst

+3 −3
Original line number Diff line number Diff line
@@ -265,7 +265,7 @@ Set the DMA mask size 
---------------------

.. note::

   If anything below doesn't make sense, please refer to

   :doc:`/core-api/dma-api`. This section is just a reminder that

   Documentation/core-api/dma-api.rst. This section is just a reminder that

   drivers need to indicate DMA capabilities of the device and is not

   an authoritative source for DMA interfaces.
@@ -291,7 +291,7 @@ Many 64-bit "PCI" devices (before PCI-X) and some PCI-X devices are 
Setup shared control data

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

Once the DMA masks are set, the driver can allocate "consistent" (a.k.a. shared)

memory.  See :doc:`/core-api/dma-api` for a full description of

memory.  See Documentation/core-api/dma-api.rst for a full description of

the DMA APIs. This section is just a reminder that it needs to be done

before enabling DMA on the device.
@@ -421,7 +421,7 @@ owners if there is one. 


Then clean up "consistent" buffers which contain the control data.



See :doc:`/core-api/dma-api` for details on unmapping interfaces.

See Documentation/core-api/dma-api.rst for details on unmapping interfaces.





Unregister from other subsystems

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst

+2 −1
Original line number Diff line number Diff line
@@ -3,7 +3,8 @@ 
SRBDS - Special Register Buffer Data Sampling

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



SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to

SRBDS is a hardware vulnerability that allows MDS

Documentation/admin-guide/hw-vuln/mds.rst techniques to

infer values returned from special register accesses.  Special register

accesses are accesses to off core registers.  According to Intel's evaluation,

the special register reads that have a security expectation of privacy are

Documentation/admin-guide/pm/intel_idle.rst

+10 −6
Original line number Diff line number Diff line
@@ -20,8 +20,8 @@ Nehalem and later generations of Intel processors, but the level of support for 
a particular processor model in it depends on whether or not it recognizes that

processor model and may also depend on information coming from the platform

firmware.  [To understand ``intel_idle`` it is necessary to know how ``CPUIdle``

works in general, so this is the time to get familiar with :doc:`cpuidle` if you

have not done that yet.]

works in general, so this is the time to get familiar with

Documentation/admin-guide/pm/cpuidle.rst if you have not done that yet.]



``intel_idle`` uses the ``MWAIT`` instruction to inform the processor that the

logical CPU executing it is idle and so it may be possible to put some of the
@@ -53,7 +53,8 @@ processor) corresponding to them depends on the processor model and it may also 
depend on the configuration of the platform.



In order to create a list of available idle states required by the ``CPUIdle``

subsystem (see :ref:`idle-states-representation` in :doc:`cpuidle`),

subsystem (see :ref:`idle-states-representation` in

Documentation/admin-guide/pm/cpuidle.rst),

``intel_idle`` can use two sources of information: static tables of idle states

for different processor models included in the driver itself and the ACPI tables

of the system.  The former are always used if the processor model at hand is
@@ -98,7 +99,8 @@ states may not be enabled by default if there are no matching entries in the 
preliminary list of idle states coming from the ACPI tables.  In that case user

space still can enable them later (on a per-CPU basis) with the help of

the ``disable`` idle state attribute in ``sysfs`` (see

:ref:`idle-states-representation` in :doc:`cpuidle`).  This basically means that

:ref:`idle-states-representation` in

Documentation/admin-guide/pm/cpuidle.rst).  This basically means that

the idle states "known" to the driver may not be enabled by default if they have

not been exposed by the platform firmware (through the ACPI tables).
@@ -186,7 +188,8 @@ be desirable. In practice, it is only really necessary to do that if the idle 
states in question cannot be enabled during system startup, because in the

working state of the system the CPU power management quality of service (PM

QoS) feature can be used to prevent ``CPUIdle`` from touching those idle states

even if they have been enumerated (see :ref:`cpu-pm-qos` in :doc:`cpuidle`).

even if they have been enumerated (see :ref:`cpu-pm-qos` in

Documentation/admin-guide/pm/cpuidle.rst).

Setting ``max_cstate`` to 0 causes the ``intel_idle`` initialization to fail.



The ``no_acpi`` and ``use_acpi`` module parameters (recognized by ``intel_idle``
@@ -202,7 +205,8 @@ Namely, the positions of the bits that are set in the ``states_off`` value are 
the indices of idle states to be disabled by default (as reflected by the names

of the corresponding idle state directories in ``sysfs``, :file:`state0`,

:file:`state1` ... :file:`state<i>` ..., where ``<i>`` is the index of the given

idle state; see :ref:`idle-states-representation` in :doc:`cpuidle`).

idle state; see :ref:`idle-states-representation` in

Documentation/admin-guide/pm/cpuidle.rst).



For example, if ``states_off`` is equal to 3, the driver will disable idle

states 0 and 1 by default, and if it is equal to 8, idle state 3 will be

Documentation/admin-guide/pm/intel_pstate.rst

+5 −4
Original line number Diff line number Diff line
@@ -18,8 +18,8 @@ General Information 
(``CPUFreq``).  It is a scaling driver for the Sandy Bridge and later

generations of Intel processors.  Note, however, that some of those processors

may not be supported.  [To understand ``intel_pstate`` it is necessary to know

how ``CPUFreq`` works in general, so this is the time to read :doc:`cpufreq` if

you have not done that yet.]

how ``CPUFreq`` works in general, so this is the time to read

Documentation/admin-guide/pm/cpufreq.rst if you have not done that yet.]



For the processors supported by ``intel_pstate``, the P-state concept is broader

than just an operating frequency or an operating performance point (see the
@@ -445,8 +445,9 @@ Interpretation of Policy Attributes 
-----------------------------------



The interpretation of some ``CPUFreq`` policy attributes described in

:doc:`cpufreq` is special with ``intel_pstate`` as the current scaling driver

and it generally depends on the driver's `operation mode <Operation Modes_>`_.

Documentation/admin-guide/pm/cpufreq.rst is special with ``intel_pstate``

as the current scaling driver and it generally depends on the driver's

`operation mode <Operation Modes_>`_.



First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and

``scaling_cur_freq`` attributes are produced by applying a processor-specific