mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
synced 2025-01-10 07:50:04 +00:00
Merge remote-tracking branch 'net-next/master' into mac80211-next
Merging to get the mac80211 updates that have since propagated into net-next. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This commit is contained in:
commit
7d6aa9ba4f
4
.mailmap
4
.mailmap
@ -152,6 +152,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>
|
||||
@ -265,6 +266,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>
|
||||
@ -276,3 +278,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>
|
||||
|
@ -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>"
|
||||
@ -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>"
|
||||
@ -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>"
|
||||
@ -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>"
|
||||
@ -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>"
|
||||
|
@ -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
|
||||
|
@ -8,6 +8,7 @@ Device Mapper
|
||||
cache-policies
|
||||
cache
|
||||
delay
|
||||
dm-clone
|
||||
dm-crypt
|
||||
dm-dust
|
||||
dm-flakey
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
----------
|
||||
@ -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();
|
||||
|
||||
@ -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
|
||||
|
@ -9,6 +9,7 @@ KUnit - Unit Testing for the Linux Kernel
|
||||
|
||||
start
|
||||
usage
|
||||
kunit-tool
|
||||
api/index
|
||||
faq
|
||||
|
||||
|
57
Documentation/dev-tools/kunit/kunit-tool.rst
Normal file
57
Documentation/dev-tools/kunit/kunit-tool.rst
Normal file
@ -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
|
@ -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
|
||||
---------------------
|
||||
@ -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
|
||||
=======================
|
||||
@ -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
|
||||
|
||||
@ -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:
|
||||
|
||||
|
@ -16,7 +16,7 @@ Organization of this document
|
||||
=============================
|
||||
|
||||
This document is organized into two main sections: Testing and Isolating
|
||||
Behavior. The first covers what a unit test is and how to use KUnit to write
|
||||
Behavior. The first covers what unit tests are and how to use KUnit to write
|
||||
them. The second covers how to use KUnit to isolate code and make it possible
|
||||
to unit test code that was otherwise un-unit-testable.
|
||||
|
||||
@ -174,13 +174,13 @@ Test Suites
|
||||
~~~~~~~~~~~
|
||||
|
||||
Now obviously one unit test isn't very helpful; the power comes from having
|
||||
many test cases covering all of your behaviors. Consequently it is common to
|
||||
have many *similar* tests; in order to reduce duplication in these closely
|
||||
related tests most unit testing frameworks provide the concept of a *test
|
||||
suite*, in KUnit we call it a *test suite*; all it is is just a collection of
|
||||
test cases for a unit of code with a set up function that gets invoked before
|
||||
every test cases and then a tear down function that gets invoked after every
|
||||
test case completes.
|
||||
many test cases covering all of a unit's behaviors. Consequently it is common
|
||||
to have many *similar* tests; in order to reduce duplication in these closely
|
||||
related tests most unit testing frameworks - including KUnit - provide the
|
||||
concept of a *test suite*. A *test suite* is just a collection of test cases
|
||||
for a unit of code with a set up function that gets invoked before every test
|
||||
case and then a tear down function that gets invoked after every test case
|
||||
completes.
|
||||
|
||||
Example:
|
||||
|
||||
@ -211,7 +211,7 @@ KUnit test framework.
|
||||
.. note::
|
||||
A test case will only be run if it is associated with a test suite.
|
||||
|
||||
For a more information on these types of things see the :doc:`api/test`.
|
||||
For more information on these types of things see the :doc:`api/test`.
|
||||
|
||||
Isolating Behavior
|
||||
==================
|
||||
@ -338,7 +338,7 @@ We can easily test this code by *faking out* the underlying EEPROM:
|
||||
return count;
|
||||
}
|
||||
|
||||
ssize_t fake_eeprom_write(struct eeprom *this, size_t offset, const char *buffer, size_t count)
|
||||
ssize_t fake_eeprom_write(struct eeprom *parent, size_t offset, const char *buffer, size_t count)
|
||||
{
|
||||
struct fake_eeprom *this = container_of(parent, struct fake_eeprom, parent);
|
||||
|
||||
@ -454,7 +454,7 @@ KUnit on non-UML architectures
|
||||
By default KUnit uses UML as a way to provide dependencies for code under test.
|
||||
Under most circumstances KUnit's usage of UML should be treated as an
|
||||
implementation detail of how KUnit works under the hood. Nevertheless, there
|
||||
are instances where being able to run architecture specific code, or test
|
||||
are instances where being able to run architecture specific code or test
|
||||
against real hardware is desirable. For these reasons KUnit supports running on
|
||||
other architectures.
|
||||
|
||||
@ -557,7 +557,7 @@ run your tests on your hardware setup just by compiling for your architecture.
|
||||
.. important::
|
||||
Always prefer tests that run on UML to tests that only run under a particular
|
||||
architecture, and always prefer tests that run under QEMU or another easy
|
||||
(and monitarily free) to obtain software environment to a specific piece of
|
||||
(and monetarily free) to obtain software environment to a specific piece of
|
||||
hardware.
|
||||
|
||||
Nevertheless, there are still valid reasons to write an architecture or hardware
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner platforms device tree bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A64 Display Engine Bus Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A23 RSB Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#address-cells":
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner Clock Control Unit Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#clock-cells":
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 Security System Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A31 MIPI-DSI Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#address-cells": true
|
||||
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Ronbo RB070D30 DSI Display Panel
|
||||
|
||||
maintainers:
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 DMA Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: "dma-controller.yaml#"
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A64 DMA Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: "dma-controller.yaml#"
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A31 DMA Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: "dma-controller.yaml#"
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A31 P2WI (Push/Pull 2 Wires Interface) Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/i2c/i2c-controller.yaml#
|
||||
|
@ -1,4 +1,4 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/iio/adc/adi,ad7292.yaml#
|
||||
@ -53,7 +53,8 @@ patternProperties:
|
||||
description: |
|
||||
The channel number. It can have up to 8 channels numbered from 0 to 7.
|
||||
items:
|
||||
maximum: 7
|
||||
- minimum: 0
|
||||
maximum: 7
|
||||
|
||||
diff-channels:
|
||||
description: see Documentation/devicetree/bindings/iio/adc/adc.txt
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A33 Thermal Sensor Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#io-channel-cells":
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 LRADC Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 Interrupt Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/interrupt-controller.yaml#
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A20 Non-Maskable Interrupt Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/interrupt-controller.yaml#
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 CMOS Sensor Interface (CSI) Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
description: |-
|
||||
The Allwinner A10 and later has a CMOS Sensor Interface to retrieve
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 Infrared Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: "rc.yaml#"
|
||||
|
@ -60,7 +60,8 @@ patternProperties:
|
||||
maximum: 1066000000
|
||||
|
||||
nvidia,emem-configuration:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
description: |
|
||||
Values to be written to the EMEM register block. See section
|
||||
"15.6.1 MC Registers" in the TRM.
|
||||
|
@ -56,7 +56,8 @@ patternProperties:
|
||||
maximum: 900000000
|
||||
|
||||
nvidia,emc-auto-cal-interval:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
Pad calibration interval in microseconds.
|
||||
minimum: 0
|
||||
@ -78,7 +79,8 @@ patternProperties:
|
||||
Mode Register 0.
|
||||
|
||||
nvidia,emc-zcal-cnt-long:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
Number of EMC clocks to wait before issuing any commands after
|
||||
sending ZCAL_MRW_CMD.
|
||||
@ -96,7 +98,8 @@ patternProperties:
|
||||
FBIO "read" FIFO periodic resetting enabled.
|
||||
|
||||
nvidia,emc-configuration:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
description:
|
||||
EMC timing characterization data. These are the registers
|
||||
(see section "18.13.2 EMC Registers" in the TRM) whose values
|
||||
|
@ -77,7 +77,8 @@ patternProperties:
|
||||
maximum: 900000000
|
||||
|
||||
nvidia,emem-configuration:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
description: |
|
||||
Values to be written to the EMEM register block. See section
|
||||
"18.13.1 MC Registers" in the TRM.
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 Resistive Touchscreen Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#thermal-sensor-cells":
|
||||
|
@ -11,7 +11,7 @@ allOf:
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#address-cells": true
|
||||
|
@ -11,7 +11,7 @@ allOf:
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#address-cells": true
|
||||
|
@ -11,7 +11,7 @@ allOf:
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 MDIO Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: "mdio.yaml#"
|
||||
|
@ -11,7 +11,7 @@ allOf:
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A83t EMAC Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 CAN Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -10,7 +10,6 @@ Required properties:
|
||||
- #size-cells: 0
|
||||
- spi-max-frequency: Maximum frequency of the SPI bus the chip can
|
||||
operate at should be less than or equal to 18 MHz.
|
||||
- device-wake-gpios: Wake up GPIO to wake up the TCAN device.
|
||||
- interrupt-parent: the phandle to the interrupt controller which provides
|
||||
the interrupt.
|
||||
- interrupts: interrupt specification for data-ready.
|
||||
@ -23,6 +22,7 @@ Optional properties:
|
||||
reset.
|
||||
- device-state-gpios: Input GPIO that indicates if the device is in
|
||||
a sleep state or if the device is active.
|
||||
- device-wake-gpios: Wake up GPIO to wake up the TCAN device.
|
||||
|
||||
Example:
|
||||
tcan4x5x: tcan4x5x@0 {
|
||||
@ -36,5 +36,5 @@ tcan4x5x: tcan4x5x@0 {
|
||||
interrupts = <14 GPIO_ACTIVE_LOW>;
|
||||
device-state-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
|
||||
device-wake-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
|
||||
reset-gpios = <&gpio1 27 GPIO_ACTIVE_LOW>;
|
||||
reset-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
|
148
Documentation/devicetree/bindings/net/dsa/ar9331.txt
Normal file
148
Documentation/devicetree/bindings/net/dsa/ar9331.txt
Normal file
@ -0,0 +1,148 @@
|
||||
Atheros AR9331 built-in switch
|
||||
=============================
|
||||
|
||||
It is a switch built-in to Atheros AR9331 WiSoC and addressable over internal
|
||||
MDIO bus. All PHYs are built-in as well.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: should be: "qca,ar9331-switch"
|
||||
- reg: Address on the MII bus for the switch.
|
||||
- resets : Must contain an entry for each entry in reset-names.
|
||||
- reset-names : Must include the following entries: "switch"
|
||||
- interrupt-parent: Phandle to the parent interrupt controller
|
||||
- interrupts: IRQ line for the switch
|
||||
- interrupt-controller: Indicates the switch is itself an interrupt
|
||||
controller. This is used for the PHY interrupts.
|
||||
- #interrupt-cells: must be 1
|
||||
- mdio: Container of PHY and devices on the switches MDIO bus.
|
||||
|
||||
See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
|
||||
required and optional properties.
|
||||
Examples:
|
||||
|
||||
eth0: ethernet@19000000 {
|
||||
compatible = "qca,ar9330-eth";
|
||||
reg = <0x19000000 0x200>;
|
||||
interrupts = <4>;
|
||||
|
||||
resets = <&rst 9>, <&rst 22>;
|
||||
reset-names = "mac", "mdio";
|
||||
clocks = <&pll ATH79_CLK_AHB>, <&pll ATH79_CLK_AHB>;
|
||||
clock-names = "eth", "mdio";
|
||||
|
||||
phy-mode = "mii";
|
||||
phy-handle = <&phy_port4>;
|
||||
};
|
||||
|
||||
eth1: ethernet@1a000000 {
|
||||
compatible = "qca,ar9330-eth";
|
||||
reg = <0x1a000000 0x200>;
|
||||
interrupts = <5>;
|
||||
resets = <&rst 13>, <&rst 23>;
|
||||
reset-names = "mac", "mdio";
|
||||
clocks = <&pll ATH79_CLK_AHB>, <&pll ATH79_CLK_AHB>;
|
||||
clock-names = "eth", "mdio";
|
||||
|
||||
phy-mode = "gmii";
|
||||
|
||||
fixed-link {
|
||||
speed = <1000>;
|
||||
full-duplex;
|
||||
};
|
||||
|
||||
mdio {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
switch10: switch@10 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
compatible = "qca,ar9331-switch";
|
||||
reg = <0x10>;
|
||||
resets = <&rst 8>;
|
||||
reset-names = "switch";
|
||||
|
||||
interrupt-parent = <&miscintc>;
|
||||
interrupts = <12>;
|
||||
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
switch_port0: port@0 {
|
||||
reg = <0x0>;
|
||||
label = "cpu";
|
||||
ethernet = <ð1>;
|
||||
|
||||
phy-mode = "gmii";
|
||||
|
||||
fixed-link {
|
||||
speed = <1000>;
|
||||
full-duplex;
|
||||
};
|
||||
};
|
||||
|
||||
switch_port1: port@1 {
|
||||
reg = <0x1>;
|
||||
phy-handle = <&phy_port0>;
|
||||
phy-mode = "internal";
|
||||
};
|
||||
|
||||
switch_port2: port@2 {
|
||||
reg = <0x2>;
|
||||
phy-handle = <&phy_port1>;
|
||||
phy-mode = "internal";
|
||||
};
|
||||
|
||||
switch_port3: port@3 {
|
||||
reg = <0x3>;
|
||||
phy-handle = <&phy_port2>;
|
||||
phy-mode = "internal";
|
||||
};
|
||||
|
||||
switch_port4: port@4 {
|
||||
reg = <0x4>;
|
||||
phy-handle = <&phy_port3>;
|
||||
phy-mode = "internal";
|
||||
};
|
||||
};
|
||||
|
||||
mdio {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
interrupt-parent = <&switch10>;
|
||||
|
||||
phy_port0: phy@0 {
|
||||
reg = <0x0>;
|
||||
interrupts = <0>;
|
||||
};
|
||||
|
||||
phy_port1: phy@1 {
|
||||
reg = <0x1>;
|
||||
interrupts = <0>;
|
||||
};
|
||||
|
||||
phy_port2: phy@2 {
|
||||
reg = <0x2>;
|
||||
interrupts = <0>;
|
||||
};
|
||||
|
||||
phy_port3: phy@3 {
|
||||
reg = <0x3>;
|
||||
interrupts = <0>;
|
||||
};
|
||||
|
||||
phy_port4: phy@4 {
|
||||
reg = <0x4>;
|
||||
interrupts = <0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
@ -14,7 +14,7 @@ Required properties:
|
||||
Should be "macirq" for the main MAC IRQ
|
||||
- clocks: Must contain a phandle for each entry in clock-names.
|
||||
- clock-names: The name of the clock listed in the clocks property. These are
|
||||
"axi", "apb", "mac_main", "ptp_ref" for MT2712 SoC
|
||||
"axi", "apb", "mac_main", "ptp_ref", "rmii_internal" for MT2712 SoC.
|
||||
- mac-address: See ethernet.txt in the same directory
|
||||
- phy-mode: See ethernet.txt in the same directory
|
||||
- mediatek,pericfg: A phandle to the syscon node that control ethernet
|
||||
@ -23,8 +23,10 @@ Required properties:
|
||||
Optional properties:
|
||||
- mediatek,tx-delay-ps: TX clock delay macro value. Default is 0.
|
||||
It should be defined for RGMII/MII interface.
|
||||
It should be defined for RMII interface when the reference clock is from MT2712 SoC.
|
||||
- mediatek,rx-delay-ps: RX clock delay macro value. Default is 0.
|
||||
It should be defined for RGMII/MII/RMII interface.
|
||||
It should be defined for RGMII/MII interface.
|
||||
It should be defined for RMII interface.
|
||||
Both delay properties need to be a multiple of 170 for RGMII interface,
|
||||
or will round down. Range 0~31*170.
|
||||
Both delay properties need to be a multiple of 550 for MII/RMII interface,
|
||||
@ -34,13 +36,20 @@ or will round down. Range 0~31*550.
|
||||
reference clock, which is from external PHYs, is connected to RXC pin
|
||||
on MT2712 SoC.
|
||||
Otherwise, is connected to TXC pin.
|
||||
- mediatek,rmii-clk-from-mac: boolean property, if present indicates that
|
||||
MT2712 SoC provides the RMII reference clock, which outputs to TXC pin only.
|
||||
- mediatek,txc-inverse: boolean property, if present indicates that
|
||||
1. tx clock will be inversed in MII/RGMII case,
|
||||
2. tx clock inside MAC will be inversed relative to reference clock
|
||||
which is from external PHYs in RMII case, and it rarely happen.
|
||||
3. the reference clock, which outputs to TXC pin will be inversed in RMII case
|
||||
when the reference clock is from MT2712 SoC.
|
||||
- mediatek,rxc-inverse: boolean property, if present indicates that
|
||||
1. rx clock will be inversed in MII/RGMII case.
|
||||
2. reference clock will be inversed when arrived at MAC in RMII case.
|
||||
2. reference clock will be inversed when arrived at MAC in RMII case, when
|
||||
the reference clock is from external PHYs.
|
||||
3. the inside clock, which be sent to MAC, will be inversed in RMII case when
|
||||
the reference clock is from MT2712 SoC.
|
||||
- assigned-clocks: mac_main and ptp_ref clocks
|
||||
- assigned-clock-parents: parent clocks of the assigned clocks
|
||||
|
||||
@ -50,29 +59,33 @@ Example:
|
||||
reg = <0 0x1101c000 0 0x1300>;
|
||||
interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-names = "macirq";
|
||||
phy-mode ="rgmii";
|
||||
phy-mode ="rgmii-rxid";
|
||||
mac-address = [00 55 7b b5 7d f7];
|
||||
clock-names = "axi",
|
||||
"apb",
|
||||
"mac_main",
|
||||
"ptp_ref",
|
||||
"ptp_top";
|
||||
"rmii_internal";
|
||||
clocks = <&pericfg CLK_PERI_GMAC>,
|
||||
<&pericfg CLK_PERI_GMAC_PCLK>,
|
||||
<&topckgen CLK_TOP_ETHER_125M_SEL>,
|
||||
<&topckgen CLK_TOP_ETHER_50M_SEL>;
|
||||
<&topckgen CLK_TOP_ETHER_50M_SEL>,
|
||||
<&topckgen CLK_TOP_ETHER_50M_RMII_SEL>;
|
||||
assigned-clocks = <&topckgen CLK_TOP_ETHER_125M_SEL>,
|
||||
<&topckgen CLK_TOP_ETHER_50M_SEL>;
|
||||
<&topckgen CLK_TOP_ETHER_50M_SEL>,
|
||||
<&topckgen CLK_TOP_ETHER_50M_RMII_SEL>;
|
||||
assigned-clock-parents = <&topckgen CLK_TOP_ETHERPLL_125M>,
|
||||
<&topckgen CLK_TOP_APLL1_D3>;
|
||||
<&topckgen CLK_TOP_APLL1_D3>,
|
||||
<&topckgen CLK_TOP_ETHERPLL_50M>;
|
||||
power-domains = <&scpsys MT2712_POWER_DOMAIN_AUDIO>;
|
||||
mediatek,pericfg = <&pericfg>;
|
||||
mediatek,tx-delay-ps = <1530>;
|
||||
mediatek,rx-delay-ps = <1530>;
|
||||
mediatek,rmii-rxc;
|
||||
mediatek,txc-inverse;
|
||||
mediatek,rxc-inverse;
|
||||
snps,txpbl = <32>;
|
||||
snps,rxpbl = <32>;
|
||||
snps,txpbl = <1>;
|
||||
snps,rxpbl = <1>;
|
||||
snps,reset-gpio = <&pio 87 GPIO_ACTIVE_LOW>;
|
||||
snps,reset-active-low;
|
||||
};
|
||||
|
@ -347,6 +347,7 @@ allOf:
|
||||
- st,spear600-gmac
|
||||
|
||||
then:
|
||||
properties:
|
||||
snps,tso:
|
||||
$ref: /schemas/types.yaml#definitions/flag
|
||||
description:
|
||||
|
@ -1,4 +1,4 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/ti,cpsw-switch.yaml#
|
||||
@ -44,7 +44,6 @@ properties:
|
||||
description: CPSW functional clock
|
||||
|
||||
clock-names:
|
||||
maxItems: 1
|
||||
items:
|
||||
- const: fck
|
||||
|
||||
@ -70,7 +69,6 @@ properties:
|
||||
Phandle to the system control device node which provides access to
|
||||
efuse IO range with MAC addresses
|
||||
|
||||
|
||||
ethernet-ports:
|
||||
type: object
|
||||
properties:
|
||||
@ -82,8 +80,6 @@ properties:
|
||||
patternProperties:
|
||||
"^port@[0-9]+$":
|
||||
type: object
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
description: CPSW external ports
|
||||
|
||||
allOf:
|
||||
@ -91,23 +87,20 @@ properties:
|
||||
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
enum: [1, 2]
|
||||
items:
|
||||
- enum: [1, 2]
|
||||
description: CPSW port number
|
||||
|
||||
phys:
|
||||
$ref: /schemas/types.yaml#definitions/phandle-array
|
||||
maxItems: 1
|
||||
description: phandle on phy-gmii-sel PHY
|
||||
|
||||
label:
|
||||
$ref: /schemas/types.yaml#/definitions/string-array
|
||||
maxItems: 1
|
||||
description: label associated with this port
|
||||
|
||||
ti,dual-emac-pvid:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
maxItems: 1
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 1
|
||||
maximum: 1024
|
||||
description:
|
||||
@ -136,7 +129,6 @@ properties:
|
||||
description: CPTS reference clock
|
||||
|
||||
clock-names:
|
||||
maxItems: 1
|
||||
items:
|
||||
- const: cpts
|
||||
|
||||
@ -201,7 +193,7 @@ examples:
|
||||
phys = <&phy_gmii_sel 1>;
|
||||
phy-handle = <ðphy0_sw>;
|
||||
phy-mode = "rgmii";
|
||||
ti,dual_emac_pvid = <1>;
|
||||
ti,dual-emac-pvid = <1>;
|
||||
};
|
||||
|
||||
cpsw_port2: port@2 {
|
||||
@ -211,7 +203,7 @@ examples:
|
||||
phys = <&phy_gmii_sel 2>;
|
||||
phy-handle = <ðphy1_sw>;
|
||||
phy-mode = "rgmii";
|
||||
ti,dual_emac_pvid = <2>;
|
||||
ti,dual-emac-pvid = <2>;
|
||||
};
|
||||
};
|
||||
|
||||
|
273
Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
Normal file
273
Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
Normal file
@ -0,0 +1,273 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (c) 2018-2019 The Linux Foundation. All rights reserved.
|
||||
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/wireless/qcom,ath11k.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Technologies ath11k wireless devices Generic Binding
|
||||
|
||||
maintainers:
|
||||
- Kalle Valo <kvalo@codeaurora.org>
|
||||
|
||||
description: |
|
||||
These are dt entries for Qualcomm Technologies, Inc. IEEE 802.11ax
|
||||
devices, for example like AHB based IPQ8074.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,ipq8074-wifi
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
items:
|
||||
- description: misc-pulse1 interrupt events
|
||||
- description: misc-latch interrupt events
|
||||
- description: sw exception interrupt events
|
||||
- description: watchdog interrupt events
|
||||
- description: interrupt event for ring CE0
|
||||
- description: interrupt event for ring CE1
|
||||
- description: interrupt event for ring CE2
|
||||
- description: interrupt event for ring CE3
|
||||
- description: interrupt event for ring CE4
|
||||
- description: interrupt event for ring CE5
|
||||
- description: interrupt event for ring CE6
|
||||
- description: interrupt event for ring CE7
|
||||
- description: interrupt event for ring CE8
|
||||
- description: interrupt event for ring CE9
|
||||
- description: interrupt event for ring CE10
|
||||
- description: interrupt event for ring CE11
|
||||
- description: interrupt event for ring host2wbm-desc-feed
|
||||
- description: interrupt event for ring host2reo-re-injection
|
||||
- description: interrupt event for ring host2reo-command
|
||||
- description: interrupt event for ring host2rxdma-monitor-ring3
|
||||
- description: interrupt event for ring host2rxdma-monitor-ring2
|
||||
- description: interrupt event for ring host2rxdma-monitor-ring1
|
||||
- description: interrupt event for ring reo2ost-exception
|
||||
- description: interrupt event for ring wbm2host-rx-release
|
||||
- description: interrupt event for ring reo2host-status
|
||||
- description: interrupt event for ring reo2host-destination-ring4
|
||||
- description: interrupt event for ring reo2host-destination-ring3
|
||||
- description: interrupt event for ring reo2host-destination-ring2
|
||||
- description: interrupt event for ring reo2host-destination-ring1
|
||||
- description: interrupt event for ring rxdma2host-monitor-destination-mac3
|
||||
- description: interrupt event for ring rxdma2host-monitor-destination-mac2
|
||||
- description: interrupt event for ring rxdma2host-monitor-destination-mac1
|
||||
- description: interrupt event for ring ppdu-end-interrupts-mac3
|
||||
- description: interrupt event for ring ppdu-end-interrupts-mac2
|
||||
- description: interrupt event for ring ppdu-end-interrupts-mac1
|
||||
- description: interrupt event for ring rxdma2host-monitor-status-ring-mac3
|
||||
- description: interrupt event for ring rxdma2host-monitor-status-ring-mac2
|
||||
- description: interrupt event for ring rxdma2host-monitor-status-ring-mac1
|
||||
- description: interrupt event for ring host2rxdma-host-buf-ring-mac3
|
||||
- description: interrupt event for ring host2rxdma-host-buf-ring-mac2
|
||||
- description: interrupt event for ring host2rxdma-host-buf-ring-mac1
|
||||
- description: interrupt event for ring rxdma2host-destination-ring-mac3
|
||||
- description: interrupt event for ring rxdma2host-destination-ring-mac2
|
||||
- description: interrupt event for ring rxdma2host-destination-ring-mac1
|
||||
- description: interrupt event for ring host2tcl-input-ring4
|
||||
- description: interrupt event for ring host2tcl-input-ring3
|
||||
- description: interrupt event for ring host2tcl-input-ring2
|
||||
- description: interrupt event for ring host2tcl-input-ring1
|
||||
- description: interrupt event for ring wbm2host-tx-completions-ring3
|
||||
- description: interrupt event for ring wbm2host-tx-completions-ring2
|
||||
- description: interrupt event for ring wbm2host-tx-completions-ring1
|
||||
- description: interrupt event for ring tcl2host-status-ring
|
||||
|
||||
|
||||
interrupt-names:
|
||||
items:
|
||||
- const: misc-pulse1
|
||||
- const: misc-latch
|
||||
- const: sw-exception
|
||||
- const: watchdog
|
||||
- const: ce0
|
||||
- const: ce1
|
||||
- const: ce2
|
||||
- const: ce3
|
||||
- const: ce4
|
||||
- const: ce5
|
||||
- const: ce6
|
||||
- const: ce7
|
||||
- const: ce8
|
||||
- const: ce9
|
||||
- const: ce10
|
||||
- const: ce11
|
||||
- const: host2wbm-desc-feed
|
||||
- const: host2reo-re-injection
|
||||
- const: host2reo-command
|
||||
- const: host2rxdma-monitor-ring3
|
||||
- const: host2rxdma-monitor-ring2
|
||||
- const: host2rxdma-monitor-ring1
|
||||
- const: reo2ost-exception
|
||||
- const: wbm2host-rx-release
|
||||
- const: reo2host-status
|
||||
- const: reo2host-destination-ring4
|
||||
- const: reo2host-destination-ring3
|
||||
- const: reo2host-destination-ring2
|
||||
- const: reo2host-destination-ring1
|
||||
- const: rxdma2host-monitor-destination-mac3
|
||||
- const: rxdma2host-monitor-destination-mac2
|
||||
- const: rxdma2host-monitor-destination-mac1
|
||||
- const: ppdu-end-interrupts-mac3
|
||||
- const: ppdu-end-interrupts-mac2
|
||||
- const: ppdu-end-interrupts-mac1
|
||||
- const: rxdma2host-monitor-status-ring-mac3
|
||||
- const: rxdma2host-monitor-status-ring-mac2
|
||||
- const: rxdma2host-monitor-status-ring-mac1
|
||||
- const: host2rxdma-host-buf-ring-mac3
|
||||
- const: host2rxdma-host-buf-ring-mac2
|
||||
- const: host2rxdma-host-buf-ring-mac1
|
||||
- const: rxdma2host-destination-ring-mac3
|
||||
- const: rxdma2host-destination-ring-mac2
|
||||
- const: rxdma2host-destination-ring-mac1
|
||||
- const: host2tcl-input-ring4
|
||||
- const: host2tcl-input-ring3
|
||||
- const: host2tcl-input-ring2
|
||||
- const: host2tcl-input-ring1
|
||||
- const: wbm2host-tx-completions-ring3
|
||||
- const: wbm2host-tx-completions-ring2
|
||||
- const: wbm2host-tx-completions-ring1
|
||||
- const: tcl2host-status-ring
|
||||
|
||||
qcom,rproc:
|
||||
$ref: /schemas/types.yaml#definitions/phandle
|
||||
description:
|
||||
DT entry of q6v5-wcss remoteproc driver.
|
||||
Phandle to a node that can contain the following properties
|
||||
* compatible
|
||||
* reg
|
||||
* reg-names
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- interrupt-names
|
||||
- qcom,rproc
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
||||
q6v5_wcss: q6v5_wcss@CD00000 {
|
||||
compatible = "qcom,ipq8074-wcss-pil";
|
||||
reg = <0xCD00000 0x4040>,
|
||||
<0x4AB000 0x20>;
|
||||
reg-names = "qdsp6",
|
||||
"rmb";
|
||||
};
|
||||
|
||||
wifi0: wifi@c000000 {
|
||||
compatible = "qcom,ipq8074-wifi";
|
||||
reg = <0xc000000 0x2000000>;
|
||||
interrupts = <0 320 1>,
|
||||
<0 319 1>,
|
||||
<0 318 1>,
|
||||
<0 317 1>,
|
||||
<0 316 1>,
|
||||
<0 315 1>,
|
||||
<0 314 1>,
|
||||
<0 311 1>,
|
||||
<0 310 1>,
|
||||
<0 411 1>,
|
||||
<0 410 1>,
|
||||
<0 40 1>,
|
||||
<0 39 1>,
|
||||
<0 302 1>,
|
||||
<0 301 1>,
|
||||
<0 37 1>,
|
||||
<0 36 1>,
|
||||
<0 296 1>,
|
||||
<0 295 1>,
|
||||
<0 294 1>,
|
||||
<0 293 1>,
|
||||
<0 292 1>,
|
||||
<0 291 1>,
|
||||
<0 290 1>,
|
||||
<0 289 1>,
|
||||
<0 288 1>,
|
||||
<0 239 1>,
|
||||
<0 236 1>,
|
||||
<0 235 1>,
|
||||
<0 234 1>,
|
||||
<0 233 1>,
|
||||
<0 232 1>,
|
||||
<0 231 1>,
|
||||
<0 230 1>,
|
||||
<0 229 1>,
|
||||
<0 228 1>,
|
||||
<0 224 1>,
|
||||
<0 223 1>,
|
||||
<0 203 1>,
|
||||
<0 183 1>,
|
||||
<0 180 1>,
|
||||
<0 179 1>,
|
||||
<0 178 1>,
|
||||
<0 177 1>,
|
||||
<0 176 1>,
|
||||
<0 163 1>,
|
||||
<0 162 1>,
|
||||
<0 160 1>,
|
||||
<0 159 1>,
|
||||
<0 158 1>,
|
||||
<0 157 1>,
|
||||
<0 156 1>;
|
||||
interrupt-names = "misc-pulse1",
|
||||
"misc-latch",
|
||||
"sw-exception",
|
||||
"watchdog",
|
||||
"ce0",
|
||||
"ce1",
|
||||
"ce2",
|
||||
"ce3",
|
||||
"ce4",
|
||||
"ce5",
|
||||
"ce6",
|
||||
"ce7",
|
||||
"ce8",
|
||||
"ce9",
|
||||
"ce10",
|
||||
"ce11",
|
||||
"host2wbm-desc-feed",
|
||||
"host2reo-re-injection",
|
||||
"host2reo-command",
|
||||
"host2rxdma-monitor-ring3",
|
||||
"host2rxdma-monitor-ring2",
|
||||
"host2rxdma-monitor-ring1",
|
||||
"reo2ost-exception",
|
||||
"wbm2host-rx-release",
|
||||
"reo2host-status",
|
||||
"reo2host-destination-ring4",
|
||||
"reo2host-destination-ring3",
|
||||
"reo2host-destination-ring2",
|
||||
"reo2host-destination-ring1",
|
||||
"rxdma2host-monitor-destination-mac3",
|
||||
"rxdma2host-monitor-destination-mac2",
|
||||
"rxdma2host-monitor-destination-mac1",
|
||||
"ppdu-end-interrupts-mac3",
|
||||
"ppdu-end-interrupts-mac2",
|
||||
"ppdu-end-interrupts-mac1",
|
||||
"rxdma2host-monitor-status-ring-mac3",
|
||||
"rxdma2host-monitor-status-ring-mac2",
|
||||
"rxdma2host-monitor-status-ring-mac1",
|
||||
"host2rxdma-host-buf-ring-mac3",
|
||||
"host2rxdma-host-buf-ring-mac2",
|
||||
"host2rxdma-host-buf-ring-mac1",
|
||||
"rxdma2host-destination-ring-mac3",
|
||||
"rxdma2host-destination-ring-mac2",
|
||||
"rxdma2host-destination-ring-mac1",
|
||||
"host2tcl-input-ring4",
|
||||
"host2tcl-input-ring3",
|
||||
"host2tcl-input-ring2",
|
||||
"host2tcl-input-ring1",
|
||||
"wbm2host-tx-completions-ring3",
|
||||
"wbm2host-tx-completions-ring2",
|
||||
"wbm2host-tx-completions-ring1",
|
||||
"tcl2host-status-ring";
|
||||
qcom,rproc = <&q6v5_wcss>;
|
||||
};
|
@ -8,7 +8,7 @@ title: Allwinner A10 Security ID Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: "nvmem.yaml#"
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A31 MIPI D-PHY Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#phy-cells":
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 Pin Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#gpio-cells":
|
||||
|
35
Documentation/devicetree/bindings/ptp/ptp-ines.txt
Normal file
35
Documentation/devicetree/bindings/ptp/ptp-ines.txt
Normal file
@ -0,0 +1,35 @@
|
||||
ZHAW InES PTP time stamping IP core
|
||||
|
||||
The IP core needs two different kinds of nodes. The control node
|
||||
lives somewhere in the memory map and specifies the address of the
|
||||
control registers. There can be up to three port handles placed as
|
||||
attributes of PHY nodes. These associate a particular MII bus with a
|
||||
port index within the IP core.
|
||||
|
||||
Required properties of the control node:
|
||||
|
||||
- compatible: "ines,ptp-ctrl"
|
||||
- reg: physical address and size of the register bank
|
||||
|
||||
Required format of the port handle within the PHY node:
|
||||
|
||||
- timestamper: provides control node reference and
|
||||
the port channel within the IP core
|
||||
|
||||
Example:
|
||||
|
||||
tstamper: timestamper@60000000 {
|
||||
compatible = "ines,ptp-ctrl";
|
||||
reg = <0x60000000 0x80>;
|
||||
};
|
||||
|
||||
ethernet@80000000 {
|
||||
...
|
||||
mdio {
|
||||
...
|
||||
ethernet-phy@3 {
|
||||
...
|
||||
timestamper = <&tstamper 0>;
|
||||
};
|
||||
};
|
||||
};
|
42
Documentation/devicetree/bindings/ptp/timestamper.txt
Normal file
42
Documentation/devicetree/bindings/ptp/timestamper.txt
Normal file
@ -0,0 +1,42 @@
|
||||
Time stamps from MII bus snooping devices
|
||||
|
||||
This binding supports non-PHY devices that snoop the MII bus and
|
||||
provide time stamps. In contrast to PHY time stamping drivers (which
|
||||
can simply attach their interface directly to the PHY instance), stand
|
||||
alone MII time stamping drivers use this binding to specify the
|
||||
connection between the snooping device and a given network interface.
|
||||
|
||||
Non-PHY MII time stamping drivers typically talk to the control
|
||||
interface over another bus like I2C, SPI, UART, or via a memory mapped
|
||||
peripheral. This controller device is associated with one or more
|
||||
time stamping channels, each of which snoops on a MII bus.
|
||||
|
||||
The "timestamper" property lives in a phy node and links a time
|
||||
stamping channel from the controller device to that phy's MII bus.
|
||||
|
||||
Example:
|
||||
|
||||
tstamper: timestamper@10000000 {
|
||||
compatible = "ines,ptp-ctrl";
|
||||
reg = <0x10000000 0x80>;
|
||||
};
|
||||
|
||||
ethernet@20000000 {
|
||||
mdio {
|
||||
ethernet-phy@1 {
|
||||
timestamper = <&tstamper 0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
ethernet@30000000 {
|
||||
mdio {
|
||||
ethernet-phy@2 {
|
||||
timestamper = <&tstamper 1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
In this example, time stamps from the MII bus attached to phy@1 will
|
||||
appear on time stamp channel 0 (zero), and those from phy@2 appear on
|
||||
channel 1.
|
@ -8,7 +8,7 @@ title: Allwinner A10 PWM Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#pwm-cells":
|
||||
|
@ -50,6 +50,8 @@ properties:
|
||||
description: Should contain the WWDG1 watchdog reset interrupt
|
||||
maxItems: 1
|
||||
|
||||
wakeup-source: true
|
||||
|
||||
mboxes:
|
||||
description:
|
||||
This property is required only if the rpmsg/virtio functionality is used.
|
||||
|
@ -22,6 +22,6 @@ Example:
|
||||
};
|
||||
|
||||
ðernet_switch {
|
||||
resets = <&reset>;
|
||||
resets = <&reset 26>;
|
||||
reset-names = "switch";
|
||||
};
|
||||
|
@ -11,7 +11,7 @@ allOf:
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A31 RTC Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#clock-cells":
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 PS2 Host Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
description:
|
||||
A20 PS2 is dual role controller (PS2 host and PS2 device). These
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 Codec Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#sound-dai-cells":
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 I2S Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#sound-dai-cells":
|
||||
|
@ -10,7 +10,7 @@ maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Liam Girdwood <lgirdwood@gmail.com>
|
||||
- Mark Brown <broonie@kernel.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#sound-dai-cells":
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A64 Analog Codec Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A23 Analog Codec Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A33 Codec Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#sound-dai-cells":
|
||||
|
@ -11,7 +11,7 @@ allOf:
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#address-cells": true
|
||||
|
@ -11,7 +11,7 @@ allOf:
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
"#address-cells": true
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 Timer Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A13 High-Speed Timer Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -8,7 +8,7 @@ title: Allwinner A10 mUSB OTG Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -11,7 +11,7 @@ allOf:
|
||||
|
||||
maintainers:
|
||||
- Chen-Yu Tsai <wens@csie.org>
|
||||
- Maxime Ripard <maxime.ripard@bootlin.com>
|
||||
- Maxime Ripard <mripard@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -24,11 +24,11 @@ Here is the main features of EROFS:
|
||||
- Metadata & data could be mixed by design;
|
||||
|
||||
- 2 inode versions for different requirements:
|
||||
v1 v2
|
||||
compact (v1) extended (v2)
|
||||
Inode metadata size: 32 bytes 64 bytes
|
||||
Max file size: 4 GB 16 EB (also limited by max. vol size)
|
||||
Max uids/gids: 65536 4294967296
|
||||
File creation time: no yes (64 + 32-bit timestamp)
|
||||
File change time: no yes (64 + 32-bit timestamp)
|
||||
Max hardlinks: 65536 4294967296
|
||||
Metadata reserved: 4 bytes 14 bytes
|
||||
|
||||
@ -39,7 +39,7 @@ Here is the main features of EROFS:
|
||||
- Support POSIX.1e ACLs by using xattrs;
|
||||
|
||||
- Support transparent file compression as an option:
|
||||
LZ4 algorithm with 4 KB fixed-output compression for high performance;
|
||||
LZ4 algorithm with 4 KB fixed-sized output compression for high performance.
|
||||
|
||||
The following git tree provides the file system user-space tools under
|
||||
development (ex, formatting tool mkfs.erofs):
|
||||
@ -85,7 +85,7 @@ All data areas should be aligned with the block size, but metadata areas
|
||||
may not. All metadatas can be now observed in two different spaces (views):
|
||||
1. Inode metadata space
|
||||
Each valid inode should be aligned with an inode slot, which is a fixed
|
||||
value (32 bytes) and designed to be kept in line with v1 inode size.
|
||||
value (32 bytes) and designed to be kept in line with compact inode size.
|
||||
|
||||
Each inode can be directly found with the following formula:
|
||||
inode offset = meta_blkaddr * block_size + 32 * nid
|
||||
@ -117,10 +117,10 @@ may not. All metadatas can be now observed in two different spaces (views):
|
||||
|-> aligned with 4B
|
||||
|
||||
Inode could be 32 or 64 bytes, which can be distinguished from a common
|
||||
field which all inode versions have -- i_advise:
|
||||
field which all inode versions have -- i_format:
|
||||
|
||||
__________________ __________________
|
||||
| i_advise | | i_advise |
|
||||
| i_format | | i_format |
|
||||
|__________________| |__________________|
|
||||
| ... | | ... |
|
||||
| | | |
|
||||
@ -129,12 +129,13 @@ may not. All metadatas can be now observed in two different spaces (views):
|
||||
|__________________| 64 bytes
|
||||
|
||||
Xattrs, extents, data inline are followed by the corresponding inode with
|
||||
proper alignes, and they could be optional for different data mappings,
|
||||
_currently_ there are totally 3 valid data mappings supported:
|
||||
proper alignment, and they could be optional for different data mappings.
|
||||
_currently_ total 4 valid data mappings are supported:
|
||||
|
||||
1) flat file data without data inline (no extent);
|
||||
2) fixed-output size data compression (must have extents);
|
||||
3) flat file data with tail-end data inline (no extent);
|
||||
0 flat file data without data inline (no extent);
|
||||
1 fixed-sized output data compression (with non-compacted indexes);
|
||||
2 flat file data with tail packing data inline (no extent);
|
||||
3 fixed-sized output data compression (with compacted indexes, v5.3+).
|
||||
|
||||
The size of the optional xattrs is indicated by i_xattr_count in inode
|
||||
header. Large xattrs or xattrs shared by many different files can be
|
||||
@ -182,8 +183,8 @@ introduce another on-disk field at all.
|
||||
|
||||
Compression
|
||||
-----------
|
||||
Currently, EROFS supports 4KB fixed-output clustersize transparent file
|
||||
compression, as illustrated below:
|
||||
Currently, EROFS supports 4KB fixed-sized output transparent file compression,
|
||||
as illustrated below:
|
||||
|
||||
|---- Variant-Length Extent ----|-------- VLE --------|----- VLE -----
|
||||
clusterofs clusterofs clusterofs
|
||||
|
@ -1,3 +1,5 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
Written by: Neil Brown
|
||||
Please see MAINTAINERS file for where to send questions.
|
||||
|
||||
@ -181,7 +183,7 @@ Kernel config options:
|
||||
worried about backward compatibility with kernels that have the redirect_dir
|
||||
feature and follow redirects even if turned off.
|
||||
|
||||
Module options (can also be changed through /sys/module/overlay/parameters/*):
|
||||
Module options (can also be changed through /sys/module/overlay/parameters/):
|
||||
|
||||
- "redirect_dir=BOOL":
|
||||
See OVERLAY_FS_REDIRECT_DIR kernel config option above.
|
||||
@ -263,7 +265,7 @@ top, lower2 the middle and lower3 the bottom layer.
|
||||
|
||||
|
||||
Metadata only copy up
|
||||
--------------------
|
||||
---------------------
|
||||
|
||||
When metadata only copy up feature is enabled, overlayfs will only copy
|
||||
up metadata (as opposed to whole file), when a metadata specific operation
|
||||
@ -286,10 +288,10 @@ pointed by REDIRECT. This should not be possible on local system as setting
|
||||
"trusted." xattrs will require CAP_SYS_ADMIN. But it should be possible
|
||||
for untrusted layers like from a pen drive.
|
||||
|
||||
Note: redirect_dir={off|nofollow|follow(*)} conflicts with metacopy=on, and
|
||||
Note: redirect_dir={off|nofollow|follow[*]} conflicts with metacopy=on, and
|
||||
results in an error.
|
||||
|
||||
(*) redirect_dir=follow only conflicts with metacopy=on if upperdir=... is
|
||||
[*] redirect_dir=follow only conflicts with metacopy=on if upperdir=... is
|
||||
given.
|
||||
|
||||
Sharing and copying layers
|
@ -196,14 +196,11 @@ applicable everywhere (see syntax).
|
||||
or equal to the first symbol and smaller than or equal to the second
|
||||
symbol.
|
||||
|
||||
- help text: "help" or "---help---"
|
||||
- help text: "help"
|
||||
|
||||
This defines a help text. The end of the help text is determined by
|
||||
the indentation level, this means it ends at the first line which has
|
||||
a smaller indentation than the first line of the help text.
|
||||
"---help---" and "help" do not differ in behaviour, "---help---" is
|
||||
used to help visually separate configuration logic from help within
|
||||
the file as an aid to developers.
|
||||
|
||||
- misc options: "option" <symbol>[=<value>]
|
||||
|
||||
|
@ -297,9 +297,19 @@ more details, with real examples.
|
||||
If CONFIG_EXT2_FS is set to either 'y' (built-in) or 'm' (modular)
|
||||
the corresponding obj- variable will be set, and kbuild will descend
|
||||
down in the ext2 directory.
|
||||
Kbuild only uses this information to decide that it needs to visit
|
||||
the directory, it is the Makefile in the subdirectory that
|
||||
specifies what is modular and what is built-in.
|
||||
|
||||
Kbuild uses this information not only to decide that it needs to visit
|
||||
the directory, but also to decide whether or not to link objects from
|
||||
the directory into vmlinux.
|
||||
|
||||
When Kbuild descends into the directory with 'y', all built-in objects
|
||||
from that directory are combined into the built-in.a, which will be
|
||||
eventually linked into vmlinux.
|
||||
|
||||
When Kbuild descends into the directory with 'm', in contrast, nothing
|
||||
from that directory will be linked into vmlinux. If the Makefile in
|
||||
that directory specifies obj-y, those objects will be left orphan.
|
||||
It is very likely a bug of the Makefile or of dependencies in Kconfig.
|
||||
|
||||
It is good practice to use a `CONFIG_` variable when assigning directory
|
||||
names. This allows kbuild to totally skip the directory if the
|
||||
|
@ -230,12 +230,6 @@ simultaneously on two ports. The driver checks the consistency of the schedules
|
||||
against this restriction and errors out when appropriate. Schedule analysis is
|
||||
needed to avoid this, which is outside the scope of the document.
|
||||
|
||||
At the moment, the time-aware scheduler can only be triggered based on a
|
||||
standalone clock and not based on PTP time. This means the base-time argument
|
||||
from tc-taprio is ignored and the schedule starts right away. It also means it
|
||||
is more difficult to phase-align the scheduler with the other devices in the
|
||||
network.
|
||||
|
||||
Device Tree bindings and board design
|
||||
=====================================
|
||||
|
||||
|
520
Documentation/networking/ethtool-netlink.rst
Normal file
520
Documentation/networking/ethtool-netlink.rst
Normal file
@ -0,0 +1,520 @@
|
||||
=============================
|
||||
Netlink interface for ethtool
|
||||
=============================
|
||||
|
||||
|
||||
Basic information
|
||||
=================
|
||||
|
||||
Netlink interface for ethtool uses generic netlink family ``ethtool``
|
||||
(userspace application should use macros ``ETHTOOL_GENL_NAME`` and
|
||||
``ETHTOOL_GENL_VERSION`` defined in ``<linux/ethtool_netlink.h>`` uapi
|
||||
header). This family does not use a specific header, all information in
|
||||
requests and replies is passed using netlink attributes.
|
||||
|
||||
The ethtool netlink interface uses extended ACK for error and warning
|
||||
reporting, userspace application developers are encouraged to make these
|
||||
messages available to user in a suitable way.
|
||||
|
||||
Requests can be divided into three categories: "get" (retrieving information),
|
||||
"set" (setting parameters) and "action" (invoking an action).
|
||||
|
||||
All "set" and "action" type requests require admin privileges
|
||||
(``CAP_NET_ADMIN`` in the namespace). Most "get" type requests are allowed for
|
||||
anyone but there are exceptions (where the response contains sensitive
|
||||
information). In some cases, the request as such is allowed for anyone but
|
||||
unprivileged users have attributes with sensitive information (e.g.
|
||||
wake-on-lan password) omitted.
|
||||
|
||||
|
||||
Conventions
|
||||
===========
|
||||
|
||||
Attributes which represent a boolean value usually use NLA_U8 type so that we
|
||||
can distinguish three states: "on", "off" and "not present" (meaning the
|
||||
information is not available in "get" requests or value is not to be changed
|
||||
in "set" requests). For these attributes, the "true" value should be passed as
|
||||
number 1 but any non-zero value should be understood as "true" by recipient.
|
||||
In the tables below, "bool" denotes NLA_U8 attributes interpreted in this way.
|
||||
|
||||
In the message structure descriptions below, if an attribute name is suffixed
|
||||
with "+", parent nest can contain multiple attributes of the same type. This
|
||||
implements an array of entries.
|
||||
|
||||
|
||||
Request header
|
||||
==============
|
||||
|
||||
Each request or reply message contains a nested attribute with common header.
|
||||
Structure of this header is
|
||||
|
||||
============================== ====== =============================
|
||||
``ETHTOOL_A_HEADER_DEV_INDEX`` u32 device ifindex
|
||||
``ETHTOOL_A_HEADER_DEV_NAME`` string device name
|
||||
``ETHTOOL_A_HEADER_FLAGS`` u32 flags common for all requests
|
||||
============================== ====== =============================
|
||||
|
||||
``ETHTOOL_A_HEADER_DEV_INDEX`` and ``ETHTOOL_A_HEADER_DEV_NAME`` identify the
|
||||
device message relates to. One of them is sufficient in requests, if both are
|
||||
used, they must identify the same device. Some requests, e.g. global string
|
||||
sets, do not require device identification. Most ``GET`` requests also allow
|
||||
dump requests without device identification to query the same information for
|
||||
all devices providing it (each device in a separate message).
|
||||
|
||||
``ETHTOOL_A_HEADER_FLAGS`` is a bitmap of request flags common for all request
|
||||
types. The interpretation of these flags is the same for all request types but
|
||||
the flags may not apply to requests. Recognized flags are:
|
||||
|
||||
================================= ===================================
|
||||
``ETHTOOL_FLAG_COMPACT_BITSETS`` use compact format bitsets in reply
|
||||
``ETHTOOL_FLAG_OMIT_REPLY`` omit optional reply (_SET and _ACT)
|
||||
================================= ===================================
|
||||
|
||||
New request flags should follow the general idea that if the flag is not set,
|
||||
the behaviour is backward compatible, i.e. requests from old clients not aware
|
||||
of the flag should be interpreted the way the client expects. A client must
|
||||
not set flags it does not understand.
|
||||
|
||||
|
||||
Bit sets
|
||||
========
|
||||
|
||||
For short bitmaps of (reasonably) fixed length, standard ``NLA_BITFIELD32``
|
||||
type is used. For arbitrary length bitmaps, ethtool netlink uses a nested
|
||||
attribute with contents of one of two forms: compact (two binary bitmaps
|
||||
representing bit values and mask of affected bits) and bit-by-bit (list of
|
||||
bits identified by either index or name).
|
||||
|
||||
Verbose (bit-by-bit) bitsets allow sending symbolic names for bits together
|
||||
with their values which saves a round trip (when the bitset is passed in a
|
||||
request) or at least a second request (when the bitset is in a reply). This is
|
||||
useful for one shot applications like traditional ethtool command. On the
|
||||
other hand, long running applications like ethtool monitor (displaying
|
||||
notifications) or network management daemons may prefer fetching the names
|
||||
only once and using compact form to save message size. Notifications from
|
||||
ethtool netlink interface always use compact form for bitsets.
|
||||
|
||||
A bitset can represent either a value/mask pair (``ETHTOOL_A_BITSET_NOMASK``
|
||||
not set) or a single bitmap (``ETHTOOL_A_BITSET_NOMASK`` set). In requests
|
||||
modifying a bitmap, the former changes the bit set in mask to values set in
|
||||
value and preserves the rest; the latter sets the bits set in the bitmap and
|
||||
clears the rest.
|
||||
|
||||
Compact form: nested (bitset) atrribute contents:
|
||||
|
||||
============================ ====== ============================
|
||||
``ETHTOOL_A_BITSET_NOMASK`` flag no mask, only a list
|
||||
``ETHTOOL_A_BITSET_SIZE`` u32 number of significant bits
|
||||
``ETHTOOL_A_BITSET_VALUE`` binary bitmap of bit values
|
||||
``ETHTOOL_A_BITSET_MASK`` binary bitmap of valid bits
|
||||
============================ ====== ============================
|
||||
|
||||
Value and mask must have length at least ``ETHTOOL_A_BITSET_SIZE`` bits
|
||||
rounded up to a multiple of 32 bits. They consist of 32-bit words in host byte
|
||||
order, words ordered from least significant to most significant (i.e. the same
|
||||
way as bitmaps are passed with ioctl interface).
|
||||
|
||||
For compact form, ``ETHTOOL_A_BITSET_SIZE`` and ``ETHTOOL_A_BITSET_VALUE`` are
|
||||
mandatory. ``ETHTOOL_A_BITSET_MASK`` attribute is mandatory if
|
||||
``ETHTOOL_A_BITSET_NOMASK`` is not set (bitset represents a value/mask pair);
|
||||
if ``ETHTOOL_A_BITSET_NOMASK`` is not set, ``ETHTOOL_A_BITSET_MASK`` is not
|
||||
allowed (bitset represents a single bitmap.
|
||||
|
||||
Kernel bit set length may differ from userspace length if older application is
|
||||
used on newer kernel or vice versa. If userspace bitmap is longer, an error is
|
||||
issued only if the request actually tries to set values of some bits not
|
||||
recognized by kernel.
|
||||
|
||||
Bit-by-bit form: nested (bitset) attribute contents:
|
||||
|
||||
+------------------------------------+--------+-----------------------------+
|
||||
| ``ETHTOOL_A_BITSET_NOMASK`` | flag | no mask, only a list |
|
||||
+------------------------------------+--------+-----------------------------+
|
||||
| ``ETHTOOL_A_BITSET_SIZE`` | u32 | number of significant bits |
|
||||
+------------------------------------+--------+-----------------------------+
|
||||
| ``ETHTOOL_A_BITSET_BITS`` | nested | array of bits |
|
||||
+-+----------------------------------+--------+-----------------------------+
|
||||
| | ``ETHTOOL_A_BITSET_BITS_BIT+`` | nested | one bit |
|
||||
+-+-+--------------------------------+--------+-----------------------------+
|
||||
| | | ``ETHTOOL_A_BITSET_BIT_INDEX`` | u32 | bit index (0 for LSB) |
|
||||
+-+-+--------------------------------+--------+-----------------------------+
|
||||
| | | ``ETHTOOL_A_BITSET_BIT_NAME`` | string | bit name |
|
||||
+-+-+--------------------------------+--------+-----------------------------+
|
||||
| | | ``ETHTOOL_A_BITSET_BIT_VALUE`` | flag | present if bit is set |
|
||||
+-+-+--------------------------------+--------+-----------------------------+
|
||||
|
||||
Bit size is optional for bit-by-bit form. ``ETHTOOL_A_BITSET_BITS`` nest can
|
||||
only contain ``ETHTOOL_A_BITSET_BITS_BIT`` attributes but there can be an
|
||||
arbitrary number of them. A bit may be identified by its index or by its
|
||||
name. When used in requests, listed bits are set to 0 or 1 according to
|
||||
``ETHTOOL_A_BITSET_BIT_VALUE``, the rest is preserved. A request fails if
|
||||
index exceeds kernel bit length or if name is not recognized.
|
||||
|
||||
When ``ETHTOOL_A_BITSET_NOMASK`` flag is present, bitset is interpreted as
|
||||
a simple bitmap. ``ETHTOOL_A_BITSET_BIT_VALUE`` attributes are not used in
|
||||
such case. Such bitset represents a bitmap with listed bits set and the rest
|
||||
zero.
|
||||
|
||||
In requests, application can use either form. Form used by kernel in reply is
|
||||
determined by ``ETHTOOL_FLAG_COMPACT_BITSETS`` flag in flags field of request
|
||||
header. Semantics of value and mask depends on the attribute.
|
||||
|
||||
|
||||
List of message types
|
||||
=====================
|
||||
|
||||
All constants identifying message types use ``ETHTOOL_CMD_`` prefix and suffix
|
||||
according to message purpose:
|
||||
|
||||
============== ======================================
|
||||
``_GET`` userspace request to retrieve data
|
||||
``_SET`` userspace request to set data
|
||||
``_ACT`` userspace request to perform an action
|
||||
``_GET_REPLY`` kernel reply to a ``GET`` request
|
||||
``_SET_REPLY`` kernel reply to a ``SET`` request
|
||||
``_ACT_REPLY`` kernel reply to an ``ACT`` request
|
||||
``_NTF`` kernel notification
|
||||
============== ======================================
|
||||
|
||||
Userspace to kernel:
|
||||
|
||||
===================================== ================================
|
||||
``ETHTOOL_MSG_STRSET_GET`` get string set
|
||||
``ETHTOOL_MSG_LINKINFO_GET`` get link settings
|
||||
``ETHTOOL_MSG_LINKINFO_SET`` set link settings
|
||||
``ETHTOOL_MSG_LINKMODES_GET`` get link modes info
|
||||
``ETHTOOL_MSG_LINKMODES_SET`` set link modes info
|
||||
``ETHTOOL_MSG_LINKSTATE_GET`` get link state
|
||||
===================================== ================================
|
||||
|
||||
Kernel to userspace:
|
||||
|
||||
===================================== ================================
|
||||
``ETHTOOL_MSG_STRSET_GET_REPLY`` string set contents
|
||||
``ETHTOOL_MSG_LINKINFO_GET_REPLY`` link settings
|
||||
``ETHTOOL_MSG_LINKINFO_NTF`` link settings notification
|
||||
``ETHTOOL_MSG_LINKMODES_GET_REPLY`` link modes info
|
||||
``ETHTOOL_MSG_LINKMODES_NTF`` link modes notification
|
||||
``ETHTOOL_MSG_LINKSTATE_GET_REPLY`` link state info
|
||||
===================================== ================================
|
||||
|
||||
``GET`` requests are sent by userspace applications to retrieve device
|
||||
information. They usually do not contain any message specific attributes.
|
||||
Kernel replies with corresponding "GET_REPLY" message. For most types, ``GET``
|
||||
request with ``NLM_F_DUMP`` and no device identification can be used to query
|
||||
the information for all devices supporting the request.
|
||||
|
||||
If the data can be also modified, corresponding ``SET`` message with the same
|
||||
layout as corresponding ``GET_REPLY`` is used to request changes. Only
|
||||
attributes where a change is requested are included in such request (also, not
|
||||
all attributes may be changed). Replies to most ``SET`` request consist only
|
||||
of error code and extack; if kernel provides additional data, it is sent in
|
||||
the form of corresponding ``SET_REPLY`` message which can be suppressed by
|
||||
setting ``ETHTOOL_FLAG_OMIT_REPLY`` flag in request header.
|
||||
|
||||
Data modification also triggers sending a ``NTF`` message with a notification.
|
||||
These usually bear only a subset of attributes which was affected by the
|
||||
change. The same notification is issued if the data is modified using other
|
||||
means (mostly ioctl ethtool interface). Unlike notifications from ethtool
|
||||
netlink code which are only sent if something actually changed, notifications
|
||||
triggered by ioctl interface may be sent even if the request did not actually
|
||||
change any data.
|
||||
|
||||
``ACT`` messages request kernel (driver) to perform a specific action. If some
|
||||
information is reported by kernel (which can be suppressed by setting
|
||||
``ETHTOOL_FLAG_OMIT_REPLY`` flag in request header), the reply takes form of
|
||||
an ``ACT_REPLY`` message. Performing an action also triggers a notification
|
||||
(``NTF`` message).
|
||||
|
||||
Later sections describe the format and semantics of these messages.
|
||||
|
||||
|
||||
STRSET_GET
|
||||
==========
|
||||
|
||||
Requests contents of a string set as provided by ioctl commands
|
||||
``ETHTOOL_GSSET_INFO`` and ``ETHTOOL_GSTRINGS.`` String sets are not user
|
||||
writeable so that the corresponding ``STRSET_SET`` message is only used in
|
||||
kernel replies. There are two types of string sets: global (independent of
|
||||
a device, e.g. device feature names) and device specific (e.g. device private
|
||||
flags).
|
||||
|
||||
Request contents:
|
||||
|
||||
+---------------------------------------+--------+------------------------+
|
||||
| ``ETHTOOL_A_STRSET_HEADER`` | nested | request header |
|
||||
+---------------------------------------+--------+------------------------+
|
||||
| ``ETHTOOL_A_STRSET_STRINGSETS`` | nested | string set to request |
|
||||
+-+-------------------------------------+--------+------------------------+
|
||||
| | ``ETHTOOL_A_STRINGSETS_STRINGSET+`` | nested | one string set |
|
||||
+-+-+-----------------------------------+--------+------------------------+
|
||||
| | | ``ETHTOOL_A_STRINGSET_ID`` | u32 | set id |
|
||||
+-+-+-----------------------------------+--------+------------------------+
|
||||
|
||||
Kernel response contents:
|
||||
|
||||
+---------------------------------------+--------+-----------------------+
|
||||
| ``ETHTOOL_A_STRSET_HEADER`` | nested | reply header |
|
||||
+---------------------------------------+--------+-----------------------+
|
||||
| ``ETHTOOL_A_STRSET_STRINGSETS`` | nested | array of string sets |
|
||||
+-+-------------------------------------+--------+-----------------------+
|
||||
| | ``ETHTOOL_A_STRINGSETS_STRINGSET+`` | nested | one string set |
|
||||
+-+-+-----------------------------------+--------+-----------------------+
|
||||
| | | ``ETHTOOL_A_STRINGSET_ID`` | u32 | set id |
|
||||
+-+-+-----------------------------------+--------+-----------------------+
|
||||
| | | ``ETHTOOL_A_STRINGSET_COUNT`` | u32 | number of strings |
|
||||
+-+-+-----------------------------------+--------+-----------------------+
|
||||
| | | ``ETHTOOL_A_STRINGSET_STRINGS`` | nested | array of strings |
|
||||
+-+-+-+---------------------------------+--------+-----------------------+
|
||||
| | | | ``ETHTOOL_A_STRINGS_STRING+`` | nested | one string |
|
||||
+-+-+-+-+-------------------------------+--------+-----------------------+
|
||||
| | | | | ``ETHTOOL_A_STRING_INDEX`` | u32 | string index |
|
||||
+-+-+-+-+-------------------------------+--------+-----------------------+
|
||||
| | | | | ``ETHTOOL_A_STRING_VALUE`` | string | string value |
|
||||
+-+-+-+-+-------------------------------+--------+-----------------------+
|
||||
| ``ETHTOOL_A_STRSET_COUNTS_ONLY`` | flag | return only counts |
|
||||
+---------------------------------------+--------+-----------------------+
|
||||
|
||||
Device identification in request header is optional. Depending on its presence
|
||||
a and ``NLM_F_DUMP`` flag, there are three type of ``STRSET_GET`` requests:
|
||||
|
||||
- no ``NLM_F_DUMP,`` no device: get "global" stringsets
|
||||
- no ``NLM_F_DUMP``, with device: get string sets related to the device
|
||||
- ``NLM_F_DUMP``, no device: get device related string sets for all devices
|
||||
|
||||
If there is no ``ETHTOOL_A_STRSET_STRINGSETS`` array, all string sets of
|
||||
requested type are returned, otherwise only those specified in the request.
|
||||
Flag ``ETHTOOL_A_STRSET_COUNTS_ONLY`` tells kernel to only return string
|
||||
counts of the sets, not the actual strings.
|
||||
|
||||
|
||||
LINKINFO_GET
|
||||
============
|
||||
|
||||
Requests link settings as provided by ``ETHTOOL_GLINKSETTINGS`` except for
|
||||
link modes and autonegotiation related information. The request does not use
|
||||
any attributes.
|
||||
|
||||
Request contents:
|
||||
|
||||
==================================== ====== ==========================
|
||||
``ETHTOOL_A_LINKINFO_HEADER`` nested request header
|
||||
==================================== ====== ==========================
|
||||
|
||||
Kernel response contents:
|
||||
|
||||
==================================== ====== ==========================
|
||||
``ETHTOOL_A_LINKINFO_HEADER`` nested reply header
|
||||
``ETHTOOL_A_LINKINFO_PORT`` u8 physical port
|
||||
``ETHTOOL_A_LINKINFO_PHYADDR`` u8 phy MDIO address
|
||||
``ETHTOOL_A_LINKINFO_TP_MDIX`` u8 MDI(-X) status
|
||||
``ETHTOOL_A_LINKINFO_TP_MDIX_CTRL`` u8 MDI(-X) control
|
||||
``ETHTOOL_A_LINKINFO_TRANSCEIVER`` u8 transceiver
|
||||
==================================== ====== ==========================
|
||||
|
||||
Attributes and their values have the same meaning as matching members of the
|
||||
corresponding ioctl structures.
|
||||
|
||||
``LINKINFO_GET`` allows dump requests (kernel returns reply message for all
|
||||
devices supporting the request).
|
||||
|
||||
|
||||
LINKINFO_SET
|
||||
============
|
||||
|
||||
``LINKINFO_SET`` request allows setting some of the attributes reported by
|
||||
``LINKINFO_GET``.
|
||||
|
||||
Request contents:
|
||||
|
||||
==================================== ====== ==========================
|
||||
``ETHTOOL_A_LINKINFO_HEADER`` nested request header
|
||||
``ETHTOOL_A_LINKINFO_PORT`` u8 physical port
|
||||
``ETHTOOL_A_LINKINFO_PHYADDR`` u8 phy MDIO address
|
||||
``ETHTOOL_A_LINKINFO_TP_MDIX_CTRL`` u8 MDI(-X) control
|
||||
==================================== ====== ==========================
|
||||
|
||||
MDI(-X) status and transceiver cannot be set, request with the corresponding
|
||||
attributes is rejected.
|
||||
|
||||
|
||||
LINKMODES_GET
|
||||
=============
|
||||
|
||||
Requests link modes (supported, advertised and peer advertised) and related
|
||||
information (autonegotiation status, link speed and duplex) as provided by
|
||||
``ETHTOOL_GLINKSETTINGS``. The request does not use any attributes.
|
||||
|
||||
Request contents:
|
||||
|
||||
==================================== ====== ==========================
|
||||
``ETHTOOL_A_LINKMODES_HEADER`` nested request header
|
||||
==================================== ====== ==========================
|
||||
|
||||
Kernel response contents:
|
||||
|
||||
==================================== ====== ==========================
|
||||
``ETHTOOL_A_LINKMODES_HEADER`` nested reply header
|
||||
``ETHTOOL_A_LINKMODES_AUTONEG`` u8 autonegotiation status
|
||||
``ETHTOOL_A_LINKMODES_OURS`` bitset advertised link modes
|
||||
``ETHTOOL_A_LINKMODES_PEER`` bitset partner link modes
|
||||
``ETHTOOL_A_LINKMODES_SPEED`` u32 link speed (Mb/s)
|
||||
``ETHTOOL_A_LINKMODES_DUPLEX`` u8 duplex mode
|
||||
==================================== ====== ==========================
|
||||
|
||||
For ``ETHTOOL_A_LINKMODES_OURS``, value represents advertised modes and mask
|
||||
represents supported modes. ``ETHTOOL_A_LINKMODES_PEER`` in the reply is a bit
|
||||
list.
|
||||
|
||||
``LINKMODES_GET`` allows dump requests (kernel returns reply messages for all
|
||||
devices supporting the request).
|
||||
|
||||
|
||||
LINKMODES_SET
|
||||
=============
|
||||
|
||||
Request contents:
|
||||
|
||||
==================================== ====== ==========================
|
||||
``ETHTOOL_A_LINKMODES_HEADER`` nested request header
|
||||
``ETHTOOL_A_LINKMODES_AUTONEG`` u8 autonegotiation status
|
||||
``ETHTOOL_A_LINKMODES_OURS`` bitset advertised link modes
|
||||
``ETHTOOL_A_LINKMODES_PEER`` bitset partner link modes
|
||||
``ETHTOOL_A_LINKMODES_SPEED`` u32 link speed (Mb/s)
|
||||
``ETHTOOL_A_LINKMODES_DUPLEX`` u8 duplex mode
|
||||
==================================== ====== ==========================
|
||||
|
||||
``ETHTOOL_A_LINKMODES_OURS`` bit set allows setting advertised link modes. If
|
||||
autonegotiation is on (either set now or kept from before), advertised modes
|
||||
are not changed (no ``ETHTOOL_A_LINKMODES_OURS`` attribute) and at least one
|
||||
of speed and duplex is specified, kernel adjusts advertised modes to all
|
||||
supported modes matching speed, duplex or both (whatever is specified). This
|
||||
autoselection is done on ethtool side with ioctl interface, netlink interface
|
||||
is supposed to allow requesting changes without knowing what exactly kernel
|
||||
supports.
|
||||
|
||||
|
||||
LINKSTATE_GET
|
||||
=============
|
||||
|
||||
Requests link state information. At the moment, only link up/down flag (as
|
||||
provided by ``ETHTOOL_GLINK`` ioctl command) is provided but some future
|
||||
extensions are planned (e.g. link down reason). This request does not have any
|
||||
attributes.
|
||||
|
||||
Request contents:
|
||||
|
||||
==================================== ====== ==========================
|
||||
``ETHTOOL_A_LINKSTATE_HEADER`` nested request header
|
||||
==================================== ====== ==========================
|
||||
|
||||
Kernel response contents:
|
||||
|
||||
==================================== ====== ==========================
|
||||
``ETHTOOL_A_LINKSTATE_HEADER`` nested reply header
|
||||
``ETHTOOL_A_LINKSTATE_LINK`` bool link state (up/down)
|
||||
==================================== ====== ==========================
|
||||
|
||||
For most NIC drivers, the value of ``ETHTOOL_A_LINKSTATE_LINK`` returns
|
||||
carrier flag provided by ``netif_carrier_ok()`` but there are drivers which
|
||||
define their own handler.
|
||||
|
||||
``LINKSTATE_GET`` allows dump requests (kernel returns reply messages for all
|
||||
devices supporting the request).
|
||||
|
||||
|
||||
Request translation
|
||||
===================
|
||||
|
||||
The following table maps ioctl commands to netlink commands providing their
|
||||
functionality. Entries with "n/a" in right column are commands which do not
|
||||
have their netlink replacement yet.
|
||||
|
||||
=================================== =====================================
|
||||
ioctl command netlink command
|
||||
=================================== =====================================
|
||||
``ETHTOOL_GSET`` ``ETHTOOL_MSG_LINKINFO_GET``
|
||||
``ETHTOOL_MSG_LINKMODES_GET``
|
||||
``ETHTOOL_SSET`` ``ETHTOOL_MSG_LINKINFO_SET``
|
||||
``ETHTOOL_MSG_LINKMODES_SET``
|
||||
``ETHTOOL_GDRVINFO`` n/a
|
||||
``ETHTOOL_GREGS`` n/a
|
||||
``ETHTOOL_GWOL`` n/a
|
||||
``ETHTOOL_SWOL`` n/a
|
||||
``ETHTOOL_GMSGLVL`` n/a
|
||||
``ETHTOOL_SMSGLVL`` n/a
|
||||
``ETHTOOL_NWAY_RST`` n/a
|
||||
``ETHTOOL_GLINK`` ``ETHTOOL_MSG_LINKSTATE_GET``
|
||||
``ETHTOOL_GEEPROM`` n/a
|
||||
``ETHTOOL_SEEPROM`` n/a
|
||||
``ETHTOOL_GCOALESCE`` n/a
|
||||
``ETHTOOL_SCOALESCE`` n/a
|
||||
``ETHTOOL_GRINGPARAM`` n/a
|
||||
``ETHTOOL_SRINGPARAM`` n/a
|
||||
``ETHTOOL_GPAUSEPARAM`` n/a
|
||||
``ETHTOOL_SPAUSEPARAM`` n/a
|
||||
``ETHTOOL_GRXCSUM`` n/a
|
||||
``ETHTOOL_SRXCSUM`` n/a
|
||||
``ETHTOOL_GTXCSUM`` n/a
|
||||
``ETHTOOL_STXCSUM`` n/a
|
||||
``ETHTOOL_GSG`` n/a
|
||||
``ETHTOOL_SSG`` n/a
|
||||
``ETHTOOL_TEST`` n/a
|
||||
``ETHTOOL_GSTRINGS`` ``ETHTOOL_MSG_STRSET_GET``
|
||||
``ETHTOOL_PHYS_ID`` n/a
|
||||
``ETHTOOL_GSTATS`` n/a
|
||||
``ETHTOOL_GTSO`` n/a
|
||||
``ETHTOOL_STSO`` n/a
|
||||
``ETHTOOL_GPERMADDR`` rtnetlink ``RTM_GETLINK``
|
||||
``ETHTOOL_GUFO`` n/a
|
||||
``ETHTOOL_SUFO`` n/a
|
||||
``ETHTOOL_GGSO`` n/a
|
||||
``ETHTOOL_SGSO`` n/a
|
||||
``ETHTOOL_GFLAGS`` n/a
|
||||
``ETHTOOL_SFLAGS`` n/a
|
||||
``ETHTOOL_GPFLAGS`` n/a
|
||||
``ETHTOOL_SPFLAGS`` n/a
|
||||
``ETHTOOL_GRXFH`` n/a
|
||||
``ETHTOOL_SRXFH`` n/a
|
||||
``ETHTOOL_GGRO`` n/a
|
||||
``ETHTOOL_SGRO`` n/a
|
||||
``ETHTOOL_GRXRINGS`` n/a
|
||||
``ETHTOOL_GRXCLSRLCNT`` n/a
|
||||
``ETHTOOL_GRXCLSRULE`` n/a
|
||||
``ETHTOOL_GRXCLSRLALL`` n/a
|
||||
``ETHTOOL_SRXCLSRLDEL`` n/a
|
||||
``ETHTOOL_SRXCLSRLINS`` n/a
|
||||
``ETHTOOL_FLASHDEV`` n/a
|
||||
``ETHTOOL_RESET`` n/a
|
||||
``ETHTOOL_SRXNTUPLE`` n/a
|
||||
``ETHTOOL_GRXNTUPLE`` n/a
|
||||
``ETHTOOL_GSSET_INFO`` ``ETHTOOL_MSG_STRSET_GET``
|
||||
``ETHTOOL_GRXFHINDIR`` n/a
|
||||
``ETHTOOL_SRXFHINDIR`` n/a
|
||||
``ETHTOOL_GFEATURES`` n/a
|
||||
``ETHTOOL_SFEATURES`` n/a
|
||||
``ETHTOOL_GCHANNELS`` n/a
|
||||
``ETHTOOL_SCHANNELS`` n/a
|
||||
``ETHTOOL_SET_DUMP`` n/a
|
||||
``ETHTOOL_GET_DUMP_FLAG`` n/a
|
||||
``ETHTOOL_GET_DUMP_DATA`` n/a
|
||||
``ETHTOOL_GET_TS_INFO`` n/a
|
||||
``ETHTOOL_GMODULEINFO`` n/a
|
||||
``ETHTOOL_GMODULEEEPROM`` n/a
|
||||
``ETHTOOL_GEEE`` n/a
|
||||
``ETHTOOL_SEEE`` n/a
|
||||
``ETHTOOL_GRSSH`` n/a
|
||||
``ETHTOOL_SRSSH`` n/a
|
||||
``ETHTOOL_GTUNABLE`` n/a
|
||||
``ETHTOOL_STUNABLE`` n/a
|
||||
``ETHTOOL_GPHYSTATS`` n/a
|
||||
``ETHTOOL_PERQUEUE`` n/a
|
||||
``ETHTOOL_GLINKSETTINGS`` ``ETHTOOL_MSG_LINKINFO_GET``
|
||||
``ETHTOOL_MSG_LINKMODES_GET``
|
||||
``ETHTOOL_SLINKSETTINGS`` ``ETHTOOL_MSG_LINKINFO_SET``
|
||||
``ETHTOOL_MSG_LINKMODES_SET``
|
||||
``ETHTOOL_PHY_GTUNABLE`` n/a
|
||||
``ETHTOOL_PHY_STUNABLE`` n/a
|
||||
``ETHTOOL_GFECPARAM`` n/a
|
||||
``ETHTOOL_SFECPARAM`` n/a
|
||||
=================================== =====================================
|
@ -16,6 +16,7 @@ Contents:
|
||||
devlink-info-versions
|
||||
devlink-trap
|
||||
devlink-trap-netdevsim
|
||||
ethtool-netlink
|
||||
ieee802154
|
||||
j1939
|
||||
kapi
|
||||
|
@ -339,7 +339,7 @@ To claim an address following code example can be used:
|
||||
.pgn = J1939_PGN_ADDRESS_CLAIMED,
|
||||
.pgn_mask = J1939_PGN_PDU1_MAX,
|
||||
}, {
|
||||
.pgn = J1939_PGN_ADDRESS_REQUEST,
|
||||
.pgn = J1939_PGN_REQUEST,
|
||||
.pgn_mask = J1939_PGN_PDU1_MAX,
|
||||
}, {
|
||||
.pgn = J1939_PGN_ADDRESS_COMMANDED,
|
||||
|
@ -988,7 +988,7 @@ Similarly, if you need to calculate the size of some structure member, use
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
|
||||
#define sizeof_field(t, f) (sizeof(((t*)0)->f))
|
||||
|
||||
There are also min() and max() macros that do strict type checking if you
|
||||
need them. Feel free to peruse that header file to see what else is already
|
||||
|
@ -29,7 +29,7 @@ smartpqi specific entries in /sys
|
||||
smartpqi host attributes:
|
||||
-------------------------
|
||||
/sys/class/scsi_host/host*/rescan
|
||||
/sys/class/scsi_host/host*/version
|
||||
/sys/class/scsi_host/host*/driver_version
|
||||
|
||||
The host rescan attribute is a write only attribute. Writing to this
|
||||
attribute will trigger the driver to scan for new, changed, or removed
|
||||
|
@ -1005,7 +1005,7 @@ struttura, usate
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
|
||||
#define sizeof_field(t, f) (sizeof(((t*)0)->f))
|
||||
|
||||
Ci sono anche le macro min() e max() che, se vi serve, effettuano un controllo
|
||||
rigido sui tipi. Sentitevi liberi di leggere attentamente questo file
|
||||
|
@ -826,7 +826,7 @@ inline gcc 也可以自动使其内联。而且其他用户可能会要求移除
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
|
||||
#define sizeof_field(t, f) (sizeof(((t*)0)->f))
|
||||
|
||||
还有可以做严格的类型检查的 min() 和 max() 宏,如果你需要可以使用它们。你可以
|
||||
自己看看那个头文件里还定义了什么你可以拿来用的东西,如果有定义的话,你就不应
|
||||
|
48
MAINTAINERS
48
MAINTAINERS
@ -771,6 +771,8 @@ F: drivers/thermal/thermal_mmio.c
|
||||
|
||||
AMAZON ETHERNET DRIVERS
|
||||
M: Netanel Belgazal <netanel@amazon.com>
|
||||
M: Arthur Kiyanovski <akiyano@amazon.com>
|
||||
R: Guy Tzalik <gtzalik@amazon.com>
|
||||
R: Saeed Bishara <saeedb@amazon.com>
|
||||
R: Zorik Machulsky <zorik@amazon.com>
|
||||
L: netdev@vger.kernel.org
|
||||
@ -2272,6 +2274,7 @@ F: drivers/*/*s3c64xx*
|
||||
F: drivers/*/*s5pv210*
|
||||
F: drivers/memory/samsung/
|
||||
F: drivers/soc/samsung/
|
||||
F: drivers/tty/serial/samsung*
|
||||
F: include/linux/soc/samsung/
|
||||
F: Documentation/arm/samsung/
|
||||
F: Documentation/devicetree/bindings/arm/samsung/
|
||||
@ -4970,6 +4973,7 @@ F: include/linux/dma-buf*
|
||||
F: include/linux/reservation.h
|
||||
F: include/linux/*fence.h
|
||||
F: Documentation/driver-api/dma-buf.rst
|
||||
K: dma_(buf|fence|resv)
|
||||
T: git git://anongit.freedesktop.org/drm/drm-misc
|
||||
|
||||
DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
|
||||
@ -4999,7 +5003,7 @@ F: include/linux/dma-mapping.h
|
||||
F: include/linux/dma-noncoherent.h
|
||||
|
||||
DMC FREQUENCY DRIVER FOR SAMSUNG EXYNOS5422
|
||||
M: Lukasz Luba <l.luba@partner.samsung.com>
|
||||
M: Lukasz Luba <lukasz.luba@arm.com>
|
||||
L: linux-pm@vger.kernel.org
|
||||
L: linux-samsung-soc@vger.kernel.org
|
||||
S: Maintained
|
||||
@ -6025,6 +6029,7 @@ M: Yash Shah <yash.shah@sifive.com>
|
||||
L: linux-edac@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/edac/sifive_edac.c
|
||||
F: drivers/soc/sifive_l2_cache.c
|
||||
|
||||
EDAC-SKYLAKE
|
||||
M: Tony Luck <tony.luck@intel.com>
|
||||
@ -7031,6 +7036,7 @@ L: linux-acpi@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/firmware-guide/acpi/gpio-properties.rst
|
||||
F: drivers/gpio/gpiolib-acpi.c
|
||||
F: drivers/gpio/gpiolib-acpi.h
|
||||
|
||||
GPIO IR Transmitter
|
||||
M: Sean Young <sean@mess.org>
|
||||
@ -9038,7 +9044,6 @@ F: include/linux/umh.h
|
||||
|
||||
KERNEL VIRTUAL MACHINE (KVM)
|
||||
M: Paolo Bonzini <pbonzini@redhat.com>
|
||||
M: Radim Krčmář <rkrcmar@redhat.com>
|
||||
L: kvm@vger.kernel.org
|
||||
W: http://www.linux-kvm.org
|
||||
T: git git://git.kernel.org/pub/scm/virt/kvm/kvm.git
|
||||
@ -9073,9 +9078,9 @@ F: virt/kvm/arm/
|
||||
F: include/kvm/arm_*
|
||||
|
||||
KERNEL VIRTUAL MACHINE FOR MIPS (KVM/mips)
|
||||
M: James Hogan <jhogan@kernel.org>
|
||||
L: linux-mips@vger.kernel.org
|
||||
S: Supported
|
||||
L: kvm@vger.kernel.org
|
||||
S: Orphan
|
||||
F: arch/mips/include/uapi/asm/kvm*
|
||||
F: arch/mips/include/asm/kvm*
|
||||
F: arch/mips/kvm/
|
||||
@ -9110,7 +9115,6 @@ F: tools/testing/selftests/kvm/*/s390x/
|
||||
|
||||
KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)
|
||||
M: Paolo Bonzini <pbonzini@redhat.com>
|
||||
M: Radim Krčmář <rkrcmar@redhat.com>
|
||||
R: Sean Christopherson <sean.j.christopherson@intel.com>
|
||||
R: Vitaly Kuznetsov <vkuznets@redhat.com>
|
||||
R: Wanpeng Li <wanpengli@tencent.com>
|
||||
@ -9956,7 +9960,7 @@ F: drivers/net/ethernet/marvell/mvneta.*
|
||||
MARVELL MWIFIEX WIRELESS DRIVER
|
||||
M: Amitkumar Karwar <amitkarwar@gmail.com>
|
||||
M: Nishant Sarmukadam <nishants@marvell.com>
|
||||
M: Ganapathi Bhat <gbhat@marvell.com>
|
||||
M: Ganapathi Bhat <ganapathi.bhat@nxp.com>
|
||||
M: Xinming Hu <huxinming820@gmail.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Maintained
|
||||
@ -10108,6 +10112,7 @@ S: Maintained
|
||||
F: drivers/media/radio/radio-maxiradio*
|
||||
|
||||
MCAN MMIO DEVICE DRIVER
|
||||
M: Dan Murphy <dmurphy@ti.com>
|
||||
M: Sriram Dash <sriram.dash@samsung.com>
|
||||
L: linux-can@vger.kernel.org
|
||||
S: Maintained
|
||||
@ -12393,7 +12398,7 @@ L: linux-unionfs@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
|
||||
S: Supported
|
||||
F: fs/overlayfs/
|
||||
F: Documentation/filesystems/overlayfs.txt
|
||||
F: Documentation/filesystems/overlayfs.rst
|
||||
|
||||
P54 WIRELESS DRIVER
|
||||
M: Christian Lamparter <chunkeey@googlemail.com>
|
||||
@ -13644,6 +13649,13 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
|
||||
S: Supported
|
||||
F: drivers/net/wireless/ath/ath10k/
|
||||
|
||||
QUALCOMM ATHEROS ATH11K WIRELESS DRIVER
|
||||
M: Kalle Valo <kvalo@codeaurora.org>
|
||||
L: ath11k@lists.infradead.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
|
||||
S: Supported
|
||||
F: drivers/net/wireless/ath/ath11k/
|
||||
|
||||
QUALCOMM ATHEROS ATH9K WIRELESS DRIVER
|
||||
M: QCA ath9k Development <ath9k-devel@qca.qualcomm.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
@ -13708,6 +13720,15 @@ L: linux-arm-msm@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/iommu/qcom_iommu.c
|
||||
|
||||
QUALCOMM RMNET DRIVER
|
||||
M: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
|
||||
M: Sean Tranchetti <stranche@codeaurora.org>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/ethernet/qualcomm/rmnet/
|
||||
F: Documentation/networking/device_drivers/qualcomm/rmnet.txt
|
||||
F: include/linux/if_rmnet.h
|
||||
|
||||
QUALCOMM TSENS THERMAL DRIVER
|
||||
M: Amit Kucheria <amit.kucheria@linaro.org>
|
||||
L: linux-pm@vger.kernel.org
|
||||
@ -16314,12 +16335,10 @@ F: drivers/media/radio/radio-raremono.c
|
||||
|
||||
THERMAL
|
||||
M: Zhang Rui <rui.zhang@intel.com>
|
||||
M: Eduardo Valentin <edubezval@gmail.com>
|
||||
R: Daniel Lezcano <daniel.lezcano@linaro.org>
|
||||
M: Daniel Lezcano <daniel.lezcano@linaro.org>
|
||||
R: Amit Kucheria <amit.kucheria@verdurent.com>
|
||||
L: linux-pm@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git
|
||||
Q: https://patchwork.kernel.org/project/linux-pm/list/
|
||||
S: Supported
|
||||
F: drivers/thermal/
|
||||
@ -16533,6 +16552,13 @@ L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
S: Odd Fixes
|
||||
F: sound/soc/codecs/tas571x*
|
||||
|
||||
TI TCAN4X5X DEVICE DRIVER
|
||||
M: Dan Murphy <dmurphy@ti.com>
|
||||
L: linux-can@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/net/can/tcan4x5x.txt
|
||||
F: drivers/net/can/m_can/tcan4x5x.c
|
||||
|
||||
TI TRF7970A NFC DRIVER
|
||||
M: Mark Greer <mgreer@animalcreek.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
|
5
Makefile
5
Makefile
@ -2,7 +2,7 @@
|
||||
VERSION = 5
|
||||
PATCHLEVEL = 5
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc1
|
||||
EXTRAVERSION = -rc4
|
||||
NAME = Kleptomaniac Octopus
|
||||
|
||||
# *DOCUMENTATION*
|
||||
@ -414,6 +414,7 @@ STRIP = $(CROSS_COMPILE)strip
|
||||
OBJCOPY = $(CROSS_COMPILE)objcopy
|
||||
OBJDUMP = $(CROSS_COMPILE)objdump
|
||||
OBJSIZE = $(CROSS_COMPILE)size
|
||||
READELF = $(CROSS_COMPILE)readelf
|
||||
PAHOLE = pahole
|
||||
LEX = flex
|
||||
YACC = bison
|
||||
@ -472,7 +473,7 @@ GCC_PLUGINS_CFLAGS :=
|
||||
CLANG_FLAGS :=
|
||||
|
||||
export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE AS LD CC
|
||||
export CPP AR NM STRIP OBJCOPY OBJDUMP OBJSIZE PAHOLE LEX YACC AWK INSTALLKERNEL
|
||||
export CPP AR NM STRIP OBJCOPY OBJDUMP OBJSIZE READELF PAHOLE LEX YACC AWK INSTALLKERNEL
|
||||
export PERL PYTHON PYTHON2 PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX
|
||||
export KBUILD_HOSTCXXFLAGS KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS LDFLAGS_MODULE
|
||||
|
||||
|
@ -42,10 +42,10 @@ do { \
|
||||
|
||||
#define EXTRA_INFO(f) { \
|
||||
BUILD_BUG_ON_ZERO(offsetof(struct unwind_frame_info, f) \
|
||||
% FIELD_SIZEOF(struct unwind_frame_info, f)) \
|
||||
% sizeof_field(struct unwind_frame_info, f)) \
|
||||
+ offsetof(struct unwind_frame_info, f) \
|
||||
/ FIELD_SIZEOF(struct unwind_frame_info, f), \
|
||||
FIELD_SIZEOF(struct unwind_frame_info, f) \
|
||||
/ sizeof_field(struct unwind_frame_info, f), \
|
||||
sizeof_field(struct unwind_frame_info, f) \
|
||||
}
|
||||
#define PTREGS_INFO(f) EXTRA_INFO(regs.f)
|
||||
|
||||
|
@ -108,7 +108,7 @@
|
||||
|
||||
&cpsw_emac0 {
|
||||
phy-handle = <ðphy0>;
|
||||
phy-mode = "rgmii-txid";
|
||||
phy-mode = "rgmii-id";
|
||||
};
|
||||
|
||||
&i2c0 {
|
||||
|
@ -86,7 +86,7 @@
|
||||
};
|
||||
|
||||
lcd0: display {
|
||||
compatible = "osddisplays,osd057T0559-34ts", "panel-dpi";
|
||||
compatible = "osddisplays,osd070t1718-19ts", "panel-dpi";
|
||||
label = "lcd";
|
||||
|
||||
backlight = <&lcd_bl>;
|
||||
|
@ -42,7 +42,7 @@
|
||||
};
|
||||
|
||||
lcd0: display {
|
||||
compatible = "osddisplays,osd057T0559-34ts", "panel-dpi";
|
||||
compatible = "osddisplays,osd070t1718-19ts", "panel-dpi";
|
||||
label = "lcd";
|
||||
|
||||
backlight = <&lcd_bl>;
|
||||
|
@ -174,8 +174,8 @@
|
||||
mdio: mdio@18002000 {
|
||||
compatible = "brcm,iproc-mdio";
|
||||
reg = <0x18002000 0x8>;
|
||||
#size-cells = <1>;
|
||||
#address-cells = <0>;
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
status = "disabled";
|
||||
|
||||
gphy0: ethernet-phy@0 {
|
||||
|
@ -43,7 +43,7 @@
|
||||
<0x7c000000 0x0 0xfc000000 0x02000000>,
|
||||
<0x40000000 0x0 0xff800000 0x00800000>;
|
||||
/* Emulate a contiguous 30-bit address range for DMA */
|
||||
dma-ranges = <0xc0000000 0x0 0x00000000 0x3c000000>;
|
||||
dma-ranges = <0xc0000000 0x0 0x00000000 0x40000000>;
|
||||
|
||||
/*
|
||||
* This node is the provider for the enable-method for
|
||||
|
@ -37,7 +37,7 @@
|
||||
|
||||
trips {
|
||||
cpu-crit {
|
||||
temperature = <80000>;
|
||||
temperature = <90000>;
|
||||
hysteresis = <0>;
|
||||
type = "critical";
|
||||
};
|
||||
|
@ -353,8 +353,8 @@
|
||||
mdio: mdio@18003000 {
|
||||
compatible = "brcm,iproc-mdio";
|
||||
reg = <0x18003000 0x8>;
|
||||
#size-cells = <1>;
|
||||
#address-cells = <0>;
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
};
|
||||
|
||||
mdio-bus-mux@18003000 {
|
||||
|
@ -265,11 +265,6 @@
|
||||
regulator-name = "LDORTC1";
|
||||
regulator-boot-on;
|
||||
};
|
||||
|
||||
ldortc2_reg: LDORTC2 {
|
||||
regulator-name = "LDORTC2";
|
||||
regulator-boot-on;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
@ -30,14 +30,26 @@
|
||||
enable-active-high;
|
||||
};
|
||||
|
||||
reg_sensors: regulator-sensors {
|
||||
reg_peri_3v3: regulator-peri-3v3 {
|
||||
compatible = "regulator-fixed";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_sensors_reg>;
|
||||
regulator-name = "sensors-supply";
|
||||
pinctrl-0 = <&pinctrl_peri_3v3>;
|
||||
regulator-name = "VPERI_3V3";
|
||||
regulator-min-microvolt = <3300000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
gpio = <&gpio5 2 GPIO_ACTIVE_LOW>;
|
||||
/*
|
||||
* If you want to want to make this dynamic please
|
||||
* check schematics and test all affected peripherals:
|
||||
*
|
||||
* - sensors
|
||||
* - ethernet phy
|
||||
* - can
|
||||
* - bluetooth
|
||||
* - wm8960 audio codec
|
||||
* - ov5640 camera
|
||||
*/
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
reg_can_3v3: regulator-can-3v3 {
|
||||
@ -140,6 +152,7 @@
|
||||
pinctrl-0 = <&pinctrl_enet1>;
|
||||
phy-mode = "rmii";
|
||||
phy-handle = <ðphy0>;
|
||||
phy-supply = <®_peri_3v3>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@ -148,6 +161,7 @@
|
||||
pinctrl-0 = <&pinctrl_enet2>;
|
||||
phy-mode = "rmii";
|
||||
phy-handle = <ðphy1>;
|
||||
phy-supply = <®_peri_3v3>;
|
||||
status = "okay";
|
||||
|
||||
mdio {
|
||||
@ -193,8 +207,8 @@
|
||||
magnetometer@e {
|
||||
compatible = "fsl,mag3110";
|
||||
reg = <0x0e>;
|
||||
vdd-supply = <®_sensors>;
|
||||
vddio-supply = <®_sensors>;
|
||||
vdd-supply = <®_peri_3v3>;
|
||||
vddio-supply = <®_peri_3v3>;
|
||||
};
|
||||
};
|
||||
|
||||
@ -227,7 +241,7 @@
|
||||
flash0: n25q256a@0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "micron,n25q256a";
|
||||
compatible = "micron,n25q256a", "jedec,spi-nor";
|
||||
spi-max-frequency = <29000000>;
|
||||
spi-rx-bus-width = <4>;
|
||||
spi-tx-bus-width = <4>;
|
||||
@ -462,7 +476,7 @@
|
||||
>;
|
||||
};
|
||||
|
||||
pinctrl_sensors_reg: sensorsreggrp {
|
||||
pinctrl_peri_3v3: peri3v3grp {
|
||||
fsl,pins = <
|
||||
MX6UL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x1b0b0
|
||||
>;
|
||||
|
@ -350,6 +350,7 @@ CONFIG_PRINTK_TIME=y
|
||||
CONFIG_DYNAMIC_DEBUG=y
|
||||
CONFIG_DEBUG_INFO=y
|
||||
CONFIG_MAGIC_SYSRQ=y
|
||||
CONFIG_DEBUG_FS=y
|
||||
CONFIG_DEBUG_KERNEL=y
|
||||
CONFIG_SOFTLOCKUP_DETECTOR=y
|
||||
# CONFIG_DETECT_HUNG_TASK is not set
|
||||
|
@ -462,6 +462,7 @@ CONFIG_FONT_8x8=y
|
||||
CONFIG_FONT_8x16=y
|
||||
CONFIG_PRINTK_TIME=y
|
||||
CONFIG_MAGIC_SYSRQ=y
|
||||
CONFIG_DEBUG_FS=y
|
||||
# CONFIG_SCHED_DEBUG is not set
|
||||
CONFIG_PROVE_LOCKING=y
|
||||
# CONFIG_DEBUG_BUGVERBOSE is not set
|
||||
|
@ -92,6 +92,7 @@ CONFIG_IP_PNP_BOOTP=y
|
||||
CONFIG_IP_PNP_RARP=y
|
||||
CONFIG_NETFILTER=y
|
||||
CONFIG_PHONET=m
|
||||
CONFIG_NET_SWITCHDEV=y
|
||||
CONFIG_CAN=m
|
||||
CONFIG_CAN_C_CAN=m
|
||||
CONFIG_CAN_C_CAN_PLATFORM=m
|
||||
@ -181,6 +182,7 @@ CONFIG_SMSC911X=y
|
||||
# CONFIG_NET_VENDOR_STMICRO is not set
|
||||
CONFIG_TI_DAVINCI_EMAC=y
|
||||
CONFIG_TI_CPSW=y
|
||||
CONFIG_TI_CPSW_SWITCHDEV=y
|
||||
CONFIG_TI_CPTS=y
|
||||
# CONFIG_NET_VENDOR_VIA is not set
|
||||
# CONFIG_NET_VENDOR_WIZNET is not set
|
||||
@ -554,6 +556,6 @@ CONFIG_DEBUG_INFO=y
|
||||
CONFIG_DEBUG_INFO_SPLIT=y
|
||||
CONFIG_DEBUG_INFO_DWARF4=y
|
||||
CONFIG_MAGIC_SYSRQ=y
|
||||
CONFIG_DEBUG_FS=y
|
||||
CONFIG_SCHEDSTATS=y
|
||||
# CONFIG_DEBUG_BUGVERBOSE is not set
|
||||
CONFIG_TI_CPSW_SWITCHDEV=y
|
||||
|
@ -212,4 +212,5 @@ CONFIG_DMA_CMA=y
|
||||
CONFIG_CMA_SIZE_MBYTES=64
|
||||
CONFIG_PRINTK_TIME=y
|
||||
# CONFIG_ENABLE_MUST_CHECK is not set
|
||||
CONFIG_DEBUG_FS=y
|
||||
CONFIG_DEBUG_KERNEL=y
|
||||
|
@ -38,6 +38,13 @@ void curve25519_arch(u8 out[CURVE25519_KEY_SIZE],
|
||||
}
|
||||
EXPORT_SYMBOL(curve25519_arch);
|
||||
|
||||
void curve25519_base_arch(u8 pub[CURVE25519_KEY_SIZE],
|
||||
const u8 secret[CURVE25519_KEY_SIZE])
|
||||
{
|
||||
return curve25519_arch(pub, secret, curve25519_base_point);
|
||||
}
|
||||
EXPORT_SYMBOL(curve25519_base_arch);
|
||||
|
||||
static int curve25519_set_secret(struct crypto_kpp *tfm, const void *buf,
|
||||
unsigned int len)
|
||||
{
|
||||
|
@ -13,6 +13,7 @@ static const char * const bcm2711_compat[] = {
|
||||
#ifdef CONFIG_ARCH_MULTI_V7
|
||||
"brcm,bcm2711",
|
||||
#endif
|
||||
NULL
|
||||
};
|
||||
|
||||
DT_MACHINE_START(BCM2711, "BCM2711")
|
||||
|
@ -84,7 +84,7 @@ struct device * __init imx_soc_device_init(void)
|
||||
const char *ocotp_compat = NULL;
|
||||
struct soc_device *soc_dev;
|
||||
struct device_node *root;
|
||||
struct regmap *ocotp;
|
||||
struct regmap *ocotp = NULL;
|
||||
const char *soc_id;
|
||||
u64 soc_uid = 0;
|
||||
u32 val;
|
||||
@ -148,11 +148,11 @@ struct device * __init imx_soc_device_init(void)
|
||||
soc_id = "i.MX6UL";
|
||||
break;
|
||||
case MXC_CPU_IMX6ULL:
|
||||
ocotp_compat = "fsl,imx6ul-ocotp";
|
||||
ocotp_compat = "fsl,imx6ull-ocotp";
|
||||
soc_id = "i.MX6ULL";
|
||||
break;
|
||||
case MXC_CPU_IMX6ULZ:
|
||||
ocotp_compat = "fsl,imx6ul-ocotp";
|
||||
ocotp_compat = "fsl,imx6ull-ocotp";
|
||||
soc_id = "i.MX6ULZ";
|
||||
break;
|
||||
case MXC_CPU_IMX6SLL:
|
||||
@ -175,7 +175,9 @@ struct device * __init imx_soc_device_init(void)
|
||||
ocotp = syscon_regmap_lookup_by_compatible(ocotp_compat);
|
||||
if (IS_ERR(ocotp))
|
||||
pr_err("%s: failed to find %s regmap!\n", __func__, ocotp_compat);
|
||||
}
|
||||
|
||||
if (!IS_ERR_OR_NULL(ocotp)) {
|
||||
regmap_read(ocotp, OCOTP_UID_H, &val);
|
||||
soc_uid = val;
|
||||
regmap_read(ocotp, OCOTP_UID_L, &val);
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user