linux-stable.git/Documentation, branch linux-5.17.y

ata: libata-transport: fix {dma|pio|xfer}_mode sysfs files

2022-06-14T16:41:46+00:00

commit 72aad489f992871e908ff6d9055b26c6366fb864 upstream.

The {dma|pio}_mode sysfs files are incorrectly documented as having a
list of the supported DMA/PIO transfer modes, while the corresponding
fields of the *struct* ata_device hold the transfer mode IDs, not masks.

To match these docs, the {dma|pio}_mode (and even xfer_mode!) sysfs
files are handled by the ata_bitfield_name_match() macro which leads to
reading such kind of nonsense from them:

$ cat /sys/class/ata_device/dev3.0/pio_mode
XFER_UDMA_7, XFER_UDMA_6, XFER_UDMA_5, XFER_UDMA_4, XFER_MW_DMA_4,
XFER_PIO_6, XFER_PIO_5, XFER_PIO_4, XFER_PIO_3, XFER_PIO_2, XFER_PIO_1,
XFER_PIO_0

Using the correct ata_bitfield_name_search() macro fixes that:

$ cat /sys/class/ata_device/dev3.0/pio_mode
XFER_PIO_4

While fixing the file documentation, somewhat reword the {dma|pio}_mode
file doc and add a note about being mostly useful for PATA devices to
the xfer_mode file doc...

Fixes: d9027470b886 ("[libata] Add ATA transport class")
Signed-off-by: Sergey Shtylyov 
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal 
Signed-off-by: Greg Kroah-Hartman

rtla/Makefile: Properly handle dependencies

2022-06-14T16:41:28+00:00

[ Upstream commit fe4d0d5dde457bb5832b866418b5036f4f0c8d13 ]

Linus had a problem compiling RTLA, saying:

"[...] I wish the tracing tools would do a bit more package
checking and helpful error messages too, rather than just
fail with:

    fatal error: tracefs.h: No such file or directory"

Which is indeed not a helpful message. Update the Makefile, adding
proper checks for the dependencies, with useful information about
how to resolve possible problems.

For example, the previous error is now reported as:

    $ make
    ********************************************
    ** NOTICE: libtracefs version 1.3 or higher not found
    **
    ** Consider installing the latest libtracefs from your
    ** distribution, e.g., 'dnf install libtracefs' on Fedora,
    ** or from source:
    **
    **  https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/
    **
    ********************************************

These messages are inspired by the ones used on trace-cmd, as suggested
by Stevel Rostedt.

Link: https://lore.kernel.org/r/CAHk-=whxmA86E=csNv76DuxX_wYsg8mW15oUs3XTabu2Yc80yw@mail.gmail.com/

Changes from V1:
 - Moved the rst2man check to the install phase (when it is used).
 - Removed the procps-ng lib check [1] as it is being removed.

[1] a0f9f8c1030c66305c9b921057c3d483064d5529.1651220820.git.bristot@kernel.org

Link: https://lkml.kernel.org/r/3f1fac776c37e4b67c876a94e5a0e45ed022ff3d.1651238057.git.bristot@kernel.org

Cc: Ingo Molnar 
Cc: Andrew Morton 
Reported-by: Linus Torvalds 
Suggested-by: Steven Rostedt 
Signed-off-by: Daniel Bristot de Oliveira 
Signed-off-by: Steven Rostedt (Google) 
Signed-off-by: Sasha Levin

regulator: mt6315-regulator: fix invalid allowed mode

2022-06-14T16:41:25+00:00

[ Upstream commit 28cbc2d4c54c09a427b18a1604740efb6b2cc2d6 ]

In the binding example, the regulator mode 4 is shown as a valid mode,
but the driver actually only support mode 0 to 2:

This generates an error in dmesg when copy/pasting the binding example:
[    0.306080] vbuck1: invalid regulator-allowed-modes element 4
[    0.307290] vbuck2: invalid regulator-allowed-modes element 4

This commit fixes this error by removing the invalid mode from the
examples.

Fixes: 977fb5b58469 ("regulator: document binding for MT6315 regulator")
Signed-off-by: Fabien Parent 
Link: https://lore.kernel.org/r/20220529154613.337559-1-fparent@baylibre.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

dt-bindings: remoteproc: mediatek: Make l1tcm reg exclusive to mt819x

2022-06-14T16:41:17+00:00

[ Upstream commit 6bbe1065121b8cd3b3e734ef8cd99f142bdab241 ]

Commit ca23ecfdbd44 ("remoteproc/mediatek: support L1TCM") added support
for the l1tcm memory region on the MT8192 SCP, adding a new da_to_va
callback that handles l1tcm while keeping the old one for
back-compatibility with MT8183. However, since the mt8192 compatible was
missing from the dt-binding, the accompanying dt-binding commit
503c64cc42f1 ("dt-bindings: remoteproc: mediatek: add L1TCM memory region")
mistakenly added this reg as if it were for mt8183. And later
it became common to all platforms as their compatibles were added.

Fix the dt-binding so that the l1tcm reg can be present only on the
supported platforms: mt8192 and mt8195.

Fixes: 503c64cc42f1 ("dt-bindings: remoteproc: mediatek: add L1TCM memory region")
Signed-off-by: Nícolas F. R. A. Prado 
Reviewed-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20220511195452.871897-2-nfraprado@collabora.com
Signed-off-by: Mathieu Poirier 
Signed-off-by: Sasha Levin

dt-bindings: gpio: altera: correct interrupt-cells

2022-06-09T08:26:30+00:00

commit 3a21c3ac93aff7b4522b152399df8f6a041df56d upstream.

update documentation to correctly state the interrupt-cells to be 2.

Cc: stable@vger.kernel.org
Fixes: 4fd9bbc6e071 ("drivers/gpio: Altera soft IP GPIO driver devicetree binding")
Signed-off-by: Dinh Nguyen 
Signed-off-by: Greg Kroah-Hartman

docs/conf.py: Cope with removal of language=None in Sphinx 5.0.0

2022-06-09T08:26:30+00:00

commit 627f01eab93d8671d4e4afee9b148f9998d20e7c upstream.

One of the changes in Sphinx 5.0.0 [1] says [sic]:

    5.0.0 final

     - #10474: language does not accept None as it value.
       The default value of language becomes to 'en' now.

[1]: https://www.sphinx-doc.org/en/master/changes.html#release-5-0-0-released-may-30-2022

It results in a new warning from Sphinx 5.0.0 [sic]:

    WARNING: Invalid configuration value found: 'language = None'.
    Update your configuration to a valid langauge code. Falling
    back to 'en' (English).

Silence the warning by using 'en'.
It works with all the Sphinx versions required for building
kernel documentation (1.7.9 or later).

Signed-off-by: Akira Yokosawa 
Link: https://lore.kernel.org/r/bd0c2ddc-2401-03cb-4526-79ca664e1cbe@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Corbet 
Signed-off-by: Greg Kroah-Hartman

landlock: Reduce the maximum number of layers to 16

2022-06-09T08:26:23+00:00

commit 75c542d6c6cc48720376862d5496d51509160dfd upstream.

The maximum number of nested Landlock domains is currently 64.  Because
of the following fix and to help reduce the stack size, let's reduce it
to 16.  This seems large enough for a lot of use cases (e.g. sandboxed
init service, spawning a sandboxed SSH service, in nested sandboxed
containers).  Reducing the number of nested domains may also help to
discover misuse of Landlock (e.g. creating a domain per rule).

Add and use a dedicated layer_mask_t typedef to fit with the number of
layers.  This might be useful when changing it and to keep it consistent
with the maximum number of layers.

Reviewed-by: Paul Moore 
Link: https://lore.kernel.org/r/20220506161102.525323-3-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün 
Signed-off-by: Greg Kroah-Hartman

dt-bindings: soc: qcom: smd-rpm: Fix missing MSM8936 compatible

2022-06-09T08:26:01+00:00

[ Upstream commit e930244918092d44b60a7b538cf60d737010ceef ]

Add compatible msm8936. msm8936 covers both msm8936 and msm8939.
The relevant driver already has the compat string but, we haven't
documented it.

Fixes: d6e52482f5ab ("drivers: soc: Add MSM8936 SMD RPM compatible")
Signed-off-by: Bryan O'Donoghue 
Acked-by: Krzysztof Kozlowski 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20220418231857.3061053-1-bryan.odonoghue@linaro.org
Signed-off-by: Sasha Levin

sched/psi: report zeroes for CPU full at the system level

2022-06-09T08:25:41+00:00

[ Upstream commit 890d550d7dbac7a31ecaa78732aa22be282bb6b8 ]

Martin find it confusing when look at the /proc/pressure/cpu output,
and found no hint about that CPU "full" line in psi Documentation.

% cat /proc/pressure/cpu
some avg10=0.92 avg60=0.91 avg300=0.73 total=933490489
full avg10=0.22 avg60=0.23 avg300=0.16 total=358783277

The PSI_CPU_FULL state is introduced by commit e7fcd7622823
("psi: Add PSI_CPU_FULL state"), which mainly for cgroup level,
but also counted at the system level as a side effect.

Naturally, the FULL state doesn't exist for the CPU resource at
the system level. These "full" numbers can come from CPU idle
schedule latency. For example, t1 is the time when task wakeup
on an idle CPU, t2 is the time when CPU pick and switch to it.
The delta of (t2 - t1) will be in CPU_FULL state.

Another case all processes can be stalled is when all cgroups
have been throttled at the same time, which unlikely to happen.

Anyway, CPU_FULL metric is meaningless and confusing at the
system level. So this patch will report zeroes for CPU full
at the system level, and update psi Documentation accordingly.

Fixes: e7fcd7622823 ("psi: Add PSI_CPU_FULL state")
Reported-by: Martin Steigerwald 
Suggested-by: Johannes Weiner 
Signed-off-by: Chengming Zhou 
Signed-off-by: Peter Zijlstra (Intel) 
Acked-by: Johannes Weiner 
Link: https://lore.kernel.org/r/20220408121914.82855-1-zhouchengming@bytedance.com
Signed-off-by: Sasha Levin

spi: qcom-qspi: Add minItems to interconnect-names

2022-06-09T08:25:37+00:00

[ Upstream commit e23d86c49a9c78e8dbe3abff20b30812b26ab427 ]

Add minItems constraint to interconnect-names as well. The schema
currently tries to match 2 names and fail for DTs with single entry.

With the change applied, below interconnect-names values are possible:
['qspi-config'], ['qspi-config', 'qspi-memory']

Fixes: 8f9c291558ea ("dt-bindings: spi: Add interconnect binding for QSPI")
Signed-off-by: Kuldeep Singh 
Reviewed-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20220328192006.18523-1-singh.kuldeep87k@gmail.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin