Skip to content

Commit

Permalink
Merge tag 'asoc-v5.6' of https://git.kernel.org/pub/scm/linux/kernel/…
Browse files Browse the repository at this point in the history 
…git/broonie/sound into for-linus

ASoC: Updates for v5.6

A pretty big release this time around, a lot of new drivers and both
Morimoto-san and Takashi were doing subsystem wide updates as well:

 - Further big refactorings from Morimoto-san simplifying the core
   interfaces and moving things to the component level.
 - Transition of drivers to managed buffer allocation and removal of
   redundant PCM ioctls.
 - New driver support for Ingenic JZ4770, Mediatek MT6660, Qualcomm
   WCD934x and WSA881x, and Realtek RT700, RT711, RT715, RT1011, RT1015
   and RT1308.
  • Loading branch information
Takashi Iwai committed Jan 27, 2020
2 parents 9b132f2 + a7196ca commit 90fb04f
Show file tree
Hide file tree
Showing 1,813 changed files with 38,893 additions and 13,010 deletions.
5 changes: 5 additions & 0 deletions .mailmap
View file
Original file line number Diff line number Diff line change
Expand Up @@ -99,6 +99,7 @@ Jacob Shin <Jacob.Shin@amd.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@google.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@motorola.com>
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk.kim@samsung.com>
Jakub Kicinski <kuba@kernel.org> <jakub.kicinski@netronome.com>
James Bottomley <jejb@mulgrave.(none)>
James Bottomley <jejb@titanic.il.steeleye.com>
James E Wilson <wilson@specifix.com>
Expand Down Expand Up @@ -152,6 +153,7 @@ Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
Lukasz Luba <lukasz.luba@arm.com> <l.luba@partner.samsung.com>
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
Marc Zyngier <maz@kernel.org> <marc.zyngier@arm.com>
Marcin Nowakowski <marcin.nowakowski@mips.com> <marcin.nowakowski@imgtec.com>
Expand Down Expand Up @@ -265,6 +267,7 @@ Vinod Koul <vkoul@kernel.org> <vkoul@infradead.org>
Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com>
Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com>
Viresh Kumar <vireshk@kernel.org> <viresh.kumar2@arm.com>
Vivien Didelot <vivien.didelot@gmail.com> <vivien.didelot@savoirfairelinux.com>
Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com>
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@virtuozzo.com>
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@parallels.com>
Expand All @@ -276,3 +279,5 @@ Gustavo Padovan <gustavo@las.ic.unicamp.br>
Gustavo Padovan <padovan@profusion.mobi>
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
Steve Wise <larrystevenwise@gmail.com> <swise@chelsio.com>
Steve Wise <larrystevenwise@gmail.com> <swise@opengridcomputing.com>
13 changes: 11 additions & 2 deletions Documentation/ABI/stable/sysfs-driver-mlxreg-io
View file
Original file line number Diff line number Diff line change
Expand Up @@ -29,13 +29,13 @@ Description: This file shows the system fans direction:

The files are read only.

What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/jtag_enable
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_version

Date: November 2018
KernelVersion: 5.0
Contact: Vadim Pasternak <vadimpmellanox.com>
Description: These files show with which CPLD versions have been burned
on LED board.
on LED or Gearbox board.

The files are read only.

Expand Down Expand Up @@ -121,6 +121,15 @@ Description: These files show the system reset cause, as following: ComEx

The files are read only.

What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_version
Date: November 2018
KernelVersion: 5.0
Contact: Vadim Pasternak <vadimpmellanox.com>
Description: These files show with which CPLD versions have been burned
on LED board.

The files are read only.

Date: June 2019
KernelVersion: 5.3
Contact: Vadim Pasternak <vadimpmellanox.com>
Expand Down
10 changes: 5 additions & 5 deletions Documentation/ABI/testing/sysfs-platform-mellanox-bootctl
View file
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
What: /sys/bus/platform/devices/MLNXBF04:00/driver/lifecycle_state
What: /sys/bus/platform/devices/MLNXBF04:00/lifecycle_state
Date: Oct 2019
KernelVersion: 5.5
Contact: "Liming Sun <lsun@mellanox.com>"
Expand All @@ -10,7 +10,7 @@ Description:
GA Non-Secured - Non-Secure chip and not able to change state
RMA - Return Merchandise Authorization

What: /sys/bus/platform/devices/MLNXBF04:00/driver/post_reset_wdog
What: /sys/bus/platform/devices/MLNXBF04:00/post_reset_wdog
Date: Oct 2019
KernelVersion: 5.5
Contact: "Liming Sun <lsun@mellanox.com>"
Expand All @@ -19,7 +19,7 @@ Description:
to reboot the chip and recover it to the old state if the new
boot partition fails.

What: /sys/bus/platform/devices/MLNXBF04:00/driver/reset_action
What: /sys/bus/platform/devices/MLNXBF04:00/reset_action
Date: Oct 2019
KernelVersion: 5.5
Contact: "Liming Sun <lsun@mellanox.com>"
Expand All @@ -30,7 +30,7 @@ Description:
emmc - boot from the onchip eMMC
emmc_legacy - boot from the onchip eMMC in legacy (slow) mode

What: /sys/bus/platform/devices/MLNXBF04:00/driver/second_reset_action
What: /sys/bus/platform/devices/MLNXBF04:00/second_reset_action
Date: Oct 2019
KernelVersion: 5.5
Contact: "Liming Sun <lsun@mellanox.com>"
Expand All @@ -44,7 +44,7 @@ Description:
swap_emmc - swap the primary / secondary boot partition
none - cancel the action

What: /sys/bus/platform/devices/MLNXBF04:00/driver/secure_boot_fuse_state
What: /sys/bus/platform/devices/MLNXBF04:00/secure_boot_fuse_state
Date: Oct 2019
KernelVersion: 5.5
Contact: "Liming Sun <lsun@mellanox.com>"
Expand Down
2 changes: 1 addition & 1 deletion Documentation/admin-guide/device-mapper/dm-integrity.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -144,7 +144,7 @@ journal_crypt:algorithm(:key) (the key is optional)
Encrypt the journal using given algorithm to make sure that the
attacker can't read the journal. You can use a block cipher here
(such as "cbc(aes)") or a stream cipher (for example "chacha20",
"salsa20", "ctr(aes)" or "ecb(arc4)").
"salsa20" or "ctr(aes)").

The journal contains history of last writes to the block device,
an attacker reading the journal could see the last sector nubmers
Expand Down
1 change: 1 addition & 0 deletions Documentation/admin-guide/device-mapper/index.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@ Device Mapper
cache-policies
cache
delay
dm-clone
dm-crypt
dm-dust
dm-flakey
Expand Down
2 changes: 1 addition & 1 deletion Documentation/admin-guide/devices.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -319,7 +319,7 @@
182 = /dev/perfctr Performance-monitoring counters
183 = /dev/hwrng Generic random number generator
184 = /dev/cpu/microcode CPU microcode update interface
186 = /dev/atomicps Atomic shapshot of process state data
186 = /dev/atomicps Atomic snapshot of process state data
187 = /dev/irnet IrNET device
188 = /dev/smbusbios SMBus BIOS
189 = /dev/ussp_ctl User space serial port control
Expand Down
19 changes: 11 additions & 8 deletions Documentation/admin-guide/ext4.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -181,14 +181,17 @@ When mounting an ext4 filesystem, the following option are accepted:
system after its metadata has been committed to the journal.

commit=nrsec (*)
Ext4 can be told to sync all its data and metadata every 'nrsec'
seconds. The default value is 5 seconds. This means that if you lose
your power, you will lose as much as the latest 5 seconds of work (your
filesystem will not be damaged though, thanks to the journaling). This
default value (or any low value) will hurt performance, but it's good
for data-safety. Setting it to 0 will have the same effect as leaving
it at the default (5 seconds). Setting it to very large values will
improve performance.
This setting limits the maximum age of the running transaction to
'nrsec' seconds. The default value is 5 seconds. This means that if
you lose your power, you will lose as much as the latest 5 seconds of
metadata changes (your filesystem will not be damaged though, thanks
to the journaling). This default value (or any low value) will hurt
performance, but it's good for data-safety. Setting it to 0 will have
the same effect as leaving it at the default (5 seconds). Setting it
to very large values will improve performance. Note that due to
delayed allocation even older data can be lost on power failure since
writeback of those data begins only after time set in
/proc/sys/vm/dirty_expire_centisecs.

barrier=<0|1(*)>, barrier(*), nobarrier
This enables/disables the use of write barriers in the jbd code.
Expand Down
2 changes: 1 addition & 1 deletion Documentation/admin-guide/xfs.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -253,7 +253,7 @@ The following sysctls are available for the XFS filesystem:
pool.

fs.xfs.speculative_prealloc_lifetime
(Units: seconds Min: 1 Default: 300 Max: 86400)
(Units: seconds Min: 1 Default: 300 Max: 86400)
The interval at which the background scanning for inodes
with unused speculative preallocation runs. The scan
removes unused preallocation from clean inodes and releases
Expand Down
10 changes: 5 additions & 5 deletions Documentation/dev-tools/kcov.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -251,11 +251,11 @@ selectively from different subsystems.
.. code-block:: c
struct kcov_remote_arg {
unsigned trace_mode;
unsigned area_size;
unsigned num_handles;
uint64_t common_handle;
uint64_t handles[0];
__u32 trace_mode;
__u32 area_size;
__u32 num_handles;
__aligned_u64 common_handle;
__aligned_u64 handles[0];
};
#define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
Expand Down
8 changes: 4 additions & 4 deletions Documentation/dev-tools/kselftest.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -203,12 +203,12 @@ Test Module
Kselftest tests the kernel from userspace. Sometimes things need
testing from within the kernel, one method of doing this is to create a
test module. We can tie the module into the kselftest framework by
using a shell script test runner. ``kselftest_module.sh`` is designed
using a shell script test runner. ``kselftest/module.sh`` is designed
to facilitate this process. There is also a header file provided to
assist writing kernel modules that are for use with kselftest:

- ``tools/testing/kselftest/kselftest_module.h``
- ``tools/testing/kselftest/kselftest_module.sh``
- ``tools/testing/kselftest/kselftest/module.sh``

How to use
----------
Expand Down Expand Up @@ -247,7 +247,7 @@ A bare bones test module might look like this:
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include "../tools/testing/selftests/kselftest_module.h"
#include "../tools/testing/selftests/kselftest/module.h"
KSTM_MODULE_GLOBALS();
Expand Down Expand Up @@ -276,7 +276,7 @@ Example test script
#!/bin/bash
# SPDX-License-Identifier: GPL-2.0+
$(dirname $0)/../kselftest_module.sh "foo" test_foo
$(dirname $0)/../kselftest/module.sh "foo" test_foo
Test Harness
Expand Down
1 change: 1 addition & 0 deletions Documentation/dev-tools/kunit/index.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,7 @@ KUnit - Unit Testing for the Linux Kernel

start
usage
kunit-tool
api/index
faq

Expand Down
57 changes: 57 additions & 0 deletions Documentation/dev-tools/kunit/kunit-tool.rst
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
.. SPDX-License-Identifier: GPL-2.0
=================
kunit_tool How-To
=================

What is kunit_tool?
===================

kunit_tool is a script (``tools/testing/kunit/kunit.py``) that aids in building
the Linux kernel as UML (`User Mode Linux
<http://user-mode-linux.sourceforge.net/>`_), running KUnit tests, parsing
the test results and displaying them in a user friendly manner.

What is a kunitconfig?
======================

It's just a defconfig that kunit_tool looks for in the base directory.
kunit_tool uses it to generate a .config as you might expect. In addition, it
verifies that the generated .config contains the CONFIG options in the
kunitconfig; the reason it does this is so that it is easy to be sure that a
CONFIG that enables a test actually ends up in the .config.

How do I use kunit_tool?
========================

If a kunitconfig is present at the root directory, all you have to do is:

.. code-block:: bash
./tools/testing/kunit/kunit.py run
However, you most likely want to use it with the following options:

.. code-block:: bash
./tools/testing/kunit/kunit.py run --timeout=30 --jobs=`nproc --all`
- ``--timeout`` sets a maximum amount of time to allow tests to run.
- ``--jobs`` sets the number of threads to use to build the kernel.

If you just want to use the defconfig that ships with the kernel, you can
append the ``--defconfig`` flag as well:

.. code-block:: bash
./tools/testing/kunit/kunit.py run --timeout=30 --jobs=`nproc --all` --defconfig
.. note::
This command is particularly helpful for getting started because it
just works. No kunitconfig needs to be present.

For a list of all the flags supported by kunit_tool, you can run:

.. code-block:: bash
./tools/testing/kunit/kunit.py run --help
26 changes: 13 additions & 13 deletions Documentation/dev-tools/kunit/start.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -19,21 +19,21 @@ The wrapper can be run with:

.. code-block:: bash
./tools/testing/kunit/kunit.py run
./tools/testing/kunit/kunit.py run --defconfig
Creating a kunitconfig
======================
The Python script is a thin wrapper around Kbuild as such, it needs to be
configured with a ``kunitconfig`` file. This file essentially contains the
For more information on this wrapper (also called kunit_tool) checkout the
:doc:`kunit-tool` page.

Creating a .kunitconfig
=======================
The Python script is a thin wrapper around Kbuild. As such, it needs to be
configured with a ``.kunitconfig`` file. This file essentially contains the
regular Kernel config, with the specific test targets as well.

.. code-block:: bash
git clone -b master https://kunit.googlesource.com/kunitconfig $PATH_TO_KUNITCONFIG_REPO
cd $PATH_TO_LINUX_REPO
ln -s $PATH_TO_KUNIT_CONFIG_REPO/kunitconfig kunitconfig
You may want to add kunitconfig to your local gitignore.
cp arch/um/configs/kunit_defconfig .kunitconfig
Verifying KUnit Works
---------------------
Expand All @@ -59,8 +59,8 @@ If everything worked correctly, you should see the following:
followed by a list of tests that are run. All of them should be passing.

.. note::
Because it is building a lot of sources for the first time, the ``Building
kunit kernel`` step may take a while.
Because it is building a lot of sources for the first time, the
``Building KUnit kernel`` step may take a while.

Writing your first test
=======================
Expand Down Expand Up @@ -148,7 +148,7 @@ and the following to ``drivers/misc/Makefile``:
obj-$(CONFIG_MISC_EXAMPLE_TEST) += example-test.o
Now add it to your ``kunitconfig``:
Now add it to your ``.kunitconfig``:

.. code-block:: none
Expand All @@ -159,7 +159,7 @@ Now you can run the test:

.. code-block:: bash
./tools/testing/kunit/kunit.py
./tools/testing/kunit/kunit.py run
You should see the following failure:

Expand Down
Loading

0 comments on commit 90fb04f

Please sign in to comment.