Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
…git/broonie/sound into for-linus

ASoC: Updates for v5.9

The biggest changes here one again come from Mormioto-san who has
continued his dilligent work cleaning up long standing issues in the
APIs, it's particularly nice to see the transition from digital_mute()
to mute_stream() finally completed. There's also been a lot of work on
the x86 code again, this time a big focus has been on cleaning up some
issues identified by various static tests, and on the Freescale systems.
Otherwise the biggest thing has been a lot of driver additions:

 - Convert users of digital_mute() to mute_stream().
 - Simplify I/O helper functions.
 - Add a helper for getting the RTD from a substream.
 - Many, many fixes and cleanups to the x86 code.
 - New drivers for Freescale MQS and i.MX6sx, Intel KeemBay I2S, Maxim
   MAX98360A and MAX98373 Soundwire, several Mediatek boards, nVidia
   Tegra 186 and 210, RealTek RL6231, Samsung Midas and Aries boards (some
   of the first phones I worked on!) and TI J721e EVM.
  • Loading branch information
tiwai committed Aug 3, 2020
2 parents 07c9983 + 84569f3 commit 103f528
Show file tree
Hide file tree
Showing 2,514 changed files with 35,259 additions and 16,838 deletions.
3 changes: 3 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -143,6 +143,9 @@ x509.genkey
/allrandom.config
/allyes.config

# Kconfig savedefconfig output
/defconfig

# Kdevelop4
*.kdev4

Expand Down
8 changes: 8 additions & 0 deletions .mailmap
Original file line number Diff line number Diff line change
Expand Up @@ -90,11 +90,16 @@ Frank Rowand <[email protected]> <[email protected]>
Frank Zago <[email protected]>
Gao Xiang <[email protected]> <[email protected]>
Gao Xiang <[email protected]> <[email protected]>
Gerald Schaefer <[email protected]> <[email protected]>
Gerald Schaefer <[email protected]> <[email protected]>
Gerald Schaefer <[email protected]> <[email protected]>
Greg Kroah-Hartman <greg@echidna.(none)>
Greg Kroah-Hartman <[email protected]>
Greg Kroah-Hartman <[email protected]>
Gregory CLEMENT <[email protected]> <[email protected]>
Hanjun Guo <[email protected]> <[email protected]>
Heiko Carstens <[email protected]> <[email protected]>
Heiko Carstens <[email protected]> <[email protected]>
Henk Vergonet <[email protected]>
Henrik Kretzschmar <[email protected]>
Henrik Rydberg <[email protected]>
Expand Down Expand Up @@ -193,6 +198,9 @@ Maxime Ripard <[email protected]> <[email protected]>
Mayuresh Janorkar <[email protected]>
Michael Buesch <[email protected]>
Michel Dänzer <[email protected]>
Mike Rapoport <[email protected]> <[email protected]>
Mike Rapoport <[email protected]> <[email protected]>
Mike Rapoport <[email protected]> <[email protected]>
Miodrag Dinic <[email protected]> <[email protected]>
Miquel Raynal <[email protected]> <[email protected]>
Mitesh shah <[email protected]>
Expand Down
11 changes: 10 additions & 1 deletion Documentation/ABI/testing/debugfs-driver-habanalabs
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,16 @@ Description: Allow the root user to disable/enable in runtime the clock
gating mechanism in Gaudi. Due to how Gaudi is built, the
clock gating needs to be disabled in order to access the
registers of the TPC and MME engines. This is sometimes needed
during debug by the user and hence the user needs this option
during debug by the user and hence the user needs this option.
The user can supply a bitmask value, each bit represents
a different engine to disable/enable its clock gating feature.
The bitmask is composed of 20 bits:
0 - 7 : DMA channels
8 - 11 : MME engines
12 - 19 : TPC engines
The bit's location of a specific engine can be determined
using (1 << GAUDI_ENGINE_ID_*). GAUDI_ENGINE_ID_* values
are defined in uapi habanalabs.h file in enum gaudi_engine_id

What: /sys/kernel/debug/habanalabs/hl<n>/command_buffers
Date: Jan 2019
Expand Down
5 changes: 0 additions & 5 deletions Documentation/ABI/testing/dev-kmsg
Original file line number Diff line number Diff line change
Expand Up @@ -56,11 +56,6 @@ Description: The /dev/kmsg character device node provides userspace access
seek after the last record available at the time
the last SYSLOG_ACTION_CLEAR was issued.

Due to the record nature of this interface with a "read all"
behavior and the specific positions each seek operation sets,
SEEK_CUR is not supported, returning -ESPIPE (invalid seek) to
errno whenever requested.

The output format consists of a prefix carrying the syslog
prefix including priority and facility, the 64 bit message
sequence number and the monotonic timestamp in microseconds,
Expand Down
27 changes: 27 additions & 0 deletions Documentation/ABI/testing/sysfs-bus-papr-pmem
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
What: /sys/bus/nd/devices/nmemX/papr/flags
Date: Apr, 2020
KernelVersion: v5.8
Contact: linuxppc-dev <[email protected]>, [email protected],
Description:
(RO) Report flags indicating various states of a
papr-pmem NVDIMM device. Each flag maps to a one or
more bits set in the dimm-health-bitmap retrieved in
response to H_SCM_HEALTH hcall. The details of the bit
flags returned in response to this hcall is available
at 'Documentation/powerpc/papr_hcalls.rst' . Below are
the flags reported in this sysfs file:

* "not_armed" : Indicates that NVDIMM contents will not
survive a power cycle.
* "flush_fail" : Indicates that NVDIMM contents
couldn't be flushed during last
shut-down event.
* "restore_fail": Indicates that NVDIMM contents
couldn't be restored during NVDIMM
initialization.
* "encrypted" : NVDIMM contents are encrypted.
* "smart_notify": There is health event for the NVDIMM.
* "scrubbed" : Indicating that contents of the
NVDIMM have been scrubbed.
* "locked" : Indicating that NVDIMM contents cant
be modified until next power cycle.
8 changes: 4 additions & 4 deletions Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
What: /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req
Date: Feb 2014
Contact: Li Jun <b47624@freescale.com>
Contact: Li Jun <jun.li@nxp.com>
Description:
Can be set and read.
Set a_bus_req(A-device bus request) input to be 1 if
Expand All @@ -17,7 +17,7 @@ Description:

What: /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop
Date: Feb 2014
Contact: Li Jun <b47624@freescale.com>
Contact: Li Jun <jun.li@nxp.com>
Description:
Can be set and read
The a_bus_drop(A-device bus drop) input is 1 when the
Expand All @@ -32,7 +32,7 @@ Description:

What: /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req
Date: Feb 2014
Contact: Li Jun <b47624@freescale.com>
Contact: Li Jun <jun.li@nxp.com>
Description:
Can be set and read.
The b_bus_req(B-device bus request) input is 1 during the time
Expand All @@ -47,7 +47,7 @@ Description:

What: /sys/bus/platform/devices/ci_hdrc.0/inputs/a_clr_err
Date: Feb 2014
Contact: Li Jun <b47624@freescale.com>
Contact: Li Jun <jun.li@nxp.com>
Description:
Only can be set.
The a_clr_err(A-device Vbus error clear) input is used to clear
Expand Down
2 changes: 1 addition & 1 deletion Documentation/admin-guide/README.rst
Original file line number Diff line number Diff line change
Expand Up @@ -258,7 +258,7 @@ Configuring the kernel
Compiling the kernel
--------------------

- Make sure you have at least gcc 4.6 available.
- Make sure you have at least gcc 4.9 available.
For more information, refer to :ref:`Documentation/process/changes.rst <changes>`.

Please note that you can still run a.out user programs with this kernel.
Expand Down
4 changes: 2 additions & 2 deletions Documentation/admin-guide/cgroup-v2.rst
Original file line number Diff line number Diff line change
Expand Up @@ -1356,8 +1356,8 @@ PAGE_SIZE multiple when read back.

thp_fault_alloc
Number of transparent hugepages which were allocated to satisfy
a page fault, including COW faults. This counter is not present
when CONFIG_TRANSPARENT_HUGEPAGE is not set.
a page fault. This counter is not present when CONFIG_TRANSPARENT_HUGEPAGE
is not set.

thp_collapse_alloc
Number of transparent hugepages which were allocated to allow
Expand Down
1 change: 1 addition & 0 deletions Documentation/admin-guide/device-mapper/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,7 @@ Device Mapper
dm-clone
dm-crypt
dm-dust
dm-ebs
dm-flakey
dm-init
dm-integrity
Expand Down
3 changes: 1 addition & 2 deletions Documentation/admin-guide/mm/transhuge.rst
Original file line number Diff line number Diff line change
Expand Up @@ -305,8 +305,7 @@ monitor how successfully the system is providing huge pages for use.

thp_fault_alloc
is incremented every time a huge page is successfully
allocated to handle a page fault. This applies to both the
first time a page is faulted and for COW faults.
allocated to handle a page fault.

thp_collapse_alloc
is incremented by khugepaged when it has found
Expand Down
2 changes: 2 additions & 0 deletions Documentation/arm64/cpu-feature-registers.rst
Original file line number Diff line number Diff line change
Expand Up @@ -171,6 +171,7 @@ infrastructure:


3) ID_AA64PFR1_EL1 - Processor Feature Register 1

+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
Expand All @@ -181,6 +182,7 @@ infrastructure:


4) MIDR_EL1 - Main ID Register

+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
Expand Down
8 changes: 8 additions & 0 deletions Documentation/arm64/silicon-errata.rst
Original file line number Diff line number Diff line change
Expand Up @@ -147,6 +147,14 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1463225 |
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1418040 |
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1530923 |
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Kryo4xx Silver | N/A | ARM64_ERRATUM_1024718 |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 |
+----------------+-----------------+-----------------+-----------------------------+
6 changes: 3 additions & 3 deletions Documentation/arm64/sve.rst
Original file line number Diff line number Diff line change
Expand Up @@ -186,7 +186,7 @@ prctl(PR_SVE_SET_VL, unsigned long arg)

flags:

PR_SVE_SET_VL_INHERIT
PR_SVE_VL_INHERIT

Inherit the current vector length across execve(). Otherwise, the
vector length is reset to the system default at execve(). (See
Expand Down Expand Up @@ -247,7 +247,7 @@ prctl(PR_SVE_GET_VL)

The following flag may be OR-ed into the result:

PR_SVE_SET_VL_INHERIT
PR_SVE_VL_INHERIT

Vector length will be inherited across execve().

Expand Down Expand Up @@ -393,7 +393,7 @@ The regset data starts with struct user_sve_header, containing:
* At every execve() call, the new vector length of the new process is set to
the system default vector length, unless

* PR_SVE_SET_VL_INHERIT (or equivalently SVE_PT_VL_INHERIT) is set for the
* PR_SVE_VL_INHERIT (or equivalently SVE_PT_VL_INHERIT) is set for the
calling thread, or

* a deferred vector length change is pending, established via the
Expand Down
9 changes: 1 addition & 8 deletions Documentation/block/bfq-iosched.rst
Original file line number Diff line number Diff line change
Expand Up @@ -492,13 +492,6 @@ set max_budget to higher values than those to which BFQ would have set
it with auto-tuning. An alternative way to achieve this goal is to
just increase the value of timeout_sync, leaving max_budget equal to 0.

weights
-------

Read-only parameter, used to show the weights of the currently active
BFQ queues.


4. Group scheduling with BFQ
============================

Expand Down Expand Up @@ -566,7 +559,7 @@ Parameters to set
For each group, there is only the following parameter to set.

weight (namely blkio.bfq.weight or io.bfq-weight): the weight of the
group inside its parent. Available values: 1..10000 (default 100). The
group inside its parent. Available values: 1..1000 (default 100). The
linear mapping between ioprio and weights, described at the beginning
of the tunable section, is still valid, but all weights higher than
IOPRIO_BE_NR*10 are mapped to ioprio 0.
Expand Down
14 changes: 14 additions & 0 deletions Documentation/bpf/prog_cgroup_sockopt.rst
Original file line number Diff line number Diff line change
Expand Up @@ -86,6 +86,20 @@ then the next program in the chain (A) will see those changes,
*not* the original input ``setsockopt`` arguments. The potentially
modified values will be then passed down to the kernel.

Large optval
============
When the ``optval`` is greater than the ``PAGE_SIZE``, the BPF program
can access only the first ``PAGE_SIZE`` of that data. So it has to options:

* Set ``optlen`` to zero, which indicates that the kernel should
use the original buffer from the userspace. Any modifications
done by the BPF program to the ``optval`` are ignored.
* Set ``optlen`` to the value less than ``PAGE_SIZE``, which
indicates that the kernel should use BPF's trimmed ``optval``.

When the BPF program returns with the ``optlen`` greater than
``PAGE_SIZE``, the userspace will receive ``EFAULT`` errno.

Example
=======

Expand Down
8 changes: 8 additions & 0 deletions Documentation/core-api/dma-api.rst
Original file line number Diff line number Diff line change
Expand Up @@ -204,6 +204,14 @@ Returns the maximum size of a mapping for the device. The size parameter
of the mapping functions like dma_map_single(), dma_map_page() and
others should not be larger than the returned value.

::

bool
dma_need_sync(struct device *dev, dma_addr_t dma_addr);

Returns %true if dma_sync_single_for_{device,cpu} calls are required to
transfer memory ownership. Returns %false if those calls can be skipped.

::

unsigned long
Expand Down
2 changes: 1 addition & 1 deletion Documentation/core-api/pin_user_pages.rst
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ all combinations of get*(), pin*(), FOLL_LONGTERM, and more. Also, the
pin_user_pages*() APIs are clearly distinct from the get_user_pages*() APIs, so
that's a natural dividing line, and a good point to make separate wrapper calls.
In other words, use pin_user_pages*() for DMA-pinned pages, and
get_user_pages*() for other cases. There are four cases described later on in
get_user_pages*() for other cases. There are five cases described later on in
this document, to further clarify that concept.

FOLL_PIN and FOLL_GET are mutually exclusive for a given gup call. However,
Expand Down
6 changes: 0 additions & 6 deletions Documentation/dev-tools/kcsan.rst
Original file line number Diff line number Diff line change
Expand Up @@ -114,12 +114,6 @@ the below options are available:
To dynamically limit for which functions to generate reports, see the
`DebugFS interface`_ blacklist/whitelist feature.

For ``__always_inline`` functions, replace ``__always_inline`` with
``__no_kcsan_or_inline`` (which implies ``__always_inline``)::

static __no_kcsan_or_inline void foo(void) {
...

* To disable data race detection for a particular compilation unit, add to the
``Makefile``::

Expand Down
40 changes: 40 additions & 0 deletions Documentation/dev-tools/kunit/faq.rst
Original file line number Diff line number Diff line change
Expand Up @@ -61,3 +61,43 @@ test, or an end-to-end test.
kernel by installing a production configuration of the kernel on production
hardware with a production userspace and then trying to exercise some behavior
that depends on interactions between the hardware, the kernel, and userspace.

KUnit isn't working, what should I do?
======================================

Unfortunately, there are a number of things which can break, but here are some
things to try.

1. Try running ``./tools/testing/kunit/kunit.py run`` with the ``--raw_output``
parameter. This might show details or error messages hidden by the kunit_tool
parser.
2. Instead of running ``kunit.py run``, try running ``kunit.py config``,
``kunit.py build``, and ``kunit.py exec`` independently. This can help track
down where an issue is occurring. (If you think the parser is at fault, you
can run it manually against stdin or a file with ``kunit.py parse``.)
3. Running the UML kernel directly can often reveal issues or error messages
kunit_tool ignores. This should be as simple as running ``./vmlinux`` after
building the UML kernel (e.g., by using ``kunit.py build``). Note that UML
has some unusual requirements (such as the host having a tmpfs filesystem
mounted), and has had issues in the past when built statically and the host
has KASLR enabled. (On older host kernels, you may need to run ``setarch
`uname -m` -R ./vmlinux`` to disable KASLR.)
4. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test
(e.g. ``CONFIG_KUNIT_EXAMPLE_TEST=y``). kunit_tool will keep its .config
around, so you can see what config was used after running ``kunit.py run``.
It also preserves any config changes you might make, so you can
enable/disable things with ``make ARCH=um menuconfig`` or similar, and then
re-run kunit_tool.
5. Try to run ``make ARCH=um defconfig`` before running ``kunit.py run``. This
may help clean up any residual config items which could be causing problems.
6. Finally, try running KUnit outside UML. KUnit and KUnit tests can run be
built into any kernel, or can be built as a module and loaded at runtime.
Doing so should allow you to determine if UML is causing the issue you're
seeing. When tests are built-in, they will execute when the kernel boots, and
modules will automatically execute associated tests when loaded. Test results
can be collected from ``/sys/kernel/debug/kunit/<test suite>/results``, and
can be parsed with ``kunit.py parse``. For more details, see "KUnit on
non-UML architectures" in :doc:`usage`.

If none of the above tricks help, you are always welcome to email any issues to
[email protected].
Loading

0 comments on commit 103f528

Please sign in to comment.