mirror of
https://github.com/torvalds/linux.git
synced 2024-11-26 14:12:06 +00:00
Linux 6.0
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmM5/fMeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG+Y0H/jG0HQjUHfIOGjPQ
T33eaF5POoZKzZmsTNITbtya7B3/OTZZRGdSq9B8t5tElyPnZrdIfaXds17mCI8y
5DJUEQGdv6fqRttYLGKf6rk1kzABhhaTS8n9BgDFEsmvdqwG4AV6dLQr3HL09gTV
Lu+Is86RPwmpgH0Z9u7DyFCF8yLjefyu0vl6eFm/SXjCE8gQM/LZQSi9mv5/YDxa
MVKlsZKIkQm6P8a6r8wbGedKYBped4+4gYedsf/IcS0lvKdLIs/P7YgR5wKklSbM
tqECvBOmKq1Fwj/oxH+fx0KLX/ZD1xxQwoQd+a9DOSo+BuPBt6KGojYT9gQRyFJp
R7gyUCo=
=2UOD
-----END PGP SIGNATURE-----
Merge tag 'v6.0' into rdma.git for-next
Trvial merge conflicts against rdma.git for-rc resolved matching
linux-next:
drivers/infiniband/hw/hns/hns_roce_hw_v2.c
drivers/infiniband/hw/hns/hns_roce_main.c
https://lore.kernel.org/r/20220929124005.105149-1-broonie@kernel.org
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
This commit is contained in:
Jason Gunthorpe
commit
33331a728c
@ -1,2 +1,4 @@
|
||||
Alan Cox <alan@lxorguk.ukuu.org.uk>
|
||||
Alan Cox <root@hraefn.swansea.linux.org.uk>
|
||||
Christoph Hellwig <hch@lst.de>
|
||||
Marc Gonzalez <marc.w.gonzalez@free.fr>
|
||||
|
||||
10
.mailmap
10
.mailmap
@ -71,6 +71,9 @@ Ben M Cahill <ben.m.cahill@intel.com>
|
||||
Ben Widawsky <bwidawsk@kernel.org> <ben@bwidawsk.net>
|
||||
Ben Widawsky <bwidawsk@kernel.org> <ben.widawsky@intel.com>
|
||||
Ben Widawsky <bwidawsk@kernel.org> <benjamin.widawsky@intel.com>
|
||||
Bjorn Andersson <andersson@kernel.org> <bjorn@kryo.se>
|
||||
Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@linaro.org>
|
||||
Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@sonymobile.com>
|
||||
Björn Steinbrink <B.Steinbrink@gmx.de>
|
||||
Björn Töpel <bjorn@kernel.org> <bjorn.topel@gmail.com>
|
||||
Björn Töpel <bjorn@kernel.org> <bjorn.topel@intel.com>
|
||||
@ -98,8 +101,7 @@ Christian Brauner <brauner@kernel.org> <christian.brauner@ubuntu.com>
|
||||
Christian Marangi <ansuelsmth@gmail.com>
|
||||
Christophe Ricard <christophe.ricard@gmail.com>
|
||||
Christoph Hellwig <hch@lst.de>
|
||||
Colin Ian King <colin.king@intel.com> <colin.king@canonical.com>
|
||||
Colin Ian King <colin.king@intel.com> <colin.i.king@gmail.com>
|
||||
Colin Ian King <colin.i.king@gmail.com> <colin.king@canonical.com>
|
||||
Corey Minyard <minyard@acm.org>
|
||||
Damian Hobson-Garcia <dhobsong@igel.co.jp>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@googlemail.com>
|
||||
@ -150,6 +152,8 @@ Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Greg Kroah-Hartman <greg@kroah.com>
|
||||
Greg Kurz <groug@kaod.org> <gkurz@linux.vnet.ibm.com>
|
||||
Gregory CLEMENT <gregory.clement@bootlin.com> <gregory.clement@free-electrons.com>
|
||||
Guilherme G. Piccoli <kernel@gpiccoli.net> <gpiccoli@linux.vnet.ibm.com>
|
||||
Guilherme G. Piccoli <kernel@gpiccoli.net> <gpiccoli@canonical.com>
|
||||
Guo Ren <guoren@kernel.org> <guoren@linux.alibaba.com>
|
||||
Guo Ren <guoren@kernel.org> <ren_guo@c-sky.com>
|
||||
Gustavo Padovan <gustavo@las.ic.unicamp.br>
|
||||
@ -253,6 +257,7 @@ Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
|
||||
Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
|
||||
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
|
||||
Lorenzo Pieralisi <lpieralisi@kernel.org> <lorenzo.pieralisi@arm.com>
|
||||
Luca Ceresoli <luca.ceresoli@bootlin.com> <luca@lucaceresoli.net>
|
||||
Lukasz Luba <lukasz.luba@arm.com> <l.luba@partner.samsung.com>
|
||||
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
|
||||
Maciej W. Rozycki <macro@orcam.me.uk> <macro@linux-mips.org>
|
||||
@ -313,6 +318,7 @@ Morten Welinder <welinder@troll.com>
|
||||
Mythri P K <mythripk@ti.com>
|
||||
Nadia Yvette Chambers <nyc@holomorphy.com> William Lee Irwin III <wli@holomorphy.com>
|
||||
Nathan Chancellor <nathan@kernel.org> <natechancellor@gmail.com>
|
||||
Neil Armstrong <neil.armstrong@linaro.org> <narmstrong@baylibre.com>
|
||||
Nguyen Anh Quynh <aquynh@gmail.com>
|
||||
Nicholas Piggin <npiggin@gmail.com> <npiggen@suse.de>
|
||||
Nicholas Piggin <npiggin@gmail.com> <npiggin@kernel.dk>
|
||||
|
||||
@ -523,6 +523,7 @@ What: /sys/devices/system/cpu/vulnerabilities
|
||||
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
|
||||
/sys/devices/system/cpu/vulnerabilities/itlb_multihit
|
||||
/sys/devices/system/cpu/vulnerabilities/mmio_stale_data
|
||||
/sys/devices/system/cpu/vulnerabilities/retbleed
|
||||
Date: January 2018
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Information about CPU vulnerabilities
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
.. _readme:
|
||||
|
||||
Linux kernel release 5.x <http://kernel.org/>
|
||||
Linux kernel release 6.x <http://kernel.org/>
|
||||
=============================================
|
||||
|
||||
These are the release notes for Linux version 5. Read them carefully,
|
||||
These are the release notes for Linux version 6. Read them carefully,
|
||||
as they tell you what this is all about, explain how to install the
|
||||
kernel, and what to do if something goes wrong.
|
||||
|
||||
@ -63,7 +63,7 @@ Installing the kernel source
|
||||
directory where you have permissions (e.g. your home directory) and
|
||||
unpack it::
|
||||
|
||||
xz -cd linux-5.x.tar.xz | tar xvf -
|
||||
xz -cd linux-6.x.tar.xz | tar xvf -
|
||||
|
||||
Replace "X" with the version number of the latest kernel.
|
||||
|
||||
@ -72,12 +72,12 @@ Installing the kernel source
|
||||
files. They should match the library, and not get messed up by
|
||||
whatever the kernel-du-jour happens to be.
|
||||
|
||||
- You can also upgrade between 5.x releases by patching. Patches are
|
||||
- You can also upgrade between 6.x releases by patching. Patches are
|
||||
distributed in the xz format. To install by patching, get all the
|
||||
newer patch files, enter the top level directory of the kernel source
|
||||
(linux-5.x) and execute::
|
||||
(linux-6.x) and execute::
|
||||
|
||||
xz -cd ../patch-5.x.xz | patch -p1
|
||||
xz -cd ../patch-6.x.xz | patch -p1
|
||||
|
||||
Replace "x" for all versions bigger than the version "x" of your current
|
||||
source tree, **in_order**, and you should be ok. You may want to remove
|
||||
@ -85,13 +85,13 @@ Installing the kernel source
|
||||
that there are no failed patches (some-file-name# or some-file-name.rej).
|
||||
If there are, either you or I have made a mistake.
|
||||
|
||||
Unlike patches for the 5.x kernels, patches for the 5.x.y kernels
|
||||
Unlike patches for the 6.x kernels, patches for the 6.x.y kernels
|
||||
(also known as the -stable kernels) are not incremental but instead apply
|
||||
directly to the base 5.x kernel. For example, if your base kernel is 5.0
|
||||
and you want to apply the 5.0.3 patch, you must not first apply the 5.0.1
|
||||
and 5.0.2 patches. Similarly, if you are running kernel version 5.0.2 and
|
||||
want to jump to 5.0.3, you must first reverse the 5.0.2 patch (that is,
|
||||
patch -R) **before** applying the 5.0.3 patch. You can read more on this in
|
||||
directly to the base 6.x kernel. For example, if your base kernel is 6.0
|
||||
and you want to apply the 6.0.3 patch, you must not first apply the 6.0.1
|
||||
and 6.0.2 patches. Similarly, if you are running kernel version 6.0.2 and
|
||||
want to jump to 6.0.3, you must first reverse the 6.0.2 patch (that is,
|
||||
patch -R) **before** applying the 6.0.3 patch. You can read more on this in
|
||||
:ref:`Documentation/process/applying-patches.rst <applying_patches>`.
|
||||
|
||||
Alternatively, the script patch-kernel can be used to automate this
|
||||
@ -114,7 +114,7 @@ Installing the kernel source
|
||||
Software requirements
|
||||
---------------------
|
||||
|
||||
Compiling and running the 5.x kernels requires up-to-date
|
||||
Compiling and running the 6.x kernels requires up-to-date
|
||||
versions of various software packages. Consult
|
||||
:ref:`Documentation/process/changes.rst <changes>` for the minimum version numbers
|
||||
required and how to get updates for these packages. Beware that using
|
||||
@ -132,12 +132,12 @@ Build directory for the kernel
|
||||
place for the output files (including .config).
|
||||
Example::
|
||||
|
||||
kernel source code: /usr/src/linux-5.x
|
||||
kernel source code: /usr/src/linux-6.x
|
||||
build directory: /home/name/build/kernel
|
||||
|
||||
To configure and build the kernel, use::
|
||||
|
||||
cd /usr/src/linux-5.x
|
||||
cd /usr/src/linux-6.x
|
||||
make O=/home/name/build/kernel menuconfig
|
||||
make O=/home/name/build/kernel
|
||||
sudo make O=/home/name/build/kernel modules_install install
|
||||
|
||||
@ -230,6 +230,20 @@ The possible values in this file are:
|
||||
* - 'Mitigation: Clear CPU buffers'
|
||||
- The processor is vulnerable and the CPU buffer clearing mitigation is
|
||||
enabled.
|
||||
* - 'Unknown: No mitigations'
|
||||
- The processor vulnerability status is unknown because it is
|
||||
out of Servicing period. Mitigation is not attempted.
|
||||
|
||||
Definitions:
|
||||
------------
|
||||
|
||||
Servicing period: The process of providing functional and security updates to
|
||||
Intel processors or platforms, utilizing the Intel Platform Update (IPU)
|
||||
process or other similar mechanisms.
|
||||
|
||||
End of Servicing Updates (ESU): ESU is the date at which Intel will no
|
||||
longer provide Servicing, such as through IPU or other similar update
|
||||
processes. ESU dates will typically be aligned to end of quarter.
|
||||
|
||||
If the processor is vulnerable then the following information is appended to
|
||||
the above information:
|
||||
|
||||
@ -5331,6 +5331,8 @@
|
||||
rodata= [KNL]
|
||||
on Mark read-only kernel memory as read-only (default).
|
||||
off Leave read-only kernel memory writable for debugging.
|
||||
full Mark read-only kernel memory and aliases as read-only
|
||||
[arm64]
|
||||
|
||||
rockchip.usb_uart
|
||||
Enable the uart passthrough on the designated usb port
|
||||
|
||||
@ -50,10 +50,10 @@ For a short example, users can monitor the virtual address space of a given
|
||||
workload as below. ::
|
||||
|
||||
# cd /sys/kernel/mm/damon/admin/
|
||||
# echo 1 > kdamonds/nr && echo 1 > kdamonds/0/contexts/nr
|
||||
# echo 1 > kdamonds/nr_kdamonds && echo 1 > kdamonds/0/contexts/nr_contexts
|
||||
# echo vaddr > kdamonds/0/contexts/0/operations
|
||||
# echo 1 > kdamonds/0/contexts/0/targets/nr
|
||||
# echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid
|
||||
# echo 1 > kdamonds/0/contexts/0/targets/nr_targets
|
||||
# echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid_target
|
||||
# echo on > kdamonds/0/state
|
||||
|
||||
Files Hierarchy
|
||||
@ -366,12 +366,12 @@ memory rate becomes larger than 60%, or lower than 30%". ::
|
||||
# echo 1 > kdamonds/0/contexts/0/schemes/nr_schemes
|
||||
# cd kdamonds/0/contexts/0/schemes/0
|
||||
# # set the basic access pattern and the action
|
||||
# echo 4096 > access_patterns/sz/min
|
||||
# echo 8192 > access_patterns/sz/max
|
||||
# echo 0 > access_patterns/nr_accesses/min
|
||||
# echo 5 > access_patterns/nr_accesses/max
|
||||
# echo 10 > access_patterns/age/min
|
||||
# echo 20 > access_patterns/age/max
|
||||
# echo 4096 > access_pattern/sz/min
|
||||
# echo 8192 > access_pattern/sz/max
|
||||
# echo 0 > access_pattern/nr_accesses/min
|
||||
# echo 5 > access_pattern/nr_accesses/max
|
||||
# echo 10 > access_pattern/age/min
|
||||
# echo 20 > access_pattern/age/max
|
||||
# echo pageout > action
|
||||
# # set quotas
|
||||
# echo 10 > quotas/ms
|
||||
|
||||
@ -271,7 +271,7 @@ poll cycle or the number of packets processed reaches netdev_budget.
|
||||
netdev_max_backlog
|
||||
------------------
|
||||
|
||||
Maximum number of packets, queued on the INPUT side, when the interface
|
||||
Maximum number of packets, queued on the INPUT side, when the interface
|
||||
receives packets faster than kernel can process them.
|
||||
|
||||
netdev_rss_key
|
||||
|
||||
@ -242,44 +242,34 @@ HWCAP2_MTE3
|
||||
by Documentation/arm64/memory-tagging-extension.rst.
|
||||
|
||||
HWCAP2_SME
|
||||
|
||||
Functionality implied by ID_AA64PFR1_EL1.SME == 0b0001, as described
|
||||
by Documentation/arm64/sme.rst.
|
||||
|
||||
HWCAP2_SME_I16I64
|
||||
|
||||
Functionality implied by ID_AA64SMFR0_EL1.I16I64 == 0b1111.
|
||||
|
||||
HWCAP2_SME_F64F64
|
||||
|
||||
Functionality implied by ID_AA64SMFR0_EL1.F64F64 == 0b1.
|
||||
|
||||
HWCAP2_SME_I8I32
|
||||
|
||||
Functionality implied by ID_AA64SMFR0_EL1.I8I32 == 0b1111.
|
||||
|
||||
HWCAP2_SME_F16F32
|
||||
|
||||
Functionality implied by ID_AA64SMFR0_EL1.F16F32 == 0b1.
|
||||
|
||||
HWCAP2_SME_B16F32
|
||||
|
||||
Functionality implied by ID_AA64SMFR0_EL1.B16F32 == 0b1.
|
||||
|
||||
HWCAP2_SME_F32F32
|
||||
|
||||
Functionality implied by ID_AA64SMFR0_EL1.F32F32 == 0b1.
|
||||
|
||||
HWCAP2_SME_FA64
|
||||
|
||||
Functionality implied by ID_AA64SMFR0_EL1.FA64 == 0b1.
|
||||
|
||||
HWCAP2_WFXT
|
||||
|
||||
Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010.
|
||||
|
||||
HWCAP2_EBF16
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0010.
|
||||
|
||||
4. Unused AT_HWCAP bits
|
||||
|
||||
@ -52,6 +52,8 @@ stable kernels.
|
||||
| Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 |
|
||||
|
||||
@ -58,13 +58,11 @@ Like with atomic_t, the rule of thumb is:
|
||||
|
||||
- RMW operations that have a return value are fully ordered.
|
||||
|
||||
- RMW operations that are conditional are unordered on FAILURE,
|
||||
otherwise the above rules apply. In the case of test_and_{}_bit() operations,
|
||||
if the bit in memory is unchanged by the operation then it is deemed to have
|
||||
failed.
|
||||
- RMW operations that are conditional are fully ordered.
|
||||
|
||||
Except for a successful test_and_set_bit_lock() which has ACQUIRE semantics and
|
||||
clear_bit_unlock() which has RELEASE semantics.
|
||||
Except for a successful test_and_set_bit_lock() which has ACQUIRE semantics,
|
||||
clear_bit_unlock() which has RELEASE semantics and test_bit_acquire which has
|
||||
ACQUIRE semantics.
|
||||
|
||||
Since a platform only has a single means of achieving atomic operations
|
||||
the same barriers as for atomic_t are used, see atomic_t.txt.
|
||||
|
||||
@ -23,3 +23,4 @@ Block
|
||||
stat
|
||||
switching-sched
|
||||
writeback_cache_control
|
||||
ublk
|
||||
|
||||
253
Documentation/block/ublk.rst
Normal file
253
Documentation/block/ublk.rst
Normal file
@ -0,0 +1,253 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===========================================
|
||||
Userspace block device driver (ublk driver)
|
||||
===========================================
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
ublk is a generic framework for implementing block device logic from userspace.
|
||||
The motivation behind it is that moving virtual block drivers into userspace,
|
||||
such as loop, nbd and similar can be very helpful. It can help to implement
|
||||
new virtual block device such as ublk-qcow2 (there are several attempts of
|
||||
implementing qcow2 driver in kernel).
|
||||
|
||||
Userspace block devices are attractive because:
|
||||
|
||||
- They can be written many programming languages.
|
||||
- They can use libraries that are not available in the kernel.
|
||||
- They can be debugged with tools familiar to application developers.
|
||||
- Crashes do not kernel panic the machine.
|
||||
- Bugs are likely to have a lower security impact than bugs in kernel
|
||||
code.
|
||||
- They can be installed and updated independently of the kernel.
|
||||
- They can be used to simulate block device easily with user specified
|
||||
parameters/setting for test/debug purpose
|
||||
|
||||
ublk block device (``/dev/ublkb*``) is added by ublk driver. Any IO request
|
||||
on the device will be forwarded to ublk userspace program. For convenience,
|
||||
in this document, ``ublk server`` refers to generic ublk userspace
|
||||
program. ``ublksrv`` [#userspace]_ is one of such implementation. It
|
||||
provides ``libublksrv`` [#userspace_lib]_ library for developing specific
|
||||
user block device conveniently, while also generic type block device is
|
||||
included, such as loop and null. Richard W.M. Jones wrote userspace nbd device
|
||||
``nbdublk`` [#userspace_nbdublk]_ based on ``libublksrv`` [#userspace_lib]_.
|
||||
|
||||
After the IO is handled by userspace, the result is committed back to the
|
||||
driver, thus completing the request cycle. This way, any specific IO handling
|
||||
logic is totally done by userspace, such as loop's IO handling, NBD's IO
|
||||
communication, or qcow2's IO mapping.
|
||||
|
||||
``/dev/ublkb*`` is driven by blk-mq request-based driver. Each request is
|
||||
assigned by one queue wide unique tag. ublk server assigns unique tag to each
|
||||
IO too, which is 1:1 mapped with IO of ``/dev/ublkb*``.
|
||||
|
||||
Both the IO request forward and IO handling result committing are done via
|
||||
``io_uring`` passthrough command; that is why ublk is also one io_uring based
|
||||
block driver. It has been observed that using io_uring passthrough command can
|
||||
give better IOPS than block IO; which is why ublk is one of high performance
|
||||
implementation of userspace block device: not only IO request communication is
|
||||
done by io_uring, but also the preferred IO handling in ublk server is io_uring
|
||||
based approach too.
|
||||
|
||||
ublk provides control interface to set/get ublk block device parameters.
|
||||
The interface is extendable and kabi compatible: basically any ublk request
|
||||
queue's parameter or ublk generic feature parameters can be set/get via the
|
||||
interface. Thus, ublk is generic userspace block device framework.
|
||||
For example, it is easy to setup a ublk device with specified block
|
||||
parameters from userspace.
|
||||
|
||||
Using ublk
|
||||
==========
|
||||
|
||||
ublk requires userspace ublk server to handle real block device logic.
|
||||
|
||||
Below is example of using ``ublksrv`` to provide ublk-based loop device.
|
||||
|
||||
- add a device::
|
||||
|
||||
ublk add -t loop -f ublk-loop.img
|
||||
|
||||
- format with xfs, then use it::
|
||||
|
||||
mkfs.xfs /dev/ublkb0
|
||||
mount /dev/ublkb0 /mnt
|
||||
# do anything. all IOs are handled by io_uring
|
||||
...
|
||||
umount /mnt
|
||||
|
||||
- list the devices with their info::
|
||||
|
||||
ublk list
|
||||
|
||||
- delete the device::
|
||||
|
||||
ublk del -a
|
||||
ublk del -n $ublk_dev_id
|
||||
|
||||
See usage details in README of ``ublksrv`` [#userspace_readme]_.
|
||||
|
||||
Design
|
||||
======
|
||||
|
||||
Control plane
|
||||
-------------
|
||||
|
||||
ublk driver provides global misc device node (``/dev/ublk-control``) for
|
||||
managing and controlling ublk devices with help of several control commands:
|
||||
|
||||
- ``UBLK_CMD_ADD_DEV``
|
||||
|
||||
Add a ublk char device (``/dev/ublkc*``) which is talked with ublk server
|
||||
WRT IO command communication. Basic device info is sent together with this
|
||||
command. It sets UAPI structure of ``ublksrv_ctrl_dev_info``,
|
||||
such as ``nr_hw_queues``, ``queue_depth``, and max IO request buffer size,
|
||||
for which the info is negotiated with the driver and sent back to the server.
|
||||
When this command is completed, the basic device info is immutable.
|
||||
|
||||
- ``UBLK_CMD_SET_PARAMS`` / ``UBLK_CMD_GET_PARAMS``
|
||||
|
||||
Set or get parameters of the device, which can be either generic feature
|
||||
related, or request queue limit related, but can't be IO logic specific,
|
||||
because the driver does not handle any IO logic. This command has to be
|
||||
sent before sending ``UBLK_CMD_START_DEV``.
|
||||
|
||||
- ``UBLK_CMD_START_DEV``
|
||||
|
||||
After the server prepares userspace resources (such as creating per-queue
|
||||
pthread & io_uring for handling ublk IO), this command is sent to the
|
||||
driver for allocating & exposing ``/dev/ublkb*``. Parameters set via
|
||||
``UBLK_CMD_SET_PARAMS`` are applied for creating the device.
|
||||
|
||||
- ``UBLK_CMD_STOP_DEV``
|
||||
|
||||
Halt IO on ``/dev/ublkb*`` and remove the device. When this command returns,
|
||||
ublk server will release resources (such as destroying per-queue pthread &
|
||||
io_uring).
|
||||
|
||||
- ``UBLK_CMD_DEL_DEV``
|
||||
|
||||
Remove ``/dev/ublkc*``. When this command returns, the allocated ublk device
|
||||
number can be reused.
|
||||
|
||||
- ``UBLK_CMD_GET_QUEUE_AFFINITY``
|
||||
|
||||
When ``/dev/ublkc`` is added, the driver creates block layer tagset, so
|
||||
that each queue's affinity info is available. The server sends
|
||||
``UBLK_CMD_GET_QUEUE_AFFINITY`` to retrieve queue affinity info. It can
|
||||
set up the per-queue context efficiently, such as bind affine CPUs with IO
|
||||
pthread and try to allocate buffers in IO thread context.
|
||||
|
||||
- ``UBLK_CMD_GET_DEV_INFO``
|
||||
|
||||
For retrieving device info via ``ublksrv_ctrl_dev_info``. It is the server's
|
||||
responsibility to save IO target specific info in userspace.
|
||||
|
||||
Data plane
|
||||
----------
|
||||
|
||||
ublk server needs to create per-queue IO pthread & io_uring for handling IO
|
||||
commands via io_uring passthrough. The per-queue IO pthread
|
||||
focuses on IO handling and shouldn't handle any control & management
|
||||
tasks.
|
||||
|
||||
The's IO is assigned by a unique tag, which is 1:1 mapping with IO
|
||||
request of ``/dev/ublkb*``.
|
||||
|
||||
UAPI structure of ``ublksrv_io_desc`` is defined for describing each IO from
|
||||
the driver. A fixed mmaped area (array) on ``/dev/ublkc*`` is provided for
|
||||
exporting IO info to the server; such as IO offset, length, OP/flags and
|
||||
buffer address. Each ``ublksrv_io_desc`` instance can be indexed via queue id
|
||||
and IO tag directly.
|
||||
|
||||
The following IO commands are communicated via io_uring passthrough command,
|
||||
and each command is only for forwarding the IO and committing the result
|
||||
with specified IO tag in the command data:
|
||||
|
||||
- ``UBLK_IO_FETCH_REQ``
|
||||
|
||||
Sent from the server IO pthread for fetching future incoming IO requests
|
||||
destined to ``/dev/ublkb*``. This command is sent only once from the server
|
||||
IO pthread for ublk driver to setup IO forward environment.
|
||||
|
||||
- ``UBLK_IO_COMMIT_AND_FETCH_REQ``
|
||||
|
||||
When an IO request is destined to ``/dev/ublkb*``, the driver stores
|
||||
the IO's ``ublksrv_io_desc`` to the specified mapped area; then the
|
||||
previous received IO command of this IO tag (either ``UBLK_IO_FETCH_REQ``
|
||||
or ``UBLK_IO_COMMIT_AND_FETCH_REQ)`` is completed, so the server gets
|
||||
the IO notification via io_uring.
|
||||
|
||||
After the server handles the IO, its result is committed back to the
|
||||
driver by sending ``UBLK_IO_COMMIT_AND_FETCH_REQ`` back. Once ublkdrv
|
||||
received this command, it parses the result and complete the request to
|
||||
``/dev/ublkb*``. In the meantime setup environment for fetching future
|
||||
requests with the same IO tag. That is, ``UBLK_IO_COMMIT_AND_FETCH_REQ``
|
||||
is reused for both fetching request and committing back IO result.
|
||||
|
||||
- ``UBLK_IO_NEED_GET_DATA``
|
||||
|
||||
With ``UBLK_F_NEED_GET_DATA`` enabled, the WRITE request will be firstly
|
||||
issued to ublk server without data copy. Then, IO backend of ublk server
|
||||
receives the request and it can allocate data buffer and embed its addr
|
||||
inside this new io command. After the kernel driver gets the command,
|
||||
data copy is done from request pages to this backend's buffer. Finally,
|
||||
backend receives the request again with data to be written and it can
|
||||
truly handle the request.
|
||||
|
||||
``UBLK_IO_NEED_GET_DATA`` adds one additional round-trip and one
|
||||
io_uring_enter() syscall. Any user thinks that it may lower performance
|
||||
should not enable UBLK_F_NEED_GET_DATA. ublk server pre-allocates IO
|
||||
buffer for each IO by default. Any new project should try to use this
|
||||
buffer to communicate with ublk driver. However, existing project may
|
||||
break or not able to consume the new buffer interface; that's why this
|
||||
command is added for backwards compatibility so that existing projects
|
||||
can still consume existing buffers.
|
||||
|
||||
- data copy between ublk server IO buffer and ublk block IO request
|
||||
|
||||
The driver needs to copy the block IO request pages into the server buffer
|
||||
(pages) first for WRITE before notifying the server of the coming IO, so
|
||||
that the server can handle WRITE request.
|
||||
|
||||
When the server handles READ request and sends
|
||||
``UBLK_IO_COMMIT_AND_FETCH_REQ`` to the server, ublkdrv needs to copy
|
||||
the server buffer (pages) read to the IO request pages.
|
||||
|
||||
Future development
|
||||
==================
|
||||
|
||||
Container-aware ublk deivice
|
||||
----------------------------
|
||||
|
||||
ublk driver doesn't handle any IO logic. Its function is well defined
|
||||
for now and very limited userspace interfaces are needed, which is also
|
||||
well defined too. It is possible to make ublk devices container-aware block
|
||||
devices in future as Stefan Hajnoczi suggested [#stefan]_, by removing
|
||||
ADMIN privilege.
|
||||
|
||||
Zero copy
|
||||
---------
|
||||
|
||||
Zero copy is a generic requirement for nbd, fuse or similar drivers. A
|
||||
problem [#xiaoguang]_ Xiaoguang mentioned is that pages mapped to userspace
|
||||
can't be remapped any more in kernel with existing mm interfaces. This can
|
||||
occurs when destining direct IO to ``/dev/ublkb*``. Also, he reported that
|
||||
big requests (IO size >= 256 KB) may benefit a lot from zero copy.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#userspace] https://github.com/ming1/ubdsrv
|
||||
|
||||
.. [#userspace_lib] https://github.com/ming1/ubdsrv/tree/master/lib
|
||||
|
||||
.. [#userspace_nbdublk] https://gitlab.com/rwmjones/libnbd/-/tree/nbdublk
|
||||
|
||||
.. [#userspace_readme] https://github.com/ming1/ubdsrv/blob/master/README
|
||||
|
||||
.. [#stefan] https://lore.kernel.org/linux-block/YoOr6jBfgVm8GvWg@stefanha-x1.localdomain/
|
||||
|
||||
.. [#xiaoguang] https://lore.kernel.org/linux-block/YoOr6jBfgVm8GvWg@stefanha-x1.localdomain/
|
||||
@ -86,6 +86,7 @@ if major >= 3:
|
||||
"__used",
|
||||
"__weak",
|
||||
"noinline",
|
||||
"__fix_address",
|
||||
|
||||
# include/linux/memblock.h:
|
||||
"__init_memblock",
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Meson Firmware registers Interface
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
description: |
|
||||
The Meson SoCs have a register bank with status and data shared with the
|
||||
|
||||
@ -233,6 +233,7 @@ allOf:
|
||||
- allwinner,sun8i-a83t-tcon-lcd
|
||||
- allwinner,sun8i-v3s-tcon
|
||||
- allwinner,sun9i-a80-tcon-lcd
|
||||
- allwinner,sun20i-d1-tcon-lcd
|
||||
|
||||
then:
|
||||
properties:
|
||||
@ -252,6 +253,7 @@ allOf:
|
||||
- allwinner,sun8i-a83t-tcon-tv
|
||||
- allwinner,sun8i-r40-tcon-tv
|
||||
- allwinner,sun9i-a80-tcon-tv
|
||||
- allwinner,sun20i-d1-tcon-tv
|
||||
|
||||
then:
|
||||
properties:
|
||||
@ -278,6 +280,7 @@ allOf:
|
||||
- allwinner,sun9i-a80-tcon-lcd
|
||||
- allwinner,sun4i-a10-tcon
|
||||
- allwinner,sun8i-a83t-tcon-lcd
|
||||
- allwinner,sun20i-d1-tcon-lcd
|
||||
|
||||
then:
|
||||
required:
|
||||
@ -294,6 +297,7 @@ allOf:
|
||||
- allwinner,sun8i-a23-tcon
|
||||
- allwinner,sun8i-a33-tcon
|
||||
- allwinner,sun8i-a83t-tcon-lcd
|
||||
- allwinner,sun20i-d1-tcon-lcd
|
||||
|
||||
then:
|
||||
properties:
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic specific extensions to the Synopsys Designware HDMI Controller
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/sound/name-prefix.yaml#
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Meson Display Controller
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
description: |
|
||||
The Amlogic Meson Display controller is composed of several components
|
||||
|
||||
@ -8,7 +8,7 @@ title: Analogix ANX7814 SlimPort (Full-HD Transmitter)
|
||||
|
||||
maintainers:
|
||||
- Andrzej Hajda <andrzej.hajda@intel.com>
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
- Robert Foss <robert.foss@linaro.org>
|
||||
|
||||
properties:
|
||||
|
||||
@ -8,7 +8,7 @@ title: ITE it66121 HDMI bridge Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Phong LE <ple@baylibre.com>
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
description: |
|
||||
The IT66121 is a high-performance and low-power single channel HDMI
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Solomon Goldentek Display GKTW70SDAE4SE 7" WVGA LVDS Display Panel
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
allOf:
|
||||
|
||||
@ -34,8 +34,8 @@ Example:
|
||||
Use specific request line passing from dma
|
||||
For example, MMC request line is 5
|
||||
|
||||
sdhci: sdhci@98e00000 {
|
||||
compatible = "moxa,moxart-sdhci";
|
||||
mmc: mmc@98e00000 {
|
||||
compatible = "moxa,moxart-mmc";
|
||||
reg = <0x98e00000 0x5C>;
|
||||
interrupts = <5 0>;
|
||||
clocks = <&clk_apb>;
|
||||
|
||||
@ -48,7 +48,6 @@ required:
|
||||
- compatible
|
||||
- reg
|
||||
- reg-names
|
||||
- intel,vm-map
|
||||
- clocks
|
||||
- resets
|
||||
- "#thermal-sensor-cells"
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Meson I2C Controller
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
- Beniamino Galvani <b.galvani@gmail.com>
|
||||
|
||||
allOf:
|
||||
|
||||
@ -60,6 +60,9 @@ properties:
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -57,6 +57,11 @@ properties:
|
||||
- description: interrupt ID for I2C event
|
||||
- description: interrupt ID for I2C error
|
||||
|
||||
interrupt-names:
|
||||
items:
|
||||
- const: event
|
||||
- const: error
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
@ -92,6 +97,8 @@ properties:
|
||||
- description: register offset within syscfg
|
||||
- description: register bitmask for FMP bit
|
||||
|
||||
wakeup-source: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -24,8 +24,10 @@ properties:
|
||||
|
||||
interrupts:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
description:
|
||||
Should be configured with type IRQ_TYPE_EDGE_RISING.
|
||||
If two interrupts are provided, expected order is INT1 and INT2.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
@ -16,6 +16,7 @@ properties:
|
||||
compatible:
|
||||
enum:
|
||||
- goodix,gt1151
|
||||
- goodix,gt1158
|
||||
- goodix,gt5663
|
||||
- goodix,gt5688
|
||||
- goodix,gt911
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Generic i.MX bus frequency device
|
||||
|
||||
maintainers:
|
||||
- Leonard Crestez <leonard.crestez@nxp.com>
|
||||
- Peng Fan <peng.fan@nxp.com>
|
||||
|
||||
description: |
|
||||
The i.MX SoC family has multiple buses for which clock frequency (and
|
||||
|
||||
@ -96,7 +96,7 @@ properties:
|
||||
Documentation/devicetree/bindings/arm/cpus.yaml).
|
||||
|
||||
required:
|
||||
- fiq-index
|
||||
- apple,fiq-index
|
||||
- cpus
|
||||
|
||||
required:
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Meson Message-Handling-Unit Controller
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
description: |
|
||||
The Amlogic's Meson SoCs Message-Handling-Unit (MHU) is a mailbox controller
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic GE2D Acceleration Unit
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Video Decoder
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
- Maxime Jourdan <mjourdan@baylibre.com>
|
||||
|
||||
description: |
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Meson AO-CEC Controller
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
description: |
|
||||
The Amlogic Meson AO-CEC module is present is Amlogic SoCs and its purpose is
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: i.MX8M DDR Controller
|
||||
|
||||
maintainers:
|
||||
- Leonard Crestez <leonard.crestez@nxp.com>
|
||||
- Peng Fan <peng.fan@nxp.com>
|
||||
|
||||
description:
|
||||
The DDRC block is integrated in i.MX8M for interfacing with DDR based
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Khadas on-board Microcontroller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
description: |
|
||||
Khadas embeds a microcontroller on their VIM and Edge boards adding some
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Meson DWMAC Ethernet controller
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
- Martin Blumenstingl <martin.blumenstingl@googlemail.com>
|
||||
|
||||
# We need a select here so we don't match all nodes with 'snps,dwmac'
|
||||
|
||||
@ -14,7 +14,7 @@ MAC node:
|
||||
- mac-address : The 6-byte MAC address. If present, it is the default
|
||||
MAC address.
|
||||
- internal-phy : phandle to the internal PHY node
|
||||
- phy-handle : phandle the external PHY node
|
||||
- phy-handle : phandle to the external PHY node
|
||||
|
||||
Internal PHY node:
|
||||
- compatible : Should be "qcom,fsm9900-emac-sgmii" or "qcom,qdf2432-emac-sgmii".
|
||||
|
||||
@ -40,6 +40,7 @@ properties:
|
||||
patternProperties:
|
||||
'^opp-?[0-9]+$':
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
opp-hz: true
|
||||
|
||||
@ -19,6 +19,7 @@ properties:
|
||||
patternProperties:
|
||||
'^opp-?[0-9]+$':
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
opp-level: true
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic AXG MIPI D-PHY
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic G12A USB2 PHY
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic G12A USB3 + PCIE Combo PHY
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@ -8,7 +8,6 @@ title: Qualcomm Technologies, Inc. Low Power Audio SubSystem (LPASS)
|
||||
Low Power Island (LPI) TLMM block
|
||||
|
||||
maintainers:
|
||||
- Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
|
||||
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
|
||||
description: |
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Technologies, Inc. SC7280 TLMM block
|
||||
|
||||
maintainers:
|
||||
- Rajendra Nayak <rnayak@codeaurora.org>
|
||||
- Bjorn Andersson <andersson@kernel.org>
|
||||
|
||||
description: |
|
||||
This binding describes the Top Level Mode Multiplexer block found in the
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Amlogic Meson Everything-Else Power Domains
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
description: |+
|
||||
The Everything-Else Power Domains node should be the child of a syscon
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm RPM/RPMh Power domains
|
||||
|
||||
maintainers:
|
||||
- Rajendra Nayak <rnayak@codeaurora.org>
|
||||
- Bjorn Andersson <andersson@kernel.org>
|
||||
|
||||
description:
|
||||
For RPM/RPMh Power domains, we communicate a performance state to RPM/RPMh
|
||||
|
||||
@ -47,12 +47,6 @@ properties:
|
||||
description:
|
||||
Properties for single LDO regulator.
|
||||
|
||||
properties:
|
||||
regulator-name:
|
||||
pattern: "^LDO[1-5]$"
|
||||
description:
|
||||
should be "LDO1", ..., "LDO5"
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
"^BUCK[1-6]$":
|
||||
@ -62,11 +56,6 @@ properties:
|
||||
Properties for single BUCK regulator.
|
||||
|
||||
properties:
|
||||
regulator-name:
|
||||
pattern: "^BUCK[1-6]$"
|
||||
description:
|
||||
should be "BUCK1", ..., "BUCK6"
|
||||
|
||||
nxp,dvs-run-voltage:
|
||||
$ref: "/schemas/types.yaml#/definitions/uint32"
|
||||
minimum: 600000
|
||||
|
||||
@ -35,6 +35,7 @@ patternProperties:
|
||||
description: List of regulators and its properties
|
||||
type: object
|
||||
$ref: regulator.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
qcom,ocp-max-retries:
|
||||
@ -100,8 +101,6 @@ patternProperties:
|
||||
SAW controlled gang leader. Will be configured as SAW regulator.
|
||||
type: boolean
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Meson SoC Reset Controller
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@ -17,9 +17,6 @@ description:
|
||||
acts as directory-based coherency manager.
|
||||
All the properties in ePAPR/DeviceTree specification applies for this platform.
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/cache-controller.yaml#
|
||||
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
@ -33,11 +30,16 @@ select:
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- sifive,fu540-c000-ccache
|
||||
- sifive,fu740-c000-ccache
|
||||
- const: cache
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- sifive,fu540-c000-ccache
|
||||
- sifive,fu740-c000-ccache
|
||||
- const: cache
|
||||
- items:
|
||||
- const: microchip,mpfs-ccache
|
||||
- const: sifive,fu540-c000-ccache
|
||||
- const: cache
|
||||
|
||||
cache-block-size:
|
||||
const: 64
|
||||
@ -72,29 +74,46 @@ properties:
|
||||
The reference to the reserved-memory for the L2 Loosely Integrated Memory region.
|
||||
The reserved memory node should be defined as per the bindings in reserved-memory.txt.
|
||||
|
||||
if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: sifive,fu540-c000-ccache
|
||||
allOf:
|
||||
- $ref: /schemas/cache-controller.yaml#
|
||||
|
||||
then:
|
||||
properties:
|
||||
interrupts:
|
||||
description: |
|
||||
Must contain entries for DirError, DataError and DataFail signals.
|
||||
maxItems: 3
|
||||
cache-sets:
|
||||
const: 1024
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- sifive,fu740-c000-ccache
|
||||
- microchip,mpfs-ccache
|
||||
|
||||
else:
|
||||
properties:
|
||||
interrupts:
|
||||
description: |
|
||||
Must contain entries for DirError, DataError, DataFail, DirFail signals.
|
||||
minItems: 4
|
||||
cache-sets:
|
||||
const: 2048
|
||||
then:
|
||||
properties:
|
||||
interrupts:
|
||||
description: |
|
||||
Must contain entries for DirError, DataError, DataFail, DirFail signals.
|
||||
minItems: 4
|
||||
|
||||
else:
|
||||
properties:
|
||||
interrupts:
|
||||
description: |
|
||||
Must contain entries for DirError, DataError and DataFail signals.
|
||||
maxItems: 3
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: sifive,fu740-c000-ccache
|
||||
|
||||
then:
|
||||
properties:
|
||||
cache-sets:
|
||||
const: 2048
|
||||
|
||||
else:
|
||||
properties:
|
||||
cache-sets:
|
||||
const: 1024
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Meson Random number generator
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Meson SoC UART Serial Interface
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
description: |
|
||||
The Amlogic Meson SoC UART Serial Interface is present on a large range
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Canvas Video Lookup Table
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
- Maxime Jourdan <mjourdan@baylibre.com>
|
||||
|
||||
description: |
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Meson SPI Communication Controller
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: "spi-controller.yaml#"
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Meson SPI Flash Controller
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: "spi-controller.yaml#"
|
||||
|
||||
@ -10,7 +10,7 @@ description:
|
||||
See spi-peripheral-props.yaml for more info.
|
||||
|
||||
maintainers:
|
||||
- Pratyush Yadav <p.yadav@ti.com>
|
||||
- Vaishnav Achath <vaishnav.a@ti.com>
|
||||
|
||||
properties:
|
||||
# cdns,qspi-nor.yaml
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Cadence Quad SPI controller
|
||||
|
||||
maintainers:
|
||||
- Pratyush Yadav <p.yadav@ti.com>
|
||||
- Vaishnav Achath <vaishnav.a@ti.com>
|
||||
|
||||
allOf:
|
||||
- $ref: spi-controller.yaml#
|
||||
|
||||
@ -16,7 +16,7 @@ description:
|
||||
their own separate schema that should be referenced from here.
|
||||
|
||||
maintainers:
|
||||
- Pratyush Yadav <p.yadav@ti.com>
|
||||
- Mark Brown <broonie@kernel.org>
|
||||
|
||||
properties:
|
||||
reg:
|
||||
|
||||
@ -42,7 +42,7 @@ properties:
|
||||
description:
|
||||
Address ranges of the thermal registers. If more then one range is given
|
||||
the first one must be the common registers followed by each sensor
|
||||
according the datasheet.
|
||||
according to the datasheet.
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
|
||||
|
||||
@ -214,6 +214,7 @@ patternProperties:
|
||||
- polling-delay
|
||||
- polling-delay-passive
|
||||
- thermal-sensors
|
||||
- trips
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Amlogic Meson G12A DWC3 USB SoC Controller Glue
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
description: |
|
||||
The Amlogic G12A embeds a DWC3 USB IP Core configured for USB2 and USB3
|
||||
|
||||
@ -24,6 +24,7 @@ properties:
|
||||
- mediatek,mt2712-mtu3
|
||||
- mediatek,mt8173-mtu3
|
||||
- mediatek,mt8183-mtu3
|
||||
- mediatek,mt8188-mtu3
|
||||
- mediatek,mt8192-mtu3
|
||||
- mediatek,mt8195-mtu3
|
||||
- const: mediatek,mtu3
|
||||
|
||||
@ -33,6 +33,7 @@ properties:
|
||||
- qcom,sm6115-dwc3
|
||||
- qcom,sm6125-dwc3
|
||||
- qcom,sm6350-dwc3
|
||||
- qcom,sm6375-dwc3
|
||||
- qcom,sm8150-dwc3
|
||||
- qcom,sm8250-dwc3
|
||||
- qcom,sm8350-dwc3
|
||||
@ -108,12 +109,17 @@ properties:
|
||||
HS/FS/LS modes are supported.
|
||||
type: boolean
|
||||
|
||||
wakeup-source: true
|
||||
|
||||
# Required child node:
|
||||
|
||||
patternProperties:
|
||||
"^usb@[0-9a-f]+$":
|
||||
$ref: snps,dwc3.yaml#
|
||||
|
||||
properties:
|
||||
wakeup-source: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
title: Meson GXBB SoCs Watchdog timer
|
||||
|
||||
maintainers:
|
||||
- Neil Armstrong <narmstrong@baylibre.com>
|
||||
- Neil Armstrong <neil.armstrong@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: watchdog.yaml#
|
||||
|
||||
@ -64,7 +64,7 @@ correct address for this module, you could get in big trouble (read:
|
||||
crashes, data corruption, etc.). Try this only as a last resort (try BIOS
|
||||
updates first, for example), and backup first! An even more dangerous
|
||||
option is 'force_addr=<IOPORT>'. This will not only enable the PIIX4 like
|
||||
'force' foes, but it will also set a new base I/O port address. The SMBus
|
||||
'force' does, but it will also set a new base I/O port address. The SMBus
|
||||
parts of the PIIX4 needs a range of 8 of these addresses to function
|
||||
correctly. If these addresses are already reserved by some other device,
|
||||
you will get into big trouble! DON'T USE THIS IF YOU ARE NOT VERY SURE
|
||||
@ -86,15 +86,15 @@ If you own Force CPCI735 motherboard or other OSB4 based systems you may need
|
||||
to change the SMBus Interrupt Select register so the SMBus controller uses
|
||||
the SMI mode.
|
||||
|
||||
1) Use lspci command and locate the PCI device with the SMBus controller:
|
||||
1) Use ``lspci`` command and locate the PCI device with the SMBus controller:
|
||||
00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 4f)
|
||||
The line may vary for different chipsets. Please consult the driver source
|
||||
for all possible PCI ids (and lspci -n to match them). Lets assume the
|
||||
for all possible PCI ids (and ``lspci -n`` to match them). Let's assume the
|
||||
device is located at 00:0f.0.
|
||||
2) Now you just need to change the value in 0xD2 register. Get it first with
|
||||
command: lspci -xxx -s 00:0f.0
|
||||
command: ``lspci -xxx -s 00:0f.0``
|
||||
If the value is 0x3 then you need to change it to 0x1:
|
||||
setpci -s 00:0f.0 d2.b=1
|
||||
``setpci -s 00:0f.0 d2.b=1``
|
||||
|
||||
Please note that you don't need to do that in all cases, just when the SMBus is
|
||||
not working properly.
|
||||
@ -109,6 +109,3 @@ which can easily get corrupted due to a state machine bug. These are mostly
|
||||
Thinkpad laptops, but desktop systems may also be affected. We have no list
|
||||
of all affected systems, so the only safe solution was to prevent access to
|
||||
the SMBus on all IBM systems (detected using DMI data.)
|
||||
|
||||
For additional information, read:
|
||||
http://www.lm-sensors.org/browser/lm-sensors/trunk/README
|
||||
|
||||
@ -148,7 +148,7 @@ You can do plain I2C transactions by using read(2) and write(2) calls.
|
||||
You do not need to pass the address byte; instead, set it through
|
||||
ioctl I2C_SLAVE before you try to access the device.
|
||||
|
||||
You can do SMBus level transactions (see documentation file smbus-protocol
|
||||
You can do SMBus level transactions (see documentation file smbus-protocol.rst
|
||||
for details) through the following functions::
|
||||
|
||||
__s32 i2c_smbus_write_quick(int file, __u8 value);
|
||||
|
||||
@ -5,6 +5,8 @@ I2C muxes and complex topologies
|
||||
There are a couple of reasons for building more complex I2C topologies
|
||||
than a straight-forward I2C bus with one adapter and one or more devices.
|
||||
|
||||
Some example use cases are:
|
||||
|
||||
1. A mux may be needed on the bus to prevent address collisions.
|
||||
|
||||
2. The bus may be accessible from some external bus master, and arbitration
|
||||
@ -14,10 +16,10 @@ than a straight-forward I2C bus with one adapter and one or more devices.
|
||||
from the I2C bus, at least most of the time, and sits behind a gate
|
||||
that has to be operated before the device can be accessed.
|
||||
|
||||
Etc
|
||||
===
|
||||
Several types of hardware components such as I2C muxes, I2C gates and I2C
|
||||
arbitrators allow to handle such needs.
|
||||
|
||||
These constructs are represented as I2C adapter trees by Linux, where
|
||||
These components are represented as I2C adapter trees by Linux, where
|
||||
each adapter has a parent adapter (except the root adapter) and zero or
|
||||
more child adapters. The root adapter is the actual adapter that issues
|
||||
I2C transfers, and all adapters with a parent are part of an "i2c-mux"
|
||||
@ -35,46 +37,7 @@ Locking
|
||||
=======
|
||||
|
||||
There are two variants of locking available to I2C muxes, they can be
|
||||
mux-locked or parent-locked muxes. As is evident from below, it can be
|
||||
useful to know if a mux is mux-locked or if it is parent-locked. The
|
||||
following list was correct at the time of writing:
|
||||
|
||||
In drivers/i2c/muxes/:
|
||||
|
||||
====================== =============================================
|
||||
i2c-arb-gpio-challenge Parent-locked
|
||||
i2c-mux-gpio Normally parent-locked, mux-locked iff
|
||||
all involved gpio pins are controlled by the
|
||||
same I2C root adapter that they mux.
|
||||
i2c-mux-gpmux Normally parent-locked, mux-locked iff
|
||||
specified in device-tree.
|
||||
i2c-mux-ltc4306 Mux-locked
|
||||
i2c-mux-mlxcpld Parent-locked
|
||||
i2c-mux-pca9541 Parent-locked
|
||||
i2c-mux-pca954x Parent-locked
|
||||
i2c-mux-pinctrl Normally parent-locked, mux-locked iff
|
||||
all involved pinctrl devices are controlled
|
||||
by the same I2C root adapter that they mux.
|
||||
i2c-mux-reg Parent-locked
|
||||
====================== =============================================
|
||||
|
||||
In drivers/iio/:
|
||||
|
||||
====================== =============================================
|
||||
gyro/mpu3050 Mux-locked
|
||||
imu/inv_mpu6050/ Mux-locked
|
||||
====================== =============================================
|
||||
|
||||
In drivers/media/:
|
||||
|
||||
======================= =============================================
|
||||
dvb-frontends/lgdt3306a Mux-locked
|
||||
dvb-frontends/m88ds3103 Parent-locked
|
||||
dvb-frontends/rtl2830 Parent-locked
|
||||
dvb-frontends/rtl2832 Mux-locked
|
||||
dvb-frontends/si2168 Mux-locked
|
||||
usb/cx231xx/ Parent-locked
|
||||
======================= =============================================
|
||||
mux-locked or parent-locked muxes.
|
||||
|
||||
|
||||
Mux-locked muxes
|
||||
@ -89,40 +52,8 @@ full transaction, unrelated I2C transfers may interleave the different
|
||||
stages of the transaction. This has the benefit that the mux driver
|
||||
may be easier and cleaner to implement, but it has some caveats.
|
||||
|
||||
==== =====================================================================
|
||||
ML1. If you build a topology with a mux-locked mux being the parent
|
||||
of a parent-locked mux, this might break the expectation from the
|
||||
parent-locked mux that the root adapter is locked during the
|
||||
transaction.
|
||||
|
||||
ML2. It is not safe to build arbitrary topologies with two (or more)
|
||||
mux-locked muxes that are not siblings, when there are address
|
||||
collisions between the devices on the child adapters of these
|
||||
non-sibling muxes.
|
||||
|
||||
I.e. the select-transfer-deselect transaction targeting e.g. device
|
||||
address 0x42 behind mux-one may be interleaved with a similar
|
||||
operation targeting device address 0x42 behind mux-two. The
|
||||
intension with such a topology would in this hypothetical example
|
||||
be that mux-one and mux-two should not be selected simultaneously,
|
||||
but mux-locked muxes do not guarantee that in all topologies.
|
||||
|
||||
ML3. A mux-locked mux cannot be used by a driver for auto-closing
|
||||
gates/muxes, i.e. something that closes automatically after a given
|
||||
number (one, in most cases) of I2C transfers. Unrelated I2C transfers
|
||||
may creep in and close prematurely.
|
||||
|
||||
ML4. If any non-I2C operation in the mux driver changes the I2C mux state,
|
||||
the driver has to lock the root adapter during that operation.
|
||||
Otherwise garbage may appear on the bus as seen from devices
|
||||
behind the mux, when an unrelated I2C transfer is in flight during
|
||||
the non-I2C mux-changing operation.
|
||||
==== =====================================================================
|
||||
|
||||
|
||||
Mux-locked Example
|
||||
------------------
|
||||
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
@ -153,6 +84,43 @@ This means that accesses to D2 are lockout out for the full duration
|
||||
of the entire operation. But accesses to D3 are possibly interleaved
|
||||
at any point.
|
||||
|
||||
Mux-locked caveats
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When using a mux-locked mux, be aware of the following restrictions:
|
||||
|
||||
[ML1]
|
||||
If you build a topology with a mux-locked mux being the parent
|
||||
of a parent-locked mux, this might break the expectation from the
|
||||
parent-locked mux that the root adapter is locked during the
|
||||
transaction.
|
||||
|
||||
[ML2]
|
||||
It is not safe to build arbitrary topologies with two (or more)
|
||||
mux-locked muxes that are not siblings, when there are address
|
||||
collisions between the devices on the child adapters of these
|
||||
non-sibling muxes.
|
||||
|
||||
I.e. the select-transfer-deselect transaction targeting e.g. device
|
||||
address 0x42 behind mux-one may be interleaved with a similar
|
||||
operation targeting device address 0x42 behind mux-two. The
|
||||
intent with such a topology would in this hypothetical example
|
||||
be that mux-one and mux-two should not be selected simultaneously,
|
||||
but mux-locked muxes do not guarantee that in all topologies.
|
||||
|
||||
[ML3]
|
||||
A mux-locked mux cannot be used by a driver for auto-closing
|
||||
gates/muxes, i.e. something that closes automatically after a given
|
||||
number (one, in most cases) of I2C transfers. Unrelated I2C transfers
|
||||
may creep in and close prematurely.
|
||||
|
||||
[ML4]
|
||||
If any non-I2C operation in the mux driver changes the I2C mux state,
|
||||
the driver has to lock the root adapter during that operation.
|
||||
Otherwise garbage may appear on the bus as seen from devices
|
||||
behind the mux, when an unrelated I2C transfer is in flight during
|
||||
the non-I2C mux-changing operation.
|
||||
|
||||
|
||||
Parent-locked muxes
|
||||
-------------------
|
||||
@ -161,28 +129,10 @@ Parent-locked muxes lock the parent adapter during the full select-
|
||||
transfer-deselect transaction. The implication is that the mux driver
|
||||
has to ensure that any and all I2C transfers through that parent
|
||||
adapter during the transaction are unlocked I2C transfers (using e.g.
|
||||
__i2c_transfer), or a deadlock will follow. There are a couple of
|
||||
caveats.
|
||||
|
||||
==== ====================================================================
|
||||
PL1. If you build a topology with a parent-locked mux being the child
|
||||
of another mux, this might break a possible assumption from the
|
||||
child mux that the root adapter is unused between its select op
|
||||
and the actual transfer (e.g. if the child mux is auto-closing
|
||||
and the parent mux issues I2C transfers as part of its select).
|
||||
This is especially the case if the parent mux is mux-locked, but
|
||||
it may also happen if the parent mux is parent-locked.
|
||||
|
||||
PL2. If select/deselect calls out to other subsystems such as gpio,
|
||||
pinctrl, regmap or iio, it is essential that any I2C transfers
|
||||
caused by these subsystems are unlocked. This can be convoluted to
|
||||
accomplish, maybe even impossible if an acceptably clean solution
|
||||
is sought.
|
||||
==== ====================================================================
|
||||
|
||||
__i2c_transfer), or a deadlock will follow.
|
||||
|
||||
Parent-locked Example
|
||||
---------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
@ -212,10 +162,30 @@ When there is an access to D1, this happens:
|
||||
9. M1 unlocks its parent adapter.
|
||||
10. M1 unlocks muxes on its parent.
|
||||
|
||||
|
||||
This means that accesses to both D2 and D3 are locked out for the full
|
||||
duration of the entire operation.
|
||||
|
||||
Parent-locked Caveats
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When using a parent-locked mux, be aware of the following restrictions:
|
||||
|
||||
[PL1]
|
||||
If you build a topology with a parent-locked mux being the child
|
||||
of another mux, this might break a possible assumption from the
|
||||
child mux that the root adapter is unused between its select op
|
||||
and the actual transfer (e.g. if the child mux is auto-closing
|
||||
and the parent mux issues I2C transfers as part of its select).
|
||||
This is especially the case if the parent mux is mux-locked, but
|
||||
it may also happen if the parent mux is parent-locked.
|
||||
|
||||
[PL2]
|
||||
If select/deselect calls out to other subsystems such as gpio,
|
||||
pinctrl, regmap or iio, it is essential that any I2C transfers
|
||||
caused by these subsystems are unlocked. This can be convoluted to
|
||||
accomplish, maybe even impossible if an acceptably clean solution
|
||||
is sought.
|
||||
|
||||
|
||||
Complex Examples
|
||||
================
|
||||
@ -261,8 +231,10 @@ This is a good topology::
|
||||
When device D1 is accessed, accesses to D2 are locked out for the
|
||||
full duration of the operation (muxes on the top child adapter of M1
|
||||
are locked). But accesses to D3 and D4 are possibly interleaved at
|
||||
any point. Accesses to D3 locks out D1 and D2, but accesses to D4
|
||||
are still possibly interleaved.
|
||||
any point.
|
||||
|
||||
Accesses to D3 locks out D1 and D2, but accesses to D4 are still possibly
|
||||
interleaved.
|
||||
|
||||
|
||||
Mux-locked mux as parent of parent-locked mux
|
||||
@ -394,3 +366,47 @@ This is a good topology::
|
||||
When D1 or D2 are accessed, accesses to D3 and D4 are locked out while
|
||||
accesses to D5 may interleave. When D3 or D4 are accessed, accesses to
|
||||
all other devices are locked out.
|
||||
|
||||
|
||||
Mux type of existing device drivers
|
||||
===================================
|
||||
|
||||
Whether a device is mux-locked or parent-locked depends on its
|
||||
implementation. The following list was correct at the time of writing:
|
||||
|
||||
In drivers/i2c/muxes/:
|
||||
|
||||
====================== =============================================
|
||||
i2c-arb-gpio-challenge Parent-locked
|
||||
i2c-mux-gpio Normally parent-locked, mux-locked iff
|
||||
all involved gpio pins are controlled by the
|
||||
same I2C root adapter that they mux.
|
||||
i2c-mux-gpmux Normally parent-locked, mux-locked iff
|
||||
specified in device-tree.
|
||||
i2c-mux-ltc4306 Mux-locked
|
||||
i2c-mux-mlxcpld Parent-locked
|
||||
i2c-mux-pca9541 Parent-locked
|
||||
i2c-mux-pca954x Parent-locked
|
||||
i2c-mux-pinctrl Normally parent-locked, mux-locked iff
|
||||
all involved pinctrl devices are controlled
|
||||
by the same I2C root adapter that they mux.
|
||||
i2c-mux-reg Parent-locked
|
||||
====================== =============================================
|
||||
|
||||
In drivers/iio/:
|
||||
|
||||
====================== =============================================
|
||||
gyro/mpu3050 Mux-locked
|
||||
imu/inv_mpu6050/ Mux-locked
|
||||
====================== =============================================
|
||||
|
||||
In drivers/media/:
|
||||
|
||||
======================= =============================================
|
||||
dvb-frontends/lgdt3306a Mux-locked
|
||||
dvb-frontends/m88ds3103 Parent-locked
|
||||
dvb-frontends/rtl2830 Parent-locked
|
||||
dvb-frontends/rtl2832 Mux-locked
|
||||
dvb-frontends/si2168 Mux-locked
|
||||
usb/cx231xx/ Parent-locked
|
||||
======================= =============================================
|
||||
|
||||
@ -32,9 +32,9 @@ User manual
|
||||
===========
|
||||
|
||||
I2C slave backends behave like standard I2C clients. So, you can instantiate
|
||||
them as described in the document 'instantiating-devices'. The only difference
|
||||
is that i2c slave backends have their own address space. So, you have to add
|
||||
0x1000 to the address you would originally request. An example for
|
||||
them as described in the document instantiating-devices.rst. The only
|
||||
difference is that i2c slave backends have their own address space. So, you
|
||||
have to add 0x1000 to the address you would originally request. An example for
|
||||
instantiating the slave-eeprom driver from userspace at the 7 bit address 0x64
|
||||
on bus 1::
|
||||
|
||||
|
||||
@ -364,7 +364,7 @@ stop condition is issued between transaction. The i2c_msg structure
|
||||
contains for each message the client address, the number of bytes of the
|
||||
message and the message data itself.
|
||||
|
||||
You can read the file ``i2c-protocol`` for more information about the
|
||||
You can read the file i2c-protocol.rst for more information about the
|
||||
actual I2C protocol.
|
||||
|
||||
|
||||
@ -414,7 +414,7 @@ transactions return 0 on success; the 'read' transactions return the read
|
||||
value, except for block transactions, which return the number of values
|
||||
read. The block buffers need not be longer than 32 bytes.
|
||||
|
||||
You can read the file ``smbus-protocol`` for more information about the
|
||||
You can read the file smbus-protocol.rst for more information about the
|
||||
actual SMBus protocol.
|
||||
|
||||
|
||||
|
||||
@ -517,6 +517,7 @@ All I-Force devices are supported by the iforce module. This includes:
|
||||
* AVB Mag Turbo Force
|
||||
* AVB Top Shot Pegasus
|
||||
* AVB Top Shot Force Feedback Racing Wheel
|
||||
* Boeder Force Feedback Wheel
|
||||
* Logitech WingMan Force
|
||||
* Logitech WingMan Force Wheel
|
||||
* Guillemot Race Leader Force Feedback
|
||||
|
||||
@ -525,8 +525,8 @@ followed by a test macro::
|
||||
If you need to expose a compiler capability to makefiles and/or C source files,
|
||||
`CC_HAS_` is the recommended prefix for the config option::
|
||||
|
||||
config CC_HAS_ASM_GOTO
|
||||
def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC))
|
||||
config CC_HAS_FOO
|
||||
def_bool $(success,$(srctree)/scripts/cc-check-foo.sh $(CC))
|
||||
|
||||
Build as module only
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -67,7 +67,7 @@ The ``netdevsim`` driver supports rate objects management, which includes:
|
||||
- setting tx_share and tx_max rate values for any rate object type;
|
||||
- setting parent node for any rate object type.
|
||||
|
||||
Rate nodes and it's parameters are exposed in ``netdevsim`` debugfs in RO mode.
|
||||
Rate nodes and their parameters are exposed in ``netdevsim`` debugfs in RO mode.
|
||||
For example created rate node with name ``some_group``:
|
||||
|
||||
.. code:: shell
|
||||
|
||||
@ -8,7 +8,7 @@ Transmit path guidelines:
|
||||
|
||||
1) The ndo_start_xmit method must not return NETDEV_TX_BUSY under
|
||||
any normal circumstances. It is considered a hard error unless
|
||||
there is no way your device can tell ahead of time when it's
|
||||
there is no way your device can tell ahead of time when its
|
||||
transmit function will become busy.
|
||||
|
||||
Instead it must maintain the queue properly. For example,
|
||||
|
||||
@ -1035,7 +1035,10 @@ tcp_limit_output_bytes - INTEGER
|
||||
tcp_challenge_ack_limit - INTEGER
|
||||
Limits number of Challenge ACK sent per second, as recommended
|
||||
in RFC 5961 (Improving TCP's Robustness to Blind In-Window Attacks)
|
||||
Default: 1000
|
||||
Note that this per netns rate limit can allow some side channel
|
||||
attacks and probably should not be enabled.
|
||||
TCP stack implements per TCP socket limits anyway.
|
||||
Default: INT_MAX (unlimited)
|
||||
|
||||
UDP variables
|
||||
=============
|
||||
|
||||
@ -11,7 +11,7 @@ Initial Release:
|
||||
================
|
||||
This is conceptually very similar to the macvlan driver with one major
|
||||
exception of using L3 for mux-ing /demux-ing among slaves. This property makes
|
||||
the master device share the L2 with it's slave devices. I have developed this
|
||||
the master device share the L2 with its slave devices. I have developed this
|
||||
driver in conjunction with network namespaces and not sure if there is use case
|
||||
outside of it.
|
||||
|
||||
|
||||
@ -530,7 +530,7 @@ its tunnel close actions. For L2TPIP sockets, the socket's close
|
||||
handler initiates the same tunnel close actions. All sessions are
|
||||
first closed. Each session drops its tunnel ref. When the tunnel ref
|
||||
reaches zero, the tunnel puts its socket ref. When the socket is
|
||||
eventually destroyed, it's sk_destruct finally frees the L2TP tunnel
|
||||
eventually destroyed, its sk_destruct finally frees the L2TP tunnel
|
||||
context.
|
||||
|
||||
Sessions
|
||||
|
||||
@ -47,7 +47,6 @@ allow_join_initial_addr_port - BOOLEAN
|
||||
Default: 1
|
||||
|
||||
pm_type - INTEGER
|
||||
|
||||
Set the default path manager type to use for each new MPTCP
|
||||
socket. In-kernel path management will control subflow
|
||||
connections and address advertisements according to
|
||||
|
||||
@ -70,15 +70,6 @@ nf_conntrack_generic_timeout - INTEGER (seconds)
|
||||
Default for generic timeout. This refers to layer 4 unknown/unsupported
|
||||
protocols.
|
||||
|
||||
nf_conntrack_helper - BOOLEAN
|
||||
- 0 - disabled (default)
|
||||
- not 0 - enabled
|
||||
|
||||
Enable automatic conntrack helper assignment.
|
||||
If disabled it is required to set up iptables rules to assign
|
||||
helpers to connections. See the CT target description in the
|
||||
iptables-extensions(8) man page for further information.
|
||||
|
||||
nf_conntrack_icmp_timeout - INTEGER (seconds)
|
||||
default 30
|
||||
|
||||
|
||||
@ -1055,17 +1055,6 @@ The kernel interface functions are as follows:
|
||||
first function to change. Note that this must be called in TASK_RUNNING
|
||||
state.
|
||||
|
||||
(#) Get reply timestamp::
|
||||
|
||||
bool rxrpc_kernel_get_reply_time(struct socket *sock,
|
||||
struct rxrpc_call *call,
|
||||
ktime_t *_ts)
|
||||
|
||||
This allows the timestamp on the first DATA packet of the reply of a
|
||||
client call to be queried, provided that it is still in the Rx ring. If
|
||||
successful, the timestamp will be stored into ``*_ts`` and true will be
|
||||
returned; false will be returned otherwise.
|
||||
|
||||
(#) Get remote client epoch::
|
||||
|
||||
u32 rxrpc_kernel_get_epoch(struct socket *sock,
|
||||
|
||||
@ -159,7 +159,7 @@ tools such as iproute2.
|
||||
|
||||
The switchdev driver can know a particular port's position in the topology by
|
||||
monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
|
||||
bond will see it's upper master change. If that bond is moved into a bridge,
|
||||
bond will see its upper master change. If that bond is moved into a bridge,
|
||||
the bond's upper master will change. And so on. The driver will track such
|
||||
movements to know what position a port is in in the overall topology by
|
||||
registering for netdevice events and acting on NETDEV_CHANGEUPPER.
|
||||
|
||||
@ -70,8 +70,16 @@
|
||||
|
||||
% Translations have Asian (CJK) characters which are only displayed if
|
||||
% xeCJK is used
|
||||
\usepackage{ifthen}
|
||||
\newboolean{enablecjk}
|
||||
\setboolean{enablecjk}{false}
|
||||
\IfFontExistsTF{Noto Sans CJK SC}{
|
||||
% Load xeCJK when CJK font is available
|
||||
\IfFileExists{xeCJK.sty}{
|
||||
\setboolean{enablecjk}{true}
|
||||
}{}
|
||||
}{}
|
||||
\ifthenelse{\boolean{enablecjk}}{
|
||||
% Load xeCJK when both the Noto Sans CJK font and xeCJK.sty are available.
|
||||
\usepackage{xeCJK}
|
||||
% Noto CJK fonts don't provide slant shape. [AutoFakeSlant] permits
|
||||
% its emulation.
|
||||
@ -196,7 +204,7 @@
|
||||
% Inactivate CJK after tableofcontents
|
||||
\apptocmd{\sphinxtableofcontents}{\kerneldocCJKoff}{}{}
|
||||
\xeCJKsetup{CJKspace = true}% For inter-phrase space of Korean TOC
|
||||
}{ % No CJK font found
|
||||
}{ % Don't enable CJK
|
||||
% Custom macros to on/off CJK and switch CJK fonts (Dummy)
|
||||
\newcommand{\kerneldocCJKon}{}
|
||||
\newcommand{\kerneldocCJKoff}{}
|
||||
@ -204,14 +212,16 @@
|
||||
%% and ignore the argument (#1) in their definitions, whole contents of
|
||||
%% CJK chapters can be ignored.
|
||||
\newcommand{\kerneldocBeginSC}[1]{%
|
||||
%% Put a note on missing CJK fonts in place of zh_CN translation.
|
||||
\begin{sphinxadmonition}{note}{Note on missing fonts:}
|
||||
%% Put a note on missing CJK fonts or the xecjk package in place of
|
||||
%% zh_CN translation.
|
||||
\begin{sphinxadmonition}{note}{Note on missing fonts and a package:}
|
||||
Translations of Simplified Chinese (zh\_CN), Traditional Chinese
|
||||
(zh\_TW), Korean (ko\_KR), and Japanese (ja\_JP) were skipped
|
||||
due to the lack of suitable font families.
|
||||
due to the lack of suitable font families and/or the texlive-xecjk
|
||||
package.
|
||||
|
||||
If you want them, please install ``Noto Sans CJK'' font families
|
||||
by following instructions from
|
||||
along with the texlive-xecjk package by following instructions from
|
||||
\sphinxcode{./scripts/sphinx-pre-install}.
|
||||
Having optional ``Noto Serif CJK'' font families will improve
|
||||
the looks of those translations.
|
||||
|
||||
@ -33,7 +33,7 @@ EXAMPLE
|
||||
=======
|
||||
In the example below, **rtla timerlat hist** is set to run for *10* minutes,
|
||||
in the cpus *0-4*, *skipping zero* only lines. Moreover, **rtla timerlat
|
||||
hist** will change the priority of the *timelat* threads to run under
|
||||
hist** will change the priority of the *timerlat* threads to run under
|
||||
*SCHED_DEADLINE* priority, with a *10us* runtime every *1ms* period. The
|
||||
*1ms* period is also passed to the *timerlat* tracer::
|
||||
|
||||
|
||||
@ -35,8 +35,7 @@ Linux カーネルに変更を加えたいと思っている個人又は会社
|
||||
てもらえやすくする提案を集めたものです。
|
||||
|
||||
コードを投稿する前に、Documentation/process/submit-checklist.rst の項目リストに目
|
||||
を通してチェックしてください。もしあなたがドライバーを投稿しようとし
|
||||
ているなら、Documentation/process/submitting-drivers.rst にも目を通してください。
|
||||
を通してチェックしてください。
|
||||
|
||||
--------------------------------------------
|
||||
セクション1 パッチの作り方と送り方
|
||||
|
||||
86
MAINTAINERS
86
MAINTAINERS
@ -671,7 +671,8 @@ F: fs/afs/
|
||||
F: include/trace/events/afs.h
|
||||
|
||||
AGPGART DRIVER
|
||||
M: David Airlie <airlied@linux.ie>
|
||||
M: David Airlie <airlied@redhat.com>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
S: Maintained
|
||||
T: git git://anongit.freedesktop.org/drm/drm
|
||||
F: drivers/char/agp/
|
||||
@ -1010,7 +1011,6 @@ F: drivers/spi/spi-amd.c
|
||||
|
||||
AMD MP2 I2C DRIVER
|
||||
M: Elie Morisse <syniurge@gmail.com>
|
||||
M: Nehal Shah <nehal-bakulchandra.shah@amd.com>
|
||||
M: Shyam Sundar S K <shyam-sundar.s-k@amd.com>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
S: Maintained
|
||||
@ -1803,7 +1803,7 @@ N: sun[x456789]i
|
||||
N: sun50i
|
||||
|
||||
ARM/Amlogic Meson SoC CLOCK FRAMEWORK
|
||||
M: Neil Armstrong <narmstrong@baylibre.com>
|
||||
M: Neil Armstrong <neil.armstrong@linaro.org>
|
||||
M: Jerome Brunet <jbrunet@baylibre.com>
|
||||
L: linux-amlogic@lists.infradead.org
|
||||
S: Maintained
|
||||
@ -1828,7 +1828,7 @@ F: Documentation/devicetree/bindings/sound/amlogic*
|
||||
F: sound/soc/meson/
|
||||
|
||||
ARM/Amlogic Meson SoC support
|
||||
M: Neil Armstrong <narmstrong@baylibre.com>
|
||||
M: Neil Armstrong <neil.armstrong@linaro.org>
|
||||
M: Kevin Hilman <khilman@baylibre.com>
|
||||
R: Jerome Brunet <jbrunet@baylibre.com>
|
||||
R: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
|
||||
@ -2178,7 +2178,7 @@ M: Jean-Marie Verdun <verdun@hpe.com>
|
||||
M: Nick Hawkins <nick.hawkins@hpe.com>
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/arm/hpe,gxp.yaml
|
||||
F: Documentation/devicetree/bindings/spi/hpe,gxp-spi.yaml
|
||||
F: Documentation/devicetree/bindings/spi/hpe,gxp-spifi.yaml
|
||||
F: Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
|
||||
F: arch/arm/boot/dts/hpe-bmc*
|
||||
F: arch/arm/boot/dts/hpe-gxp*
|
||||
@ -2531,7 +2531,7 @@ W: http://www.digriz.org.uk/ts78xx/kernel
|
||||
F: arch/arm/mach-orion5x/ts78xx-*
|
||||
|
||||
ARM/OXNAS platform support
|
||||
M: Neil Armstrong <narmstrong@baylibre.com>
|
||||
M: Neil Armstrong <neil.armstrong@linaro.org>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: linux-oxnas@groups.io (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
@ -2579,7 +2579,7 @@ W: http://www.armlinux.org.uk/
|
||||
|
||||
ARM/QUALCOMM SUPPORT
|
||||
M: Andy Gross <agross@kernel.org>
|
||||
M: Bjorn Andersson <bjorn.andersson@linaro.org>
|
||||
M: Bjorn Andersson <andersson@kernel.org>
|
||||
R: Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
S: Maintained
|
||||
@ -2670,7 +2670,6 @@ M: Russell King <linux@armlinux.org.uk>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
W: http://www.armlinux.org.uk/
|
||||
F: arch/arm/include/asm/hardware/entry-macro-iomd.S
|
||||
F: arch/arm/include/asm/hardware/ioc.h
|
||||
F: arch/arm/include/asm/hardware/iomd.h
|
||||
F: arch/arm/include/asm/hardware/memc.h
|
||||
@ -3612,6 +3611,7 @@ F: include/linux/find.h
|
||||
F: include/linux/nodemask.h
|
||||
F: lib/bitmap.c
|
||||
F: lib/cpumask.c
|
||||
F: lib/cpumask_kunit.c
|
||||
F: lib/find_bit.c
|
||||
F: lib/find_bit_benchmark.c
|
||||
F: lib/test_bitmap.c
|
||||
@ -3679,6 +3679,7 @@ F: Documentation/networking/bonding.rst
|
||||
F: drivers/net/bonding/
|
||||
F: include/net/bond*
|
||||
F: include/uapi/linux/if_bonding.h
|
||||
F: tools/testing/selftests/drivers/net/bonding/
|
||||
|
||||
BOSCH SENSORTEC BMA400 ACCELEROMETER IIO DRIVER
|
||||
M: Dan Robertson <dan@dlrobertson.com>
|
||||
@ -5145,6 +5146,7 @@ T: git git://git.samba.org/sfrench/cifs-2.6.git
|
||||
F: Documentation/admin-guide/cifs/
|
||||
F: fs/cifs/
|
||||
F: fs/smbfs_common/
|
||||
F: include/uapi/linux/cifs
|
||||
|
||||
COMPACTPCI HOTPLUG CORE
|
||||
M: Scott Murray <scott@spiteful.org>
|
||||
@ -5242,6 +5244,7 @@ F: block/blk-throttle.c
|
||||
F: include/linux/blk-cgroup.h
|
||||
|
||||
CONTROL GROUP - CPUSET
|
||||
M: Waiman Long <longman@redhat.com>
|
||||
M: Zefan Li <lizefan.x@bytedance.com>
|
||||
L: cgroups@vger.kernel.org
|
||||
S: Maintained
|
||||
@ -6750,7 +6753,7 @@ F: Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml
|
||||
F: drivers/gpu/drm/panel/panel-widechips-ws2401.c
|
||||
|
||||
DRM DRIVERS
|
||||
M: David Airlie <airlied@linux.ie>
|
||||
M: David Airlie <airlied@gmail.com>
|
||||
M: Daniel Vetter <daniel@ffwll.ch>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
S: Maintained
|
||||
@ -6789,7 +6792,7 @@ F: Documentation/devicetree/bindings/display/allwinner*
|
||||
F: drivers/gpu/drm/sun4i/
|
||||
|
||||
DRM DRIVERS FOR AMLOGIC SOCS
|
||||
M: Neil Armstrong <narmstrong@baylibre.com>
|
||||
M: Neil Armstrong <neil.armstrong@linaro.org>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
L: linux-amlogic@lists.infradead.org
|
||||
S: Supported
|
||||
@ -6811,7 +6814,7 @@ F: drivers/gpu/drm/atmel-hlcdc/
|
||||
|
||||
DRM DRIVERS FOR BRIDGE CHIPS
|
||||
M: Andrzej Hajda <andrzej.hajda@intel.com>
|
||||
M: Neil Armstrong <narmstrong@baylibre.com>
|
||||
M: Neil Armstrong <neil.armstrong@linaro.org>
|
||||
M: Robert Foss <robert.foss@linaro.org>
|
||||
R: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
|
||||
R: Jonas Karlman <jonas@kwiboo.se>
|
||||
@ -8649,8 +8652,8 @@ F: drivers/input/touchscreen/goodix*
|
||||
|
||||
GOOGLE ETHERNET DRIVERS
|
||||
M: Jeroen de Borst <jeroendb@google.com>
|
||||
R: Catherine Sullivan <csully@google.com>
|
||||
R: David Awogbemila <awogbemila@google.com>
|
||||
M: Catherine Sullivan <csully@google.com>
|
||||
R: Shailend Chand <shailend@google.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/networking/device_drivers/ethernet/google/gve.rst
|
||||
@ -8940,7 +8943,7 @@ F: include/linux/hw_random.h
|
||||
|
||||
HARDWARE SPINLOCK CORE
|
||||
M: Ohad Ben-Cohen <ohad@wizery.com>
|
||||
M: Bjorn Andersson <bjorn.andersson@linaro.org>
|
||||
M: Bjorn Andersson <andersson@kernel.org>
|
||||
R: Baolin Wang <baolin.wang7@gmail.com>
|
||||
L: linux-remoteproc@vger.kernel.org
|
||||
S: Maintained
|
||||
@ -9119,7 +9122,7 @@ S: Maintained
|
||||
F: drivers/dma/hisi_dma.c
|
||||
|
||||
HISILICON GPIO DRIVER
|
||||
M: Luo Jiaxing <luojiaxing@huawei.com>
|
||||
M: Jay Fang <f.fangjian@huawei.com>
|
||||
L: linux-gpio@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/gpio/gpio-hisi.c
|
||||
@ -9205,8 +9208,8 @@ F: Documentation/ABI/testing/debugfs-hisi-zip
|
||||
F: drivers/crypto/hisilicon/zip/
|
||||
|
||||
HISILICON ROCE DRIVER
|
||||
M: Haoyue Xu <xuhaoyue1@hisilicon.com>
|
||||
M: Wenpeng Liang <liangwenpeng@huawei.com>
|
||||
M: Weihang Li <liweihang@huawei.com>
|
||||
L: linux-rdma@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt
|
||||
@ -9780,7 +9783,7 @@ M: Christian Brauner <brauner@kernel.org>
|
||||
M: Seth Forshee <sforshee@kernel.org>
|
||||
L: linux-fsdevel@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git
|
||||
T: git://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping.git
|
||||
F: Documentation/filesystems/idmappings.rst
|
||||
F: tools/testing/selftests/mount_setattr/
|
||||
F: include/linux/mnt_idmapping.h
|
||||
@ -10029,6 +10032,7 @@ F: Documentation/devicetree/bindings/input/
|
||||
F: Documentation/devicetree/bindings/serio/
|
||||
F: Documentation/input/
|
||||
F: drivers/input/
|
||||
F: include/dt-bindings/input/
|
||||
F: include/linux/input.h
|
||||
F: include/linux/input/
|
||||
F: include/uapi/linux/input-event-codes.h
|
||||
@ -10657,6 +10661,7 @@ T: git git://git.kernel.dk/linux-block
|
||||
T: git git://git.kernel.dk/liburing
|
||||
F: io_uring/
|
||||
F: include/linux/io_uring.h
|
||||
F: include/linux/io_uring_types.h
|
||||
F: include/uapi/linux/io_uring.h
|
||||
F: tools/io_uring/
|
||||
|
||||
@ -10823,7 +10828,7 @@ F: drivers/media/tuners/it913x*
|
||||
|
||||
ITE IT66121 HDMI BRIDGE DRIVER
|
||||
M: Phong LE <ple@baylibre.com>
|
||||
M: Neil Armstrong <narmstrong@baylibre.com>
|
||||
M: Neil Armstrong <neil.armstrong@linaro.org>
|
||||
S: Maintained
|
||||
T: git git://anongit.freedesktop.org/drm/drm-misc
|
||||
F: Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
|
||||
@ -11342,7 +11347,7 @@ F: kernel/debug/
|
||||
F: kernel/module/kdb.c
|
||||
|
||||
KHADAS MCU MFD DRIVER
|
||||
M: Neil Armstrong <narmstrong@baylibre.com>
|
||||
M: Neil Armstrong <neil.armstrong@linaro.org>
|
||||
L: linux-amlogic@lists.infradead.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
|
||||
@ -13213,7 +13218,7 @@ S: Maintained
|
||||
F: drivers/watchdog/menz69_wdt.c
|
||||
|
||||
MESON AO CEC DRIVER FOR AMLOGIC SOCS
|
||||
M: Neil Armstrong <narmstrong@baylibre.com>
|
||||
M: Neil Armstrong <neil.armstrong@linaro.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
L: linux-amlogic@lists.infradead.org
|
||||
S: Supported
|
||||
@ -13224,7 +13229,7 @@ F: drivers/media/cec/platform/meson/ao-cec-g12a.c
|
||||
F: drivers/media/cec/platform/meson/ao-cec.c
|
||||
|
||||
MESON GE2D DRIVER FOR AMLOGIC SOCS
|
||||
M: Neil Armstrong <narmstrong@baylibre.com>
|
||||
M: Neil Armstrong <neil.armstrong@linaro.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
L: linux-amlogic@lists.infradead.org
|
||||
S: Supported
|
||||
@ -13240,7 +13245,7 @@ F: Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
|
||||
F: drivers/mtd/nand/raw/meson_*
|
||||
|
||||
MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS
|
||||
M: Neil Armstrong <narmstrong@baylibre.com>
|
||||
M: Neil Armstrong <neil.armstrong@linaro.org>
|
||||
L: linux-media@vger.kernel.org
|
||||
L: linux-amlogic@lists.infradead.org
|
||||
S: Supported
|
||||
@ -16120,7 +16125,7 @@ F: drivers/gpio/gpio-sama5d2-piobu.c
|
||||
F: drivers/pinctrl/pinctrl-at91*
|
||||
|
||||
PIN CONTROLLER - QUALCOMM
|
||||
M: Bjorn Andersson <bjorn.andersson@linaro.org>
|
||||
M: Bjorn Andersson <andersson@kernel.org>
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pinctrl/qcom,*.txt
|
||||
@ -16813,7 +16818,7 @@ F: Documentation/devicetree/bindings/media/*camss*
|
||||
F: drivers/media/platform/qcom/camss/
|
||||
|
||||
QUALCOMM CLOCK DRIVERS
|
||||
M: Bjorn Andersson <bjorn.andersson@linaro.org>
|
||||
M: Bjorn Andersson <andersson@kernel.org>
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
S: Supported
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git
|
||||
@ -16852,6 +16857,7 @@ F: drivers/net/ethernet/qualcomm/emac/
|
||||
|
||||
QUALCOMM ETHQOS ETHERNET DRIVER
|
||||
M: Vinod Koul <vkoul@kernel.org>
|
||||
R: Bhupesh Sharma <bhupesh.sharma@linaro.org>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/net/qcom,ethqos.txt
|
||||
@ -17302,7 +17308,7 @@ S: Supported
|
||||
F: fs/reiserfs/
|
||||
|
||||
REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
|
||||
M: Bjorn Andersson <bjorn.andersson@linaro.org>
|
||||
M: Bjorn Andersson <andersson@kernel.org>
|
||||
M: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
L: linux-remoteproc@vger.kernel.org
|
||||
S: Maintained
|
||||
@ -17315,7 +17321,7 @@ F: include/linux/remoteproc.h
|
||||
F: include/linux/remoteproc/
|
||||
|
||||
REMOTE PROCESSOR MESSAGING (RPMSG) SUBSYSTEM
|
||||
M: Bjorn Andersson <bjorn.andersson@linaro.org>
|
||||
M: Bjorn Andersson <andersson@kernel.org>
|
||||
M: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
L: linux-remoteproc@vger.kernel.org
|
||||
S: Maintained
|
||||
@ -17527,9 +17533,19 @@ M: Conor Dooley <conor.dooley@microchip.com>
|
||||
M: Daire McNamara <daire.mcnamara@microchip.com>
|
||||
L: linux-riscv@lists.infradead.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/clock/microchip,mpfs.yaml
|
||||
F: Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml
|
||||
F: Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml
|
||||
F: Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml
|
||||
F: Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml
|
||||
F: Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml
|
||||
F: Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml
|
||||
F: Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml
|
||||
F: Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml
|
||||
F: arch/riscv/boot/dts/microchip/
|
||||
F: drivers/char/hw_random/mpfs-rng.c
|
||||
F: drivers/clk/microchip/clk-mpfs.c
|
||||
F: drivers/i2c/busses/i2c-microchip-core.c
|
||||
F: drivers/mailbox/mailbox-mpfs.c
|
||||
F: drivers/pci/controller/pcie-microchip-host.c
|
||||
F: drivers/rtc/rtc-mpfs.c
|
||||
@ -17730,6 +17746,17 @@ L: linux-rdma@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/infiniband/ulp/rtrs/
|
||||
|
||||
RUNTIME VERIFICATION (RV)
|
||||
M: Daniel Bristot de Oliveira <bristot@kernel.org>
|
||||
M: Steven Rostedt <rostedt@goodmis.org>
|
||||
L: linux-trace-devel@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/trace/rv/
|
||||
F: include/linux/rv.h
|
||||
F: include/rv/
|
||||
F: kernel/trace/rv/
|
||||
F: tools/verification/
|
||||
|
||||
RXRPC SOCKETS (AF_RXRPC)
|
||||
M: David Howells <dhowells@redhat.com>
|
||||
M: Marc Dionne <marc.dionne@auristor.com>
|
||||
@ -19933,6 +19960,7 @@ S: Supported
|
||||
F: drivers/net/team/
|
||||
F: include/linux/if_team.h
|
||||
F: include/uapi/linux/if_team.h
|
||||
F: tools/testing/selftests/drivers/net/team/
|
||||
|
||||
TECHNOLOGIC SYSTEMS TS-5500 PLATFORM SUPPORT
|
||||
M: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
|
||||
@ -20596,6 +20624,7 @@ F: include/*/ftrace.h
|
||||
F: include/linux/trace*.h
|
||||
F: include/trace/
|
||||
F: kernel/trace/
|
||||
F: scripts/tracing/
|
||||
F: tools/testing/selftests/ftrace/
|
||||
|
||||
TRACING MMIO ACCESSES (MMIOTRACE)
|
||||
@ -20760,6 +20789,7 @@ UBLK USERSPACE BLOCK DRIVER
|
||||
M: Ming Lei <ming.lei@redhat.com>
|
||||
L: linux-block@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/block/ublk.rst
|
||||
F: drivers/block/ublk_drv.c
|
||||
F: include/uapi/linux/ublk_cmd.h
|
||||
|
||||
@ -21537,7 +21567,7 @@ F: drivers/gpio/gpio-virtio.c
|
||||
F: include/uapi/linux/virtio_gpio.h
|
||||
|
||||
VIRTIO GPU DRIVER
|
||||
M: David Airlie <airlied@linux.ie>
|
||||
M: David Airlie <airlied@redhat.com>
|
||||
M: Gerd Hoffmann <kraxel@redhat.com>
|
||||
R: Gurchetan Singh <gurchetansingh@chromium.org>
|
||||
R: Chia-I Wu <olvaffe@gmail.com>
|
||||
@ -22301,7 +22331,7 @@ M: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
|
||||
R: Srinivas Neeli <srinivas.neeli@xilinx.com>
|
||||
R: Michal Simek <michal.simek@xilinx.com>
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
|
||||
F: Documentation/devicetree/bindings/gpio/xlnx,gpio-xilinx.yaml
|
||||
F: Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
|
||||
F: drivers/gpio/gpio-xilinx.c
|
||||
F: drivers/gpio/gpio-zynq.c
|
||||
|
||||
11
Makefile
11
Makefile
@ -2,7 +2,7 @@
|
||||
VERSION = 6
|
||||
PATCHLEVEL = 0
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc1
|
||||
EXTRAVERSION =
|
||||
NAME = Hurr durr I'ma ninja sloth
|
||||
|
||||
# *DOCUMENTATION*
|
||||
@ -1113,13 +1113,11 @@ vmlinux-alldirs := $(sort $(vmlinux-dirs) Documentation \
|
||||
$(patsubst %/,%,$(filter %/, $(core-) \
|
||||
$(drivers-) $(libs-))))
|
||||
|
||||
subdir-modorder := $(addsuffix modules.order,$(filter %/, \
|
||||
$(core-y) $(core-m) $(libs-y) $(libs-m) \
|
||||
$(drivers-y) $(drivers-m)))
|
||||
|
||||
build-dirs := $(vmlinux-dirs)
|
||||
clean-dirs := $(vmlinux-alldirs)
|
||||
|
||||
subdir-modorder := $(addsuffix /modules.order, $(build-dirs))
|
||||
|
||||
# Externally visible symbols (used by link-vmlinux.sh)
|
||||
KBUILD_VMLINUX_OBJS := $(head-y) $(patsubst %/,%/built-in.a, $(core-y))
|
||||
KBUILD_VMLINUX_OBJS += $(addsuffix built-in.a, $(filter %/, $(libs-y)))
|
||||
@ -1289,8 +1287,7 @@ hdr-inst := -f $(srctree)/scripts/Makefile.headersinst obj
|
||||
|
||||
PHONY += headers
|
||||
headers: $(version_h) scripts_unifdef uapi-asm-generic archheaders archscripts
|
||||
$(if $(wildcard $(srctree)/arch/$(SRCARCH)/include/uapi/asm/Kbuild),, \
|
||||
$(error Headers not exportable for the $(SRCARCH) architecture))
|
||||
$(if $(filter um, $(SRCARCH)), $(error Headers not exportable for UML))
|
||||
$(Q)$(MAKE) $(hdr-inst)=include/uapi
|
||||
$(Q)$(MAKE) $(hdr-inst)=arch/$(SRCARCH)/include/uapi
|
||||
|
||||
|
||||
@ -53,7 +53,6 @@ config KPROBES
|
||||
config JUMP_LABEL
|
||||
bool "Optimize very unlikely/likely branches"
|
||||
depends on HAVE_ARCH_JUMP_LABEL
|
||||
depends on CC_HAS_ASM_GOTO
|
||||
select OBJTOOL if HAVE_JUMP_LABEL_HACK
|
||||
help
|
||||
This option enables a transparent branch optimization that
|
||||
@ -924,6 +923,9 @@ config HAVE_SOFTIRQ_ON_OWN_STACK
|
||||
Architecture provides a function to run __do_softirq() on a
|
||||
separate stack.
|
||||
|
||||
config SOFTIRQ_ON_OWN_STACK
|
||||
def_bool HAVE_SOFTIRQ_ON_OWN_STACK && !PREEMPT_RT
|
||||
|
||||
config ALTERNATE_USER_ADDRESS_SPACE
|
||||
bool
|
||||
help
|
||||
@ -1361,7 +1363,7 @@ config HAVE_PREEMPT_DYNAMIC_CALL
|
||||
|
||||
config HAVE_PREEMPT_DYNAMIC_KEY
|
||||
bool
|
||||
depends on HAVE_ARCH_JUMP_LABEL && CC_HAS_ASM_GOTO
|
||||
depends on HAVE_ARCH_JUMP_LABEL
|
||||
select HAVE_PREEMPT_DYNAMIC
|
||||
help
|
||||
An architecture should select this if it can handle the preemption
|
||||
|
||||
@ -283,11 +283,8 @@ arch___test_and_change_bit(unsigned long nr, volatile unsigned long *addr)
|
||||
return (old & mask) != 0;
|
||||
}
|
||||
|
||||
static __always_inline bool
|
||||
arch_test_bit(unsigned long nr, const volatile unsigned long *addr)
|
||||
{
|
||||
return (1UL & (((const int *) addr)[nr >> 5] >> (nr & 31))) != 0UL;
|
||||
}
|
||||
#define arch_test_bit generic_test_bit
|
||||
#define arch_test_bit_acquire generic_test_bit_acquire
|
||||
|
||||
/*
|
||||
* ffz = Find First Zero in word. Undefined if no zero exists,
|
||||
|
||||
@ -1502,8 +1502,7 @@
|
||||
mmc1: mmc@0 {
|
||||
compatible = "ti,am335-sdhci";
|
||||
ti,needs-special-reset;
|
||||
dmas = <&edma_xbar 24 0 0
|
||||
&edma_xbar 25 0 0>;
|
||||
dmas = <&edma 24 0>, <&edma 25 0>;
|
||||
dma-names = "tx", "rx";
|
||||
interrupts = <64>;
|
||||
reg = <0x0 0x1000>;
|
||||
|
||||
@ -25,6 +25,10 @@
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
&usb4_tm {
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
&atl_tm {
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
@ -399,7 +399,7 @@
|
||||
compatible = "arm,pl022", "arm,primecell";
|
||||
reg = <0x1000d000 0x1000>;
|
||||
clocks = <&sspclk>, <&pclk>;
|
||||
clock-names = "SSPCLK", "apb_pclk";
|
||||
clock-names = "sspclk", "apb_pclk";
|
||||
};
|
||||
|
||||
wdog: watchdog@10010000 {
|
||||
|
||||
@ -410,7 +410,7 @@
|
||||
interrupt-parent = <&intc_dc1176>;
|
||||
interrupts = <0 17 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&sspclk>, <&pclk>;
|
||||
clock-names = "SSPCLK", "apb_pclk";
|
||||
clock-names = "sspclk", "apb_pclk";
|
||||
};
|
||||
|
||||
pb1176_serial0: serial@1010c000 {
|
||||
|
||||
@ -555,7 +555,7 @@
|
||||
interrupt-parent = <&intc_pb11mp>;
|
||||
interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&sspclk>, <&pclk>;
|
||||
clock-names = "SSPCLK", "apb_pclk";
|
||||
clock-names = "sspclk", "apb_pclk";
|
||||
};
|
||||
|
||||
watchdog@1000f000 {
|
||||
|
||||
@ -390,7 +390,7 @@
|
||||
compatible = "arm,pl022", "arm,primecell";
|
||||
reg = <0x1000d000 0x1000>;
|
||||
clocks = <&sspclk>, <&pclk>;
|
||||
clock-names = "SSPCLK", "apb_pclk";
|
||||
clock-names = "sspclk", "apb_pclk";
|
||||
};
|
||||
|
||||
wdog0: watchdog@1000f000 {
|
||||
|
||||
@ -76,8 +76,8 @@
|
||||
regulators {
|
||||
vdd_3v3: VDD_IO {
|
||||
regulator-name = "VDD_IO";
|
||||
regulator-min-microvolt = <1200000>;
|
||||
regulator-max-microvolt = <3700000>;
|
||||
regulator-min-microvolt = <3300000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
regulator-initial-mode = <2>;
|
||||
regulator-allowed-modes = <2>, <4>;
|
||||
regulator-always-on;
|
||||
@ -95,8 +95,8 @@
|
||||
|
||||
vddio_ddr: VDD_DDR {
|
||||
regulator-name = "VDD_DDR";
|
||||
regulator-min-microvolt = <600000>;
|
||||
regulator-max-microvolt = <1850000>;
|
||||
regulator-min-microvolt = <1200000>;
|
||||
regulator-max-microvolt = <1200000>;
|
||||
regulator-initial-mode = <2>;
|
||||
regulator-allowed-modes = <2>, <4>;
|
||||
regulator-always-on;
|
||||
@ -118,8 +118,8 @@
|
||||
|
||||
vdd_core: VDD_CORE {
|
||||
regulator-name = "VDD_CORE";
|
||||
regulator-min-microvolt = <600000>;
|
||||
regulator-max-microvolt = <1850000>;
|
||||
regulator-min-microvolt = <1250000>;
|
||||
regulator-max-microvolt = <1250000>;
|
||||
regulator-initial-mode = <2>;
|
||||
regulator-allowed-modes = <2>, <4>;
|
||||
regulator-always-on;
|
||||
@ -160,8 +160,8 @@
|
||||
|
||||
LDO1 {
|
||||
regulator-name = "LDO1";
|
||||
regulator-min-microvolt = <1200000>;
|
||||
regulator-max-microvolt = <3700000>;
|
||||
regulator-min-microvolt = <3300000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
regulator-always-on;
|
||||
|
||||
regulator-state-standby {
|
||||
@ -175,9 +175,8 @@
|
||||
|
||||
LDO2 {
|
||||
regulator-name = "LDO2";
|
||||
regulator-min-microvolt = <1200000>;
|
||||
regulator-max-microvolt = <3700000>;
|
||||
regulator-always-on;
|
||||
regulator-min-microvolt = <1800000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
|
||||
regulator-state-standby {
|
||||
regulator-on-in-suspend;
|
||||
|
||||
@ -196,8 +196,8 @@
|
||||
regulators {
|
||||
vdd_io_reg: VDD_IO {
|
||||
regulator-name = "VDD_IO";
|
||||
regulator-min-microvolt = <1200000>;
|
||||
regulator-max-microvolt = <3700000>;
|
||||
regulator-min-microvolt = <3300000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
regulator-initial-mode = <2>;
|
||||
regulator-allowed-modes = <2>, <4>;
|
||||
regulator-always-on;
|
||||
@ -215,8 +215,8 @@
|
||||
|
||||
VDD_DDR {
|
||||
regulator-name = "VDD_DDR";
|
||||
regulator-min-microvolt = <600000>;
|
||||
regulator-max-microvolt = <1850000>;
|
||||
regulator-min-microvolt = <1350000>;
|
||||
regulator-max-microvolt = <1350000>;
|
||||
regulator-initial-mode = <2>;
|
||||
regulator-allowed-modes = <2>, <4>;
|
||||
regulator-always-on;
|
||||
@ -234,8 +234,8 @@
|
||||
|
||||
VDD_CORE {
|
||||
regulator-name = "VDD_CORE";
|
||||
regulator-min-microvolt = <600000>;
|
||||
regulator-max-microvolt = <1850000>;
|
||||
regulator-min-microvolt = <1250000>;
|
||||
regulator-max-microvolt = <1250000>;
|
||||
regulator-initial-mode = <2>;
|
||||
regulator-allowed-modes = <2>, <4>;
|
||||
regulator-always-on;
|
||||
@ -257,7 +257,6 @@
|
||||
regulator-max-microvolt = <1850000>;
|
||||
regulator-initial-mode = <2>;
|
||||
regulator-allowed-modes = <2>, <4>;
|
||||
regulator-always-on;
|
||||
|
||||
regulator-state-standby {
|
||||
regulator-on-in-suspend;
|
||||
@ -272,8 +271,8 @@
|
||||
|
||||
LDO1 {
|
||||
regulator-name = "LDO1";
|
||||
regulator-min-microvolt = <1200000>;
|
||||
regulator-max-microvolt = <3700000>;
|
||||
regulator-min-microvolt = <2500000>;
|
||||
regulator-max-microvolt = <2500000>;
|
||||
regulator-always-on;
|
||||
|
||||
regulator-state-standby {
|
||||
@ -287,8 +286,8 @@
|
||||
|
||||
LDO2 {
|
||||
regulator-name = "LDO2";
|
||||
regulator-min-microvolt = <1200000>;
|
||||
regulator-max-microvolt = <3700000>;
|
||||
regulator-min-microvolt = <3300000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
regulator-always-on;
|
||||
|
||||
regulator-state-standby {
|
||||
|
||||
@ -244,8 +244,8 @@
|
||||
regulators {
|
||||
vdd_3v3: VDD_IO {
|
||||
regulator-name = "VDD_IO";
|
||||
regulator-min-microvolt = <1200000>;
|
||||
regulator-max-microvolt = <3700000>;
|
||||
regulator-min-microvolt = <3300000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
regulator-initial-mode = <2>;
|
||||
regulator-allowed-modes = <2>, <4>;
|
||||
regulator-always-on;
|
||||
@ -264,8 +264,8 @@
|
||||
|
||||
vddioddr: VDD_DDR {
|
||||
regulator-name = "VDD_DDR";
|
||||
regulator-min-microvolt = <1300000>;
|
||||
regulator-max-microvolt = <1450000>;
|
||||
regulator-min-microvolt = <1350000>;
|
||||
regulator-max-microvolt = <1350000>;
|
||||
regulator-initial-mode = <2>;
|
||||
regulator-allowed-modes = <2>, <4>;
|
||||
regulator-always-on;
|
||||
@ -285,8 +285,8 @@
|
||||
|
||||
vddcore: VDD_CORE {
|
||||
regulator-name = "VDD_CORE";
|
||||
regulator-min-microvolt = <1100000>;
|
||||
regulator-max-microvolt = <1850000>;
|
||||
regulator-min-microvolt = <1150000>;
|
||||
regulator-max-microvolt = <1150000>;
|
||||
regulator-initial-mode = <2>;
|
||||
regulator-allowed-modes = <2>, <4>;
|
||||
regulator-always-on;
|
||||
@ -306,7 +306,7 @@
|
||||
vddcpu: VDD_OTHER {
|
||||
regulator-name = "VDD_OTHER";
|
||||
regulator-min-microvolt = <1050000>;
|
||||
regulator-max-microvolt = <1850000>;
|
||||
regulator-max-microvolt = <1250000>;
|
||||
regulator-initial-mode = <2>;
|
||||
regulator-allowed-modes = <2>, <4>;
|
||||
regulator-ramp-delay = <3125>;
|
||||
@ -326,8 +326,8 @@
|
||||
|
||||
vldo1: LDO1 {
|
||||
regulator-name = "LDO1";
|
||||
regulator-min-microvolt = <1200000>;
|
||||
regulator-max-microvolt = <3700000>;
|
||||
regulator-min-microvolt = <1800000>;
|
||||
regulator-max-microvolt = <1800000>;
|
||||
regulator-always-on;
|
||||
|
||||
regulator-state-standby {
|
||||
|
||||
@ -32,6 +32,7 @@
|
||||
next-level-cache = <&L2_0>;
|
||||
enable-method = "psci";
|
||||
};
|
||||
|
||||
CA7_2: cpu@2 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a7";
|
||||
@ -39,6 +40,7 @@
|
||||
next-level-cache = <&L2_0>;
|
||||
enable-method = "psci";
|
||||
};
|
||||
|
||||
L2_0: l2-cache0 {
|
||||
compatible = "cache";
|
||||
};
|
||||
@ -46,10 +48,10 @@
|
||||
|
||||
timer {
|
||||
compatible = "arm,armv7-timer";
|
||||
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
|
||||
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(3) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(3) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(3) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(3) | IRQ_TYPE_LEVEL_LOW)>;
|
||||
arm,cpu-registers-not-fw-configured;
|
||||
};
|
||||
|
||||
@ -80,23 +82,23 @@
|
||||
psci {
|
||||
compatible = "arm,psci-0.2";
|
||||
method = "smc";
|
||||
cpu_off = <1>;
|
||||
cpu_on = <2>;
|
||||
};
|
||||
|
||||
axi@81000000 {
|
||||
compatible = "simple-bus";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0x81000000 0x4000>;
|
||||
ranges = <0 0x81000000 0x8000>;
|
||||
|
||||
gic: interrupt-controller@1000 {
|
||||
compatible = "arm,cortex-a7-gic";
|
||||
#interrupt-cells = <3>;
|
||||
#address-cells = <0>;
|
||||
interrupt-controller;
|
||||
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(3) | IRQ_TYPE_LEVEL_HIGH)>;
|
||||
reg = <0x1000 0x1000>,
|
||||
<0x2000 0x2000>;
|
||||
<0x2000 0x2000>,
|
||||
<0x4000 0x2000>,
|
||||
<0x6000 0x2000>;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
@ -40,10 +40,10 @@
|
||||
|
||||
timer {
|
||||
compatible = "arm,armv7-timer";
|
||||
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
|
||||
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
|
||||
arm,cpu-registers-not-fw-configured;
|
||||
};
|
||||
|
||||
@ -65,23 +65,23 @@
|
||||
psci {
|
||||
compatible = "arm,psci-0.2";
|
||||
method = "smc";
|
||||
cpu_off = <1>;
|
||||
cpu_on = <2>;
|
||||
};
|
||||
|
||||
axi@81000000 {
|
||||
compatible = "simple-bus";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0x81000000 0x4000>;
|
||||
ranges = <0 0x81000000 0x8000>;
|
||||
|
||||
gic: interrupt-controller@1000 {
|
||||
compatible = "arm,cortex-a7-gic";
|
||||
#interrupt-cells = <3>;
|
||||
#address-cells = <0>;
|
||||
interrupt-controller;
|
||||
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
|
||||
reg = <0x1000 0x1000>,
|
||||
<0x2000 0x2000>;
|
||||
<0x2000 0x2000>,
|
||||
<0x4000 0x2000>,
|
||||
<0x6000 0x2000>;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
@ -32,6 +32,7 @@
|
||||
next-level-cache = <&L2_0>;
|
||||
enable-method = "psci";
|
||||
};
|
||||
|
||||
L2_0: l2-cache0 {
|
||||
compatible = "cache";
|
||||
};
|
||||
@ -39,10 +40,10 @@
|
||||
|
||||
timer {
|
||||
compatible = "arm,armv7-timer";
|
||||
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
|
||||
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
|
||||
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
|
||||
arm,cpu-registers-not-fw-configured;
|
||||
};
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user