mirror of
https://github.com/torvalds/linux.git
synced 2024-09-20 15:03:04 +00:00
Linux 6.8
-----BEGIN PGP SIGNATURE----- iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmXuGjEeHHRvcnZhbGRz QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGlhYH/3entux62pEL1BSR 3UNZvs41dZ6BW60d5+DQ+v/GnyEwn4Krtf054sfVL3cwGBLbErndo4F2eSHgMnRy zUTLXl+aAQRpC47phNvXu1bC6jXm+xuXu/8VBYZWP+IP10zFtdSeTC2lQtYwpFd9 u1ZqUtTfKSWjADToLW6asjlviO6MV9rdAYkttJYcQ7Ztn/v+NAECMb0AvFDKHvh4 g74BA3bqslX1fPOMyAH/4u/IL0PRj1usLvbCsTAujb5R9121geYRBylgw0Ei3YXx P+vaOmJeO33bWiRNdfxEMoQSfJ+q7Jq/x5utZ/SckAy8bFJG7VimQwRrFYtcN6ls LR0oKRY= =e2GM -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmX4emYACgkQJNaLcl1U h9AkWgf9Efiayi+sO/vkE7bVL6bMajuZ6gm1Au2xT542JM90iYKXiuulEw5WKhq4 iEl5WyJb+DePFUPQYAeITgYgF+xE+7TZgdqWFyYSSOtAqqLhZ15jkR7xf3sGtkJO svPzEoxzL9Vg+sCTvXG8ZRZcDa/QcbPHckHVAtjXA1oUn3V7ze8YjvPITdhzL9cA H6oszBkzpYupGcuJqByYRABH7DvBEjUEUmEuvbIi+fyq/zmfCwvvrbmEI0EitN5E xENB89Tc1sTHMehlY2oouQnc5GyGVaUFjohEZchq4H86KHmOmZJSsXk3akJHSsDE XHjrUojAL2huo29tULxC2QS87peg8g== =oDh+ -----END PGP SIGNATURE----- spi: Merge up v6.8 release An i.MX fix depends on other fixes that were sent to v6.8.
This commit is contained in:
commit
5bd249aec7
18
.mailmap
18
.mailmap
|
@ -191,10 +191,11 @@ Gao Xiang <xiang@kernel.org> <gaoxiang25@huawei.com>
|
|||
Gao Xiang <xiang@kernel.org> <hsiangkao@aol.com>
|
||||
Gao Xiang <xiang@kernel.org> <hsiangkao@linux.alibaba.com>
|
||||
Gao Xiang <xiang@kernel.org> <hsiangkao@redhat.com>
|
||||
Geliang Tang <geliang.tang@linux.dev> <geliang.tang@suse.com>
|
||||
Geliang Tang <geliang.tang@linux.dev> <geliangtang@xiaomi.com>
|
||||
Geliang Tang <geliang.tang@linux.dev> <geliangtang@gmail.com>
|
||||
Geliang Tang <geliang.tang@linux.dev> <geliangtang@163.com>
|
||||
Geliang Tang <geliang@kernel.org> <geliang.tang@linux.dev>
|
||||
Geliang Tang <geliang@kernel.org> <geliang.tang@suse.com>
|
||||
Geliang Tang <geliang@kernel.org> <geliangtang@xiaomi.com>
|
||||
Geliang Tang <geliang@kernel.org> <geliangtang@gmail.com>
|
||||
Geliang Tang <geliang@kernel.org> <geliangtang@163.com>
|
||||
Georgi Djakov <djakov@kernel.org> <georgi.djakov@linaro.org>
|
||||
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <geraldsc@de.ibm.com>
|
||||
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <gerald.schaefer@de.ibm.com>
|
||||
|
@ -289,6 +290,7 @@ Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com>
|
|||
John Crispin <john@phrozen.org> <blogic@openwrt.org>
|
||||
John Fastabend <john.fastabend@gmail.com> <john.r.fastabend@intel.com>
|
||||
John Keeping <john@keeping.me.uk> <john@metanate.com>
|
||||
John Moon <john@jmoon.dev> <quic_johmoo@quicinc.com>
|
||||
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
|
||||
John Stultz <johnstul@us.ibm.com>
|
||||
<jon.toppins+linux@gmail.com> <jtoppins@cumulusnetworks.com>
|
||||
|
@ -323,6 +325,7 @@ Kenneth W Chen <kenneth.w.chen@intel.com>
|
|||
Kenneth Westfield <quic_kwestfie@quicinc.com> <kwestfie@codeaurora.org>
|
||||
Kiran Gunda <quic_kgunda@quicinc.com> <kgunda@codeaurora.org>
|
||||
Kirill Tkhai <tkhai@ya.ru> <ktkhai@virtuozzo.com>
|
||||
Kishon Vijay Abraham I <kishon@kernel.org> <kishon@ti.com>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
|
||||
Koushik <raghavendra.koushik@neterion.com>
|
||||
|
@ -344,6 +347,7 @@ Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
|||
Leon Romanovsky <leon@kernel.org> <leon@leon.nu>
|
||||
Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com>
|
||||
Leon Romanovsky <leon@kernel.org> <leonro@nvidia.com>
|
||||
Leo Yan <leo.yan@linux.dev> <leo.yan@linaro.org>
|
||||
Liam Mark <quic_lmark@quicinc.com> <lmark@codeaurora.org>
|
||||
Linas Vepstas <linas@austin.ibm.com>
|
||||
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>
|
||||
|
@ -550,6 +554,7 @@ Senthilkumar N L <quic_snlakshm@quicinc.com> <snlakshm@codeaurora.org>
|
|||
Serge Hallyn <sergeh@kernel.org> <serge.hallyn@canonical.com>
|
||||
Serge Hallyn <sergeh@kernel.org> <serue@us.ibm.com>
|
||||
Seth Forshee <sforshee@kernel.org> <seth.forshee@canonical.com>
|
||||
Shakeel Butt <shakeel.butt@linux.dev> <shakeelb@google.com>
|
||||
Shannon Nelson <shannon.nelson@amd.com> <snelson@pensando.io>
|
||||
Shannon Nelson <shannon.nelson@amd.com> <shannon.nelson@intel.com>
|
||||
Shannon Nelson <shannon.nelson@amd.com> <shannon.nelson@oracle.com>
|
||||
|
@ -605,6 +610,11 @@ TripleX Chung <xxx.phy@gmail.com> <triplex@zh-kernel.org>
|
|||
TripleX Chung <xxx.phy@gmail.com> <zhongyu@18mail.cn>
|
||||
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
|
||||
Tudor Ambarus <tudor.ambarus@linaro.org> <tudor.ambarus@microchip.com>
|
||||
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@intel.com>
|
||||
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@linux.intel.com>
|
||||
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@sophos.com>
|
||||
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@onelan.co.uk>
|
||||
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko@ursulin.net>
|
||||
Tycho Andersen <tycho@tycho.pizza> <tycho@tycho.ws>
|
||||
Tzung-Bi Shih <tzungbi@kernel.org> <tzungbi@google.com>
|
||||
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
What: /sys/class/<iface>/statistics/collisions
|
||||
What: /sys/class/net/<iface>/statistics/collisions
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -6,7 +6,7 @@ Description:
|
|||
Indicates the number of collisions seen by this network device.
|
||||
This value might not be relevant with all MAC layers.
|
||||
|
||||
What: /sys/class/<iface>/statistics/multicast
|
||||
What: /sys/class/net/<iface>/statistics/multicast
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -14,7 +14,7 @@ Description:
|
|||
Indicates the number of multicast packets received by this
|
||||
network device.
|
||||
|
||||
What: /sys/class/<iface>/statistics/rx_bytes
|
||||
What: /sys/class/net/<iface>/statistics/rx_bytes
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -23,7 +23,7 @@ Description:
|
|||
See the network driver for the exact meaning of when this
|
||||
value is incremented.
|
||||
|
||||
What: /sys/class/<iface>/statistics/rx_compressed
|
||||
What: /sys/class/net/<iface>/statistics/rx_compressed
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -32,7 +32,7 @@ Description:
|
|||
network device. This value might only be relevant for interfaces
|
||||
that support packet compression (e.g: PPP).
|
||||
|
||||
What: /sys/class/<iface>/statistics/rx_crc_errors
|
||||
What: /sys/class/net/<iface>/statistics/rx_crc_errors
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -41,7 +41,7 @@ Description:
|
|||
by this network device. Note that the specific meaning might
|
||||
depend on the MAC layer used by the interface.
|
||||
|
||||
What: /sys/class/<iface>/statistics/rx_dropped
|
||||
What: /sys/class/net/<iface>/statistics/rx_dropped
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -51,7 +51,7 @@ Description:
|
|||
packet processing. See the network driver for the exact
|
||||
meaning of this value.
|
||||
|
||||
What: /sys/class/<iface>/statistics/rx_errors
|
||||
What: /sys/class/net/<iface>/statistics/rx_errors
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -59,7 +59,7 @@ Description:
|
|||
Indicates the number of receive errors on this network device.
|
||||
See the network driver for the exact meaning of this value.
|
||||
|
||||
What: /sys/class/<iface>/statistics/rx_fifo_errors
|
||||
What: /sys/class/net/<iface>/statistics/rx_fifo_errors
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -68,7 +68,7 @@ Description:
|
|||
network device. See the network driver for the exact
|
||||
meaning of this value.
|
||||
|
||||
What: /sys/class/<iface>/statistics/rx_frame_errors
|
||||
What: /sys/class/net/<iface>/statistics/rx_frame_errors
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -78,7 +78,7 @@ Description:
|
|||
on the MAC layer protocol used. See the network driver for
|
||||
the exact meaning of this value.
|
||||
|
||||
What: /sys/class/<iface>/statistics/rx_length_errors
|
||||
What: /sys/class/net/<iface>/statistics/rx_length_errors
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -87,7 +87,7 @@ Description:
|
|||
error, oversized or undersized. See the network driver for the
|
||||
exact meaning of this value.
|
||||
|
||||
What: /sys/class/<iface>/statistics/rx_missed_errors
|
||||
What: /sys/class/net/<iface>/statistics/rx_missed_errors
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -96,7 +96,7 @@ Description:
|
|||
due to lack of capacity in the receive side. See the network
|
||||
driver for the exact meaning of this value.
|
||||
|
||||
What: /sys/class/<iface>/statistics/rx_nohandler
|
||||
What: /sys/class/net/<iface>/statistics/rx_nohandler
|
||||
Date: February 2016
|
||||
KernelVersion: 4.6
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -104,7 +104,7 @@ Description:
|
|||
Indicates the number of received packets that were dropped on
|
||||
an inactive device by the network core.
|
||||
|
||||
What: /sys/class/<iface>/statistics/rx_over_errors
|
||||
What: /sys/class/net/<iface>/statistics/rx_over_errors
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -114,7 +114,7 @@ Description:
|
|||
(e.g: larger than MTU). See the network driver for the exact
|
||||
meaning of this value.
|
||||
|
||||
What: /sys/class/<iface>/statistics/rx_packets
|
||||
What: /sys/class/net/<iface>/statistics/rx_packets
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -122,7 +122,7 @@ Description:
|
|||
Indicates the total number of good packets received by this
|
||||
network device.
|
||||
|
||||
What: /sys/class/<iface>/statistics/tx_aborted_errors
|
||||
What: /sys/class/net/<iface>/statistics/tx_aborted_errors
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -132,7 +132,7 @@ Description:
|
|||
a medium collision). See the network driver for the exact
|
||||
meaning of this value.
|
||||
|
||||
What: /sys/class/<iface>/statistics/tx_bytes
|
||||
What: /sys/class/net/<iface>/statistics/tx_bytes
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -143,7 +143,7 @@ Description:
|
|||
transmitted packets or all packets that have been queued for
|
||||
transmission.
|
||||
|
||||
What: /sys/class/<iface>/statistics/tx_carrier_errors
|
||||
What: /sys/class/net/<iface>/statistics/tx_carrier_errors
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -152,7 +152,7 @@ Description:
|
|||
because of carrier errors (e.g: physical link down). See the
|
||||
network driver for the exact meaning of this value.
|
||||
|
||||
What: /sys/class/<iface>/statistics/tx_compressed
|
||||
What: /sys/class/net/<iface>/statistics/tx_compressed
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -161,7 +161,7 @@ Description:
|
|||
this might only be relevant for devices that support
|
||||
compression (e.g: PPP).
|
||||
|
||||
What: /sys/class/<iface>/statistics/tx_dropped
|
||||
What: /sys/class/net/<iface>/statistics/tx_dropped
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -170,7 +170,7 @@ Description:
|
|||
See the driver for the exact reasons as to why the packets were
|
||||
dropped.
|
||||
|
||||
What: /sys/class/<iface>/statistics/tx_errors
|
||||
What: /sys/class/net/<iface>/statistics/tx_errors
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -179,7 +179,7 @@ Description:
|
|||
a network device. See the driver for the exact reasons as to
|
||||
why the packets were dropped.
|
||||
|
||||
What: /sys/class/<iface>/statistics/tx_fifo_errors
|
||||
What: /sys/class/net/<iface>/statistics/tx_fifo_errors
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -188,7 +188,7 @@ Description:
|
|||
FIFO error. See the driver for the exact reasons as to why the
|
||||
packets were dropped.
|
||||
|
||||
What: /sys/class/<iface>/statistics/tx_heartbeat_errors
|
||||
What: /sys/class/net/<iface>/statistics/tx_heartbeat_errors
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -197,7 +197,7 @@ Description:
|
|||
reported as heartbeat errors. See the driver for the exact
|
||||
reasons as to why the packets were dropped.
|
||||
|
||||
What: /sys/class/<iface>/statistics/tx_packets
|
||||
What: /sys/class/net/<iface>/statistics/tx_packets
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
@ -206,7 +206,7 @@ Description:
|
|||
device. See the driver for whether this reports the number of all
|
||||
attempted or successful transmissions.
|
||||
|
||||
What: /sys/class/<iface>/statistics/tx_window_errors
|
||||
What: /sys/class/net/<iface>/statistics/tx_window_errors
|
||||
Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: netdev@vger.kernel.org
|
||||
|
|
|
@ -4,18 +4,18 @@ KernelVersion: 6.5
|
|||
Contact: Miquel Raynal <miquel.raynal@bootlin.com>
|
||||
Description:
|
||||
The "cells" folder contains one file per cell exposed by the
|
||||
NVMEM device. The name of the file is: <name>@<where>, with
|
||||
<name> being the cell name and <where> its location in the NVMEM
|
||||
device, in hexadecimal (without the '0x' prefix, to mimic device
|
||||
tree node names). The length of the file is the size of the cell
|
||||
(when known). The content of the file is the binary content of
|
||||
the cell (may sometimes be ASCII, likely without trailing
|
||||
character).
|
||||
NVMEM device. The name of the file is: "<name>@<byte>,<bit>",
|
||||
with <name> being the cell name and <where> its location in
|
||||
the NVMEM device, in hexadecimal bytes and bits (without the
|
||||
'0x' prefix, to mimic device tree node names). The length of
|
||||
the file is the size of the cell (when known). The content of
|
||||
the file is the binary content of the cell (may sometimes be
|
||||
ASCII, likely without trailing character).
|
||||
Note: This file is only present if CONFIG_NVMEM_SYSFS
|
||||
is enabled.
|
||||
|
||||
Example::
|
||||
|
||||
hexdump -C /sys/bus/nvmem/devices/1-00563/cells/product-name@d
|
||||
hexdump -C /sys/bus/nvmem/devices/1-00563/cells/product-name@d,0
|
||||
00000000 54 4e 34 38 4d 2d 50 2d 44 4e |TN48M-P-DN|
|
||||
0000000a
|
||||
|
|
|
@ -243,3 +243,10 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ASR | ASR8601 | #8601001 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Microsoft | Azure Cobalt 100| #2139208 | ARM64_ERRATUM_2139208 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Microsoft | Azure Cobalt 100| #2067961 | ARM64_ERRATUM_2067961 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Microsoft | Azure Cobalt 100| #2253138 | ARM64_ERRATUM_2253138 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
|
|
|
@ -95,6 +95,9 @@ The kernel provides a function to invoke the buffer clearing:
|
|||
|
||||
mds_clear_cpu_buffers()
|
||||
|
||||
Also macro CLEAR_CPU_BUFFERS can be used in ASM late in exit-to-user path.
|
||||
Other than CFLAGS.ZF, this macro doesn't clobber any registers.
|
||||
|
||||
The mitigation is invoked on kernel/userspace, hypervisor/guest and C-state
|
||||
(idle) transitions.
|
||||
|
||||
|
@ -138,17 +141,30 @@ Mitigation points
|
|||
|
||||
When transitioning from kernel to user space the CPU buffers are flushed
|
||||
on affected CPUs when the mitigation is not disabled on the kernel
|
||||
command line. The migitation is enabled through the static key
|
||||
mds_user_clear.
|
||||
command line. The mitigation is enabled through the feature flag
|
||||
X86_FEATURE_CLEAR_CPU_BUF.
|
||||
|
||||
The mitigation is invoked in prepare_exit_to_usermode() which covers
|
||||
all but one of the kernel to user space transitions. The exception
|
||||
is when we return from a Non Maskable Interrupt (NMI), which is
|
||||
handled directly in do_nmi().
|
||||
The mitigation is invoked just before transitioning to userspace after
|
||||
user registers are restored. This is done to minimize the window in
|
||||
which kernel data could be accessed after VERW e.g. via an NMI after
|
||||
VERW.
|
||||
|
||||
(The reason that NMI is special is that prepare_exit_to_usermode() can
|
||||
enable IRQs. In NMI context, NMIs are blocked, and we don't want to
|
||||
enable IRQs with NMIs blocked.)
|
||||
**Corner case not handled**
|
||||
Interrupts returning to kernel don't clear CPUs buffers since the
|
||||
exit-to-user path is expected to do that anyways. But, there could be
|
||||
a case when an NMI is generated in kernel after the exit-to-user path
|
||||
has cleared the buffers. This case is not handled and NMI returning to
|
||||
kernel don't clear CPU buffers because:
|
||||
|
||||
1. It is rare to get an NMI after VERW, but before returning to userspace.
|
||||
2. For an unprivileged user, there is no known way to make that NMI
|
||||
less rare or target it.
|
||||
3. It would take a large number of these precisely-timed NMIs to mount
|
||||
an actual attack. There's presumably not enough bandwidth.
|
||||
4. The NMI in question occurs after a VERW, i.e. when user state is
|
||||
restored and most interesting data is already scrubbed. Whats left
|
||||
is only the data that NMI touches, and that may or may not be of
|
||||
any interest.
|
||||
|
||||
|
||||
2. C-State transition
|
||||
|
|
|
@ -388,6 +388,12 @@ latex_elements = {
|
|||
verbatimhintsturnover=false,
|
||||
''',
|
||||
|
||||
#
|
||||
# Some of our authors are fond of deep nesting; tell latex to
|
||||
# cope.
|
||||
#
|
||||
'maxlistdepth': '10',
|
||||
|
||||
# For CJK One-half spacing, need to be in front of hyperref
|
||||
'extrapackages': r'\usepackage{setspace}',
|
||||
|
||||
|
|
|
@ -28,7 +28,10 @@ $(obj)/%.example.dts: $(src)/%.yaml check_dtschema_version FORCE
|
|||
find_all_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \
|
||||
-name 'processed-schema*' \)
|
||||
|
||||
find_cmd = $(find_all_cmd) | sed 's|^$(srctree)/$(src)/||' | grep -F -e "$(subst :," -e ",$(DT_SCHEMA_FILES))" | sed 's|^|$(srctree)/$(src)/|'
|
||||
find_cmd = $(find_all_cmd) | \
|
||||
sed 's|^$(srctree)/||' | \
|
||||
grep -F -e "$(subst :," -e ",$(DT_SCHEMA_FILES))" | \
|
||||
sed 's|^|$(srctree)/|'
|
||||
CHK_DT_DOCS := $(shell $(find_cmd))
|
||||
|
||||
quiet_cmd_yamllint = LINT $(src)
|
||||
|
|
|
@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Ceva AHCI SATA Controller
|
||||
|
||||
maintainers:
|
||||
- Piyush Mehta <piyush.mehta@amd.com>
|
||||
- Mubin Sayyed <mubin.sayyed@amd.com>
|
||||
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
|
||||
|
||||
description: |
|
||||
The Ceva SATA controller mostly conforms to the AHCI interface with some
|
||||
|
|
|
@ -85,8 +85,8 @@ allOf:
|
|||
|
||||
clock-names:
|
||||
items:
|
||||
- const: dout_cmu_misc_bus
|
||||
- const: dout_cmu_misc_sss
|
||||
- const: bus
|
||||
- const: sss
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
|
|
@ -29,19 +29,22 @@ properties:
|
|||
|
||||
audio-ports:
|
||||
description:
|
||||
Array of 8-bit values, 2 values per DAI (Documentation/sound/soc/dai.rst).
|
||||
Array of 2 values per DAI (Documentation/sound/soc/dai.rst).
|
||||
The implementation allows one or two DAIs.
|
||||
If two DAIs are defined, they must be of different type.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-matrix
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
items:
|
||||
minItems: 1
|
||||
items:
|
||||
- description: |
|
||||
The first value defines the DAI type: TDA998x_SPDIF or TDA998x_I2S
|
||||
(see include/dt-bindings/display/tda998x.h).
|
||||
enum: [ 1, 2 ]
|
||||
- description:
|
||||
The second value defines the tda998x AP_ENA reg content when the
|
||||
DAI in question is used.
|
||||
maximum: 0xff
|
||||
|
||||
'#sound-dai-cells':
|
||||
enum: [ 0, 1 ]
|
||||
|
|
|
@ -12,7 +12,8 @@ description:
|
|||
PS_MODE). Every pin can be configured as input/output.
|
||||
|
||||
maintainers:
|
||||
- Piyush Mehta <piyush.mehta@amd.com>
|
||||
- Mubin Sayyed <mubin.sayyed@amd.com>
|
||||
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -78,8 +78,8 @@ examples:
|
|||
pcie@0 {
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
ranges = <0x0 0x0 0x0 0x0 0x0 0x0>;
|
||||
reg = <0x0 0x0 0x0 0x0 0x0 0x0>;
|
||||
ranges = <0x02000000 0x0 0x100000 0x10000000 0x0 0x0>;
|
||||
reg = <0x0 0x1000>;
|
||||
device_type = "pci";
|
||||
|
||||
switch@0,0 {
|
||||
|
|
|
@ -65,9 +65,11 @@ properties:
|
|||
|
||||
rx-internal-delay-ps:
|
||||
enum: [0, 1800]
|
||||
default: 0
|
||||
|
||||
tx-internal-delay-ps:
|
||||
enum: [0, 2000]
|
||||
default: 0
|
||||
|
||||
'#address-cells':
|
||||
const: 1
|
||||
|
|
|
@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Zynq UltraScale+ MPSoC and Versal reset
|
||||
|
||||
maintainers:
|
||||
- Piyush Mehta <piyush.mehta@amd.com>
|
||||
- Mubin Sayyed <mubin.sayyed@amd.com>
|
||||
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
|
||||
|
||||
description: |
|
||||
The Zynq UltraScale+ MPSoC and Versal has several different resets.
|
||||
|
|
|
@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Google SC7280-Herobrine ASoC sound card driver
|
||||
|
||||
maintainers:
|
||||
- Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
|
||||
- Judy Hsiao <judyhsiao@chromium.org>
|
||||
|
||||
description:
|
||||
|
|
|
@ -64,7 +64,7 @@ examples:
|
|||
#include <dt-bindings/clock/tegra30-car.h>
|
||||
#include <dt-bindings/soc/tegra-pmc.h>
|
||||
sound {
|
||||
compatible = "lge,tegra-audio-max98089-p895",
|
||||
compatible = "lg,tegra-audio-max98089-p895",
|
||||
"nvidia,tegra-audio-max98089";
|
||||
nvidia,model = "LG Optimus Vu MAX98089";
|
||||
|
||||
|
|
|
@ -42,7 +42,7 @@ properties:
|
|||
|
||||
resets:
|
||||
description: Reset controller to reset the TPM
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios:
|
||||
description: Output GPIO pin to reset the TPM
|
||||
|
|
|
@ -55,9 +55,12 @@ properties:
|
|||
|
||||
samsung,sysreg:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description: Should be phandle/offset pair. The phandle to the syscon node
|
||||
which indicates the FSYSx sysreg interface and the offset of
|
||||
the control register for UFS io coherency setting.
|
||||
items:
|
||||
- items:
|
||||
- description: phandle to FSYSx sysreg node
|
||||
- description: offset of the control register for UFS io coherency setting
|
||||
description:
|
||||
Phandle and offset to the FSYSx sysreg for UFS io coherency setting.
|
||||
|
||||
dma-coherent: true
|
||||
|
||||
|
|
|
@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Xilinx SuperSpeed DWC3 USB SoC controller
|
||||
|
||||
maintainers:
|
||||
- Piyush Mehta <piyush.mehta@amd.com>
|
||||
- Mubin Sayyed <mubin.sayyed@amd.com>
|
||||
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -16,8 +16,9 @@ description:
|
|||
USB 2.0 traffic.
|
||||
|
||||
maintainers:
|
||||
- Piyush Mehta <piyush.mehta@amd.com>
|
||||
- Michal Simek <michal.simek@amd.com>
|
||||
- Mubin Sayyed <mubin.sayyed@amd.com>
|
||||
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Xilinx udc controller
|
||||
|
||||
maintainers:
|
||||
- Piyush Mehta <piyush.mehta@amd.com>
|
||||
- Mubin Sayyed <mubin.sayyed@amd.com>
|
||||
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -545,7 +545,7 @@ In such scenario, dpll device input signal shall be also configurable
|
|||
to drive dpll with signal recovered from the PHY netdevice.
|
||||
This is done by exposing a pin to the netdevice - attaching pin to the
|
||||
netdevice itself with
|
||||
``netdev_dpll_pin_set(struct net_device *dev, struct dpll_pin *dpll_pin)``.
|
||||
``dpll_netdev_pin_set(struct net_device *dev, struct dpll_pin *dpll_pin)``.
|
||||
Exposed pin id handle ``DPLL_A_PIN_ID`` is then identifiable by the user
|
||||
as it is attached to rtnetlink respond to get ``RTM_NEWLINK`` command in
|
||||
nested attribute ``IFLA_DPLL_PIN``.
|
||||
|
|
|
@ -16,13 +16,13 @@
|
|||
# that are possible for CORE. So for example if CORE_BELL_A_ADVANCED is 'y',
|
||||
# CORE must be 'y' too.
|
||||
#
|
||||
# * What influences CORE_BELL_A_ADVANCED ?
|
||||
# * What influences CORE_BELL_A_ADVANCED?
|
||||
#
|
||||
# As the name implies CORE_BELL_A_ADVANCED is an advanced feature of
|
||||
# CORE_BELL_A so naturally it depends on CORE_BELL_A. So if CORE_BELL_A is 'y'
|
||||
# we know CORE_BELL_A_ADVANCED can be 'y' too.
|
||||
#
|
||||
# * What influences CORE_BELL_A ?
|
||||
# * What influences CORE_BELL_A?
|
||||
#
|
||||
# CORE_BELL_A depends on CORE, so CORE influences CORE_BELL_A.
|
||||
#
|
||||
|
@ -34,7 +34,7 @@
|
|||
# the "recursive dependency detected" error.
|
||||
#
|
||||
# Reading the Documentation/kbuild/Kconfig.recursion-issue-01 file it may be
|
||||
# obvious that an easy to solution to this problem should just be the removal
|
||||
# obvious that an easy solution to this problem should just be the removal
|
||||
# of the "select CORE" from CORE_BELL_A_ADVANCED as that is implicit already
|
||||
# since CORE_BELL_A depends on CORE. Recursive dependency issues are not always
|
||||
# so trivial to resolve, we provide another example below of practical
|
||||
|
|
|
@ -384,8 +384,6 @@ operations:
|
|||
- type
|
||||
|
||||
dump:
|
||||
pre: dpll-lock-dumpit
|
||||
post: dpll-unlock-dumpit
|
||||
reply: *dev-attrs
|
||||
|
||||
-
|
||||
|
@ -473,8 +471,6 @@ operations:
|
|||
- fractional-frequency-offset
|
||||
|
||||
dump:
|
||||
pre: dpll-lock-dumpit
|
||||
post: dpll-unlock-dumpit
|
||||
request:
|
||||
attributes:
|
||||
- id
|
||||
|
|
|
@ -126,7 +126,7 @@ Users may also set the RoCE capability of the function using
|
|||
`devlink port function set roce` command.
|
||||
|
||||
Users may also set the function as migratable using
|
||||
'devlink port function set migratable' command.
|
||||
`devlink port function set migratable` command.
|
||||
|
||||
Users may also set the IPsec crypto capability of the function using
|
||||
`devlink port function set ipsec_crypto` command.
|
||||
|
|
|
@ -1,9 +1,9 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. Copyright (C) 2023 Google LLC
|
||||
|
||||
=====================================================
|
||||
inet_connection_sock struct fast path usage breakdown
|
||||
=====================================================
|
||||
==========================================
|
||||
inet_sock struct fast path usage breakdown
|
||||
==========================================
|
||||
|
||||
Type Name fastpath_tx_access fastpath_rx_access comment
|
||||
..struct ..inet_sock
|
||||
|
|
|
@ -136,8 +136,8 @@ struct_netpoll_info* npinfo -
|
|||
possible_net_t nd_net - read_mostly (dev_net)napi_busy_loop,tcp_v(4/6)_rcv,ip(v6)_rcv,ip(6)_input,ip(6)_input_finish
|
||||
void* ml_priv
|
||||
enum_netdev_ml_priv_type ml_priv_type
|
||||
struct_pcpu_lstats__percpu* lstats
|
||||
struct_pcpu_sw_netstats__percpu* tstats
|
||||
struct_pcpu_lstats__percpu* lstats read_mostly dev_lstats_add()
|
||||
struct_pcpu_sw_netstats__percpu* tstats read_mostly dev_sw_netstats_tx_add()
|
||||
struct_pcpu_dstats__percpu* dstats
|
||||
struct_garp_port* garp_port
|
||||
struct_mrp_port* mrp_port
|
||||
|
|
|
@ -38,13 +38,13 @@ u32 max_window read_mostly -
|
|||
u32 mss_cache read_mostly read_mostly tcp_rate_check_app_limited,tcp_current_mss,tcp_sync_mss,tcp_sndbuf_expand,tcp_tso_should_defer(tx);tcp_update_pacing_rate,tcp_clean_rtx_queue(rx)
|
||||
u32 window_clamp read_mostly read_write tcp_rcv_space_adjust,__tcp_select_window
|
||||
u32 rcv_ssthresh read_mostly - __tcp_select_window
|
||||
u82 scaling_ratio
|
||||
u8 scaling_ratio read_mostly read_mostly tcp_win_from_space
|
||||
struct tcp_rack
|
||||
u16 advmss - read_mostly tcp_rcv_space_adjust
|
||||
u8 compressed_ack
|
||||
u8:2 dup_ack_counter
|
||||
u8:1 tlp_retrans
|
||||
u8:1 tcp_usec_ts
|
||||
u8:1 tcp_usec_ts read_mostly read_mostly
|
||||
u32 chrono_start read_write - tcp_chrono_start/stop(tcp_write_xmit,tcp_cwnd_validate,tcp_send_syn_data)
|
||||
u32[3] chrono_stat read_write - tcp_chrono_start/stop(tcp_write_xmit,tcp_cwnd_validate,tcp_send_syn_data)
|
||||
u8:2 chrono_type read_write - tcp_chrono_start/stop(tcp_write_xmit,tcp_cwnd_validate,tcp_send_syn_data)
|
||||
|
|
121
Documentation/process/cve.rst
Normal file
121
Documentation/process/cve.rst
Normal file
|
@ -0,0 +1,121 @@
|
|||
====
|
||||
CVEs
|
||||
====
|
||||
|
||||
Common Vulnerabilities and Exposure (CVE®) numbers were developed as an
|
||||
unambiguous way to identify, define, and catalog publicly disclosed
|
||||
security vulnerabilities. Over time, their usefulness has declined with
|
||||
regards to the kernel project, and CVE numbers were very often assigned
|
||||
in inappropriate ways and for inappropriate reasons. Because of this,
|
||||
the kernel development community has tended to avoid them. However, the
|
||||
combination of continuing pressure to assign CVEs and other forms of
|
||||
security identifiers, and ongoing abuses by individuals and companies
|
||||
outside of the kernel community has made it clear that the kernel
|
||||
community should have control over those assignments.
|
||||
|
||||
The Linux kernel developer team does have the ability to assign CVEs for
|
||||
potential Linux kernel security issues. This assignment is independent
|
||||
of the :doc:`normal Linux kernel security bug reporting
|
||||
process<../process/security-bugs>`.
|
||||
|
||||
A list of all assigned CVEs for the Linux kernel can be found in the
|
||||
archives of the linux-cve mailing list, as seen on
|
||||
https://lore.kernel.org/linux-cve-announce/. To get notice of the
|
||||
assigned CVEs, please `subscribe
|
||||
<https://subspace.kernel.org/subscribing.html>`_ to that mailing list.
|
||||
|
||||
Process
|
||||
=======
|
||||
|
||||
As part of the normal stable release process, kernel changes that are
|
||||
potentially security issues are identified by the developers responsible
|
||||
for CVE number assignments and have CVE numbers automatically assigned
|
||||
to them. These assignments are published on the linux-cve-announce
|
||||
mailing list as announcements on a frequent basis.
|
||||
|
||||
Note, due to the layer at which the Linux kernel is in a system, almost
|
||||
any bug might be exploitable to compromise the security of the kernel,
|
||||
but the possibility of exploitation is often not evident when the bug is
|
||||
fixed. Because of this, the CVE assignment team is overly cautious and
|
||||
assign CVE numbers to any bugfix that they identify. This
|
||||
explains the seemingly large number of CVEs that are issued by the Linux
|
||||
kernel team.
|
||||
|
||||
If the CVE assignment team misses a specific fix that any user feels
|
||||
should have a CVE assigned to it, please email them at <cve@kernel.org>
|
||||
and the team there will work with you on it. Note that no potential
|
||||
security issues should be sent to this alias, it is ONLY for assignment
|
||||
of CVEs for fixes that are already in released kernel trees. If you
|
||||
feel you have found an unfixed security issue, please follow the
|
||||
:doc:`normal Linux kernel security bug reporting
|
||||
process<../process/security-bugs>`.
|
||||
|
||||
No CVEs will be automatically assigned for unfixed security issues in
|
||||
the Linux kernel; assignment will only automatically happen after a fix
|
||||
is available and applied to a stable kernel tree, and it will be tracked
|
||||
that way by the git commit id of the original fix. If anyone wishes to
|
||||
have a CVE assigned before an issue is resolved with a commit, please
|
||||
contact the kernel CVE assignment team at <cve@kernel.org> to get an
|
||||
identifier assigned from their batch of reserved identifiers.
|
||||
|
||||
No CVEs will be assigned for any issue found in a version of the kernel
|
||||
that is not currently being actively supported by the Stable/LTS kernel
|
||||
team. A list of the currently supported kernel branches can be found at
|
||||
https://kernel.org/releases.html
|
||||
|
||||
Disputes of assigned CVEs
|
||||
=========================
|
||||
|
||||
The authority to dispute or modify an assigned CVE for a specific kernel
|
||||
change lies solely with the maintainers of the relevant subsystem
|
||||
affected. This principle ensures a high degree of accuracy and
|
||||
accountability in vulnerability reporting. Only those individuals with
|
||||
deep expertise and intimate knowledge of the subsystem can effectively
|
||||
assess the validity and scope of a reported vulnerability and determine
|
||||
its appropriate CVE designation. Any attempt to modify or dispute a CVE
|
||||
outside of this designated authority could lead to confusion, inaccurate
|
||||
reporting, and ultimately, compromised systems.
|
||||
|
||||
Invalid CVEs
|
||||
============
|
||||
|
||||
If a security issue is found in a Linux kernel that is only supported by
|
||||
a Linux distribution due to the changes that have been made by that
|
||||
distribution, or due to the distribution supporting a kernel version
|
||||
that is no longer one of the kernel.org supported releases, then a CVE
|
||||
can not be assigned by the Linux kernel CVE team, and must be asked for
|
||||
from that Linux distribution itself.
|
||||
|
||||
Any CVE that is assigned against the Linux kernel for an actively
|
||||
supported kernel version, by any group other than the kernel assignment
|
||||
CVE team should not be treated as a valid CVE. Please notify the
|
||||
kernel CVE assignment team at <cve@kernel.org> so that they can work to
|
||||
invalidate such entries through the CNA remediation process.
|
||||
|
||||
Applicability of specific CVEs
|
||||
==============================
|
||||
|
||||
As the Linux kernel can be used in many different ways, with many
|
||||
different ways of accessing it by external users, or no access at all,
|
||||
the applicability of any specific CVE is up to the user of Linux to
|
||||
determine, it is not up to the CVE assignment team. Please do not
|
||||
contact us to attempt to determine the applicability of any specific
|
||||
CVE.
|
||||
|
||||
Also, as the source tree is so large, and any one system only uses a
|
||||
small subset of the source tree, any users of Linux should be aware that
|
||||
large numbers of assigned CVEs are not relevant for their systems.
|
||||
|
||||
In short, we do not know your use case, and we do not know what portions
|
||||
of the kernel that you use, so there is no way for us to determine if a
|
||||
specific CVE is relevant for your system.
|
||||
|
||||
As always, it is best to take all released kernel changes, as they are
|
||||
tested together in a unified whole by many community members, and not as
|
||||
individual cherry-picked changes. Also note that for many bugs, the
|
||||
solution to the overall problem is not found in a single change, but by
|
||||
the sum of many fixes on top of each other. Ideally CVEs will be
|
||||
assigned to all fixes for all issues, but sometimes we will fail to
|
||||
notice fixes, therefore assume that some changes without a CVE assigned
|
||||
might be relevant to take.
|
||||
|
|
@ -81,6 +81,7 @@ of special classes of bugs: regressions and security problems.
|
|||
|
||||
handling-regressions
|
||||
security-bugs
|
||||
cve
|
||||
embargoed-hardware-issues
|
||||
|
||||
Maintainer information
|
||||
|
|
|
@ -431,7 +431,7 @@ patchwork checks
|
|||
Checks in patchwork are mostly simple wrappers around existing kernel
|
||||
scripts, the sources are available at:
|
||||
|
||||
https://github.com/kuba-moo/nipa/tree/master/tests
|
||||
https://github.com/linux-netdev/nipa/tree/master/tests
|
||||
|
||||
**Do not** post your patches just to run them through the checks.
|
||||
You must ensure that your patches are ready by testing them locally
|
||||
|
|
|
@ -99,9 +99,8 @@ CVE assignment
|
|||
The security team does not assign CVEs, nor do we require them for
|
||||
reports or fixes, as this can needlessly complicate the process and may
|
||||
delay the bug handling. If a reporter wishes to have a CVE identifier
|
||||
assigned, they should find one by themselves, for example by contacting
|
||||
MITRE directly. However under no circumstances will a patch inclusion
|
||||
be delayed to wait for a CVE identifier to arrive.
|
||||
assigned for a confirmed issue, they can contact the :doc:`kernel CVE
|
||||
assignment team<../process/cve>` to obtain one.
|
||||
|
||||
Non-disclosure agreements
|
||||
-------------------------
|
||||
|
|
|
@ -109,7 +109,7 @@ class KernelFeat(Directive):
|
|||
else:
|
||||
out_lines += line + "\n"
|
||||
|
||||
nodeList = self.nestedParse(out_lines, fname)
|
||||
nodeList = self.nestedParse(out_lines, self.arguments[0])
|
||||
return nodeList
|
||||
|
||||
def nestedParse(self, lines, fname):
|
||||
|
|
|
@ -29,10 +29,7 @@ all_languages = {
|
|||
}
|
||||
|
||||
class LanguagesNode(nodes.Element):
|
||||
def __init__(self, current_language, *args, **kwargs):
|
||||
super().__init__(*args, **kwargs)
|
||||
|
||||
self.current_language = current_language
|
||||
pass
|
||||
|
||||
class TranslationsTransform(Transform):
|
||||
default_priority = 900
|
||||
|
@ -49,7 +46,8 @@ class TranslationsTransform(Transform):
|
|||
# normalize docname to be the untranslated one
|
||||
docname = os.path.join(*components[2:])
|
||||
|
||||
new_nodes = LanguagesNode(all_languages[this_lang_code])
|
||||
new_nodes = LanguagesNode()
|
||||
new_nodes['current_language'] = all_languages[this_lang_code]
|
||||
|
||||
for lang_code, lang_name in all_languages.items():
|
||||
if lang_code == this_lang_code:
|
||||
|
@ -84,7 +82,7 @@ def process_languages(app, doctree, docname):
|
|||
|
||||
html_content = app.builder.templates.render('translations.html',
|
||||
context={
|
||||
'current_language': node.current_language,
|
||||
'current_language': node['current_language'],
|
||||
'languages': languages,
|
||||
})
|
||||
|
||||
|
|
|
@ -10,3 +10,4 @@ Hyper-V Enlightenments
|
|||
overview
|
||||
vmbus
|
||||
clocks
|
||||
vpci
|
||||
|
|
316
Documentation/virt/hyperv/vpci.rst
Normal file
316
Documentation/virt/hyperv/vpci.rst
Normal file
|
@ -0,0 +1,316 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
PCI pass-thru devices
|
||||
=========================
|
||||
In a Hyper-V guest VM, PCI pass-thru devices (also called
|
||||
virtual PCI devices, or vPCI devices) are physical PCI devices
|
||||
that are mapped directly into the VM's physical address space.
|
||||
Guest device drivers can interact directly with the hardware
|
||||
without intermediation by the host hypervisor. This approach
|
||||
provides higher bandwidth access to the device with lower
|
||||
latency, compared with devices that are virtualized by the
|
||||
hypervisor. The device should appear to the guest just as it
|
||||
would when running on bare metal, so no changes are required
|
||||
to the Linux device drivers for the device.
|
||||
|
||||
Hyper-V terminology for vPCI devices is "Discrete Device
|
||||
Assignment" (DDA). Public documentation for Hyper-V DDA is
|
||||
available here: `DDA`_
|
||||
|
||||
.. _DDA: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/plan-for-deploying-devices-using-discrete-device-assignment
|
||||
|
||||
DDA is typically used for storage controllers, such as NVMe,
|
||||
and for GPUs. A similar mechanism for NICs is called SR-IOV
|
||||
and produces the same benefits by allowing a guest device
|
||||
driver to interact directly with the hardware. See Hyper-V
|
||||
public documentation here: `SR-IOV`_
|
||||
|
||||
.. _SR-IOV: https://learn.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-single-root-i-o-virtualization--sr-iov-
|
||||
|
||||
This discussion of vPCI devices includes DDA and SR-IOV
|
||||
devices.
|
||||
|
||||
Device Presentation
|
||||
-------------------
|
||||
Hyper-V provides full PCI functionality for a vPCI device when
|
||||
it is operating, so the Linux device driver for the device can
|
||||
be used unchanged, provided it uses the correct Linux kernel
|
||||
APIs for accessing PCI config space and for other integration
|
||||
with Linux. But the initial detection of the PCI device and
|
||||
its integration with the Linux PCI subsystem must use Hyper-V
|
||||
specific mechanisms. Consequently, vPCI devices on Hyper-V
|
||||
have a dual identity. They are initially presented to Linux
|
||||
guests as VMBus devices via the standard VMBus "offer"
|
||||
mechanism, so they have a VMBus identity and appear under
|
||||
/sys/bus/vmbus/devices. The VMBus vPCI driver in Linux at
|
||||
drivers/pci/controller/pci-hyperv.c handles a newly introduced
|
||||
vPCI device by fabricating a PCI bus topology and creating all
|
||||
the normal PCI device data structures in Linux that would
|
||||
exist if the PCI device were discovered via ACPI on a bare-
|
||||
metal system. Once those data structures are set up, the
|
||||
device also has a normal PCI identity in Linux, and the normal
|
||||
Linux device driver for the vPCI device can function as if it
|
||||
were running in Linux on bare-metal. Because vPCI devices are
|
||||
presented dynamically through the VMBus offer mechanism, they
|
||||
do not appear in the Linux guest's ACPI tables. vPCI devices
|
||||
may be added to a VM or removed from a VM at any time during
|
||||
the life of the VM, and not just during initial boot.
|
||||
|
||||
With this approach, the vPCI device is a VMBus device and a
|
||||
PCI device at the same time. In response to the VMBus offer
|
||||
message, the hv_pci_probe() function runs and establishes a
|
||||
VMBus connection to the vPCI VSP on the Hyper-V host. That
|
||||
connection has a single VMBus channel. The channel is used to
|
||||
exchange messages with the vPCI VSP for the purpose of setting
|
||||
up and configuring the vPCI device in Linux. Once the device
|
||||
is fully configured in Linux as a PCI device, the VMBus
|
||||
channel is used only if Linux changes the vCPU to be interrupted
|
||||
in the guest, or if the vPCI device is removed from
|
||||
the VM while the VM is running. The ongoing operation of the
|
||||
device happens directly between the Linux device driver for
|
||||
the device and the hardware, with VMBus and the VMBus channel
|
||||
playing no role.
|
||||
|
||||
PCI Device Setup
|
||||
----------------
|
||||
PCI device setup follows a sequence that Hyper-V originally
|
||||
created for Windows guests, and that can be ill-suited for
|
||||
Linux guests due to differences in the overall structure of
|
||||
the Linux PCI subsystem compared with Windows. Nonetheless,
|
||||
with a bit of hackery in the Hyper-V virtual PCI driver for
|
||||
Linux, the virtual PCI device is setup in Linux so that
|
||||
generic Linux PCI subsystem code and the Linux driver for the
|
||||
device "just work".
|
||||
|
||||
Each vPCI device is set up in Linux to be in its own PCI
|
||||
domain with a host bridge. The PCI domainID is derived from
|
||||
bytes 4 and 5 of the instance GUID assigned to the VMBus vPCI
|
||||
device. The Hyper-V host does not guarantee that these bytes
|
||||
are unique, so hv_pci_probe() has an algorithm to resolve
|
||||
collisions. The collision resolution is intended to be stable
|
||||
across reboots of the same VM so that the PCI domainIDs don't
|
||||
change, as the domainID appears in the user space
|
||||
configuration of some devices.
|
||||
|
||||
hv_pci_probe() allocates a guest MMIO range to be used as PCI
|
||||
config space for the device. This MMIO range is communicated
|
||||
to the Hyper-V host over the VMBus channel as part of telling
|
||||
the host that the device is ready to enter d0. See
|
||||
hv_pci_enter_d0(). When the guest subsequently accesses this
|
||||
MMIO range, the Hyper-V host intercepts the accesses and maps
|
||||
them to the physical device PCI config space.
|
||||
|
||||
hv_pci_probe() also gets BAR information for the device from
|
||||
the Hyper-V host, and uses this information to allocate MMIO
|
||||
space for the BARs. That MMIO space is then setup to be
|
||||
associated with the host bridge so that it works when generic
|
||||
PCI subsystem code in Linux processes the BARs.
|
||||
|
||||
Finally, hv_pci_probe() creates the root PCI bus. At this
|
||||
point the Hyper-V virtual PCI driver hackery is done, and the
|
||||
normal Linux PCI machinery for scanning the root bus works to
|
||||
detect the device, to perform driver matching, and to
|
||||
initialize the driver and device.
|
||||
|
||||
PCI Device Removal
|
||||
------------------
|
||||
A Hyper-V host may initiate removal of a vPCI device from a
|
||||
guest VM at any time during the life of the VM. The removal
|
||||
is instigated by an admin action taken on the Hyper-V host and
|
||||
is not under the control of the guest OS.
|
||||
|
||||
A guest VM is notified of the removal by an unsolicited
|
||||
"Eject" message sent from the host to the guest over the VMBus
|
||||
channel associated with the vPCI device. Upon receipt of such
|
||||
a message, the Hyper-V virtual PCI driver in Linux
|
||||
asynchronously invokes Linux kernel PCI subsystem calls to
|
||||
shutdown and remove the device. When those calls are
|
||||
complete, an "Ejection Complete" message is sent back to
|
||||
Hyper-V over the VMBus channel indicating that the device has
|
||||
been removed. At this point, Hyper-V sends a VMBus rescind
|
||||
message to the Linux guest, which the VMBus driver in Linux
|
||||
processes by removing the VMBus identity for the device. Once
|
||||
that processing is complete, all vestiges of the device having
|
||||
been present are gone from the Linux kernel. The rescind
|
||||
message also indicates to the guest that Hyper-V has stopped
|
||||
providing support for the vPCI device in the guest. If the
|
||||
guest were to attempt to access that device's MMIO space, it
|
||||
would be an invalid reference. Hypercalls affecting the device
|
||||
return errors, and any further messages sent in the VMBus
|
||||
channel are ignored.
|
||||
|
||||
After sending the Eject message, Hyper-V allows the guest VM
|
||||
60 seconds to cleanly shutdown the device and respond with
|
||||
Ejection Complete before sending the VMBus rescind
|
||||
message. If for any reason the Eject steps don't complete
|
||||
within the allowed 60 seconds, the Hyper-V host forcibly
|
||||
performs the rescind steps, which will likely result in
|
||||
cascading errors in the guest because the device is now no
|
||||
longer present from the guest standpoint and accessing the
|
||||
device MMIO space will fail.
|
||||
|
||||
Because ejection is asynchronous and can happen at any point
|
||||
during the guest VM lifecycle, proper synchronization in the
|
||||
Hyper-V virtual PCI driver is very tricky. Ejection has been
|
||||
observed even before a newly offered vPCI device has been
|
||||
fully setup. The Hyper-V virtual PCI driver has been updated
|
||||
several times over the years to fix race conditions when
|
||||
ejections happen at inopportune times. Care must be taken when
|
||||
modifying this code to prevent re-introducing such problems.
|
||||
See comments in the code.
|
||||
|
||||
Interrupt Assignment
|
||||
--------------------
|
||||
The Hyper-V virtual PCI driver supports vPCI devices using
|
||||
MSI, multi-MSI, or MSI-X. Assigning the guest vCPU that will
|
||||
receive the interrupt for a particular MSI or MSI-X message is
|
||||
complex because of the way the Linux setup of IRQs maps onto
|
||||
the Hyper-V interfaces. For the single-MSI and MSI-X cases,
|
||||
Linux calls hv_compse_msi_msg() twice, with the first call
|
||||
containing a dummy vCPU and the second call containing the
|
||||
real vCPU. Furthermore, hv_irq_unmask() is finally called
|
||||
(on x86) or the GICD registers are set (on arm64) to specify
|
||||
the real vCPU again. Each of these three calls interact
|
||||
with Hyper-V, which must decide which physical CPU should
|
||||
receive the interrupt before it is forwarded to the guest VM.
|
||||
Unfortunately, the Hyper-V decision-making process is a bit
|
||||
limited, and can result in concentrating the physical
|
||||
interrupts on a single CPU, causing a performance bottleneck.
|
||||
See details about how this is resolved in the extensive
|
||||
comment above the function hv_compose_msi_req_get_cpu().
|
||||
|
||||
The Hyper-V virtual PCI driver implements the
|
||||
irq_chip.irq_compose_msi_msg function as hv_compose_msi_msg().
|
||||
Unfortunately, on Hyper-V the implementation requires sending
|
||||
a VMBus message to the Hyper-V host and awaiting an interrupt
|
||||
indicating receipt of a reply message. Since
|
||||
irq_chip.irq_compose_msi_msg can be called with IRQ locks
|
||||
held, it doesn't work to do the normal sleep until awakened by
|
||||
the interrupt. Instead hv_compose_msi_msg() must send the
|
||||
VMBus message, and then poll for the completion message. As
|
||||
further complexity, the vPCI device could be ejected/rescinded
|
||||
while the polling is in progress, so this scenario must be
|
||||
detected as well. See comments in the code regarding this
|
||||
very tricky area.
|
||||
|
||||
Most of the code in the Hyper-V virtual PCI driver (pci-
|
||||
hyperv.c) applies to Hyper-V and Linux guests running on x86
|
||||
and on arm64 architectures. But there are differences in how
|
||||
interrupt assignments are managed. On x86, the Hyper-V
|
||||
virtual PCI driver in the guest must make a hypercall to tell
|
||||
Hyper-V which guest vCPU should be interrupted by each
|
||||
MSI/MSI-X interrupt, and the x86 interrupt vector number that
|
||||
the x86_vector IRQ domain has picked for the interrupt. This
|
||||
hypercall is made by hv_arch_irq_unmask(). On arm64, the
|
||||
Hyper-V virtual PCI driver manages the allocation of an SPI
|
||||
for each MSI/MSI-X interrupt. The Hyper-V virtual PCI driver
|
||||
stores the allocated SPI in the architectural GICD registers,
|
||||
which Hyper-V emulates, so no hypercall is necessary as with
|
||||
x86. Hyper-V does not support using LPIs for vPCI devices in
|
||||
arm64 guest VMs because it does not emulate a GICv3 ITS.
|
||||
|
||||
The Hyper-V virtual PCI driver in Linux supports vPCI devices
|
||||
whose drivers create managed or unmanaged Linux IRQs. If the
|
||||
smp_affinity for an unmanaged IRQ is updated via the /proc/irq
|
||||
interface, the Hyper-V virtual PCI driver is called to tell
|
||||
the Hyper-V host to change the interrupt targeting and
|
||||
everything works properly. However, on x86 if the x86_vector
|
||||
IRQ domain needs to reassign an interrupt vector due to
|
||||
running out of vectors on a CPU, there's no path to inform the
|
||||
Hyper-V host of the change, and things break. Fortunately,
|
||||
guest VMs operate in a constrained device environment where
|
||||
using all the vectors on a CPU doesn't happen. Since such a
|
||||
problem is only a theoretical concern rather than a practical
|
||||
concern, it has been left unaddressed.
|
||||
|
||||
DMA
|
||||
---
|
||||
By default, Hyper-V pins all guest VM memory in the host
|
||||
when the VM is created, and programs the physical IOMMU to
|
||||
allow the VM to have DMA access to all its memory. Hence
|
||||
it is safe to assign PCI devices to the VM, and allow the
|
||||
guest operating system to program the DMA transfers. The
|
||||
physical IOMMU prevents a malicious guest from initiating
|
||||
DMA to memory belonging to the host or to other VMs on the
|
||||
host. From the Linux guest standpoint, such DMA transfers
|
||||
are in "direct" mode since Hyper-V does not provide a virtual
|
||||
IOMMU in the guest.
|
||||
|
||||
Hyper-V assumes that physical PCI devices always perform
|
||||
cache-coherent DMA. When running on x86, this behavior is
|
||||
required by the architecture. When running on arm64, the
|
||||
architecture allows for both cache-coherent and
|
||||
non-cache-coherent devices, with the behavior of each device
|
||||
specified in the ACPI DSDT. But when a PCI device is assigned
|
||||
to a guest VM, that device does not appear in the DSDT, so the
|
||||
Hyper-V VMBus driver propagates cache-coherency information
|
||||
from the VMBus node in the ACPI DSDT to all VMBus devices,
|
||||
including vPCI devices (since they have a dual identity as a VMBus
|
||||
device and as a PCI device). See vmbus_dma_configure().
|
||||
Current Hyper-V versions always indicate that the VMBus is
|
||||
cache coherent, so vPCI devices on arm64 always get marked as
|
||||
cache coherent and the CPU does not perform any sync
|
||||
operations as part of dma_map/unmap_*() calls.
|
||||
|
||||
vPCI protocol versions
|
||||
----------------------
|
||||
As previously described, during vPCI device setup and teardown
|
||||
messages are passed over a VMBus channel between the Hyper-V
|
||||
host and the Hyper-v vPCI driver in the Linux guest. Some
|
||||
messages have been revised in newer versions of Hyper-V, so
|
||||
the guest and host must agree on the vPCI protocol version to
|
||||
be used. The version is negotiated when communication over
|
||||
the VMBus channel is first established. See
|
||||
hv_pci_protocol_negotiation(). Newer versions of the protocol
|
||||
extend support to VMs with more than 64 vCPUs, and provide
|
||||
additional information about the vPCI device, such as the
|
||||
guest virtual NUMA node to which it is most closely affined in
|
||||
the underlying hardware.
|
||||
|
||||
Guest NUMA node affinity
|
||||
------------------------
|
||||
When the vPCI protocol version provides it, the guest NUMA
|
||||
node affinity of the vPCI device is stored as part of the Linux
|
||||
device information for subsequent use by the Linux driver. See
|
||||
hv_pci_assign_numa_node(). If the negotiated protocol version
|
||||
does not support the host providing NUMA affinity information,
|
||||
the Linux guest defaults the device NUMA node to 0. But even
|
||||
when the negotiated protocol version includes NUMA affinity
|
||||
information, the ability of the host to provide such
|
||||
information depends on certain host configuration options. If
|
||||
the guest receives NUMA node value "0", it could mean NUMA
|
||||
node 0, or it could mean "no information is available".
|
||||
Unfortunately it is not possible to distinguish the two cases
|
||||
from the guest side.
|
||||
|
||||
PCI config space access in a CoCo VM
|
||||
------------------------------------
|
||||
Linux PCI device drivers access PCI config space using a
|
||||
standard set of functions provided by the Linux PCI subsystem.
|
||||
In Hyper-V guests these standard functions map to functions
|
||||
hv_pcifront_read_config() and hv_pcifront_write_config()
|
||||
in the Hyper-V virtual PCI driver. In normal VMs,
|
||||
these hv_pcifront_*() functions directly access the PCI config
|
||||
space, and the accesses trap to Hyper-V to be handled.
|
||||
But in CoCo VMs, memory encryption prevents Hyper-V
|
||||
from reading the guest instruction stream to emulate the
|
||||
access, so the hv_pcifront_*() functions must invoke
|
||||
hypercalls with explicit arguments describing the access to be
|
||||
made.
|
||||
|
||||
Config Block back-channel
|
||||
-------------------------
|
||||
The Hyper-V host and Hyper-V virtual PCI driver in Linux
|
||||
together implement a non-standard back-channel communication
|
||||
path between the host and guest. The back-channel path uses
|
||||
messages sent over the VMBus channel associated with the vPCI
|
||||
device. The functions hyperv_read_cfg_blk() and
|
||||
hyperv_write_cfg_blk() are the primary interfaces provided to
|
||||
other parts of the Linux kernel. As of this writing, these
|
||||
interfaces are used only by the Mellanox mlx5 driver to pass
|
||||
diagnostic data to a Hyper-V host running in the Azure public
|
||||
cloud. The functions hyperv_read_cfg_blk() and
|
||||
hyperv_write_cfg_blk() are implemented in a separate module
|
||||
(pci-hyperv-intf.c, under CONFIG_PCI_HYPERV_INTERFACE) that
|
||||
effectively stubs them out when running in non-Hyper-V
|
||||
environments.
|
|
@ -8791,6 +8791,11 @@ means the VM type with value @n is supported. Possible values of @n are::
|
|||
#define KVM_X86_DEFAULT_VM 0
|
||||
#define KVM_X86_SW_PROTECTED_VM 1
|
||||
|
||||
Note, KVM_X86_SW_PROTECTED_VM is currently only for development and testing.
|
||||
Do not use KVM_X86_SW_PROTECTED_VM for "real" VMs, and especially not in
|
||||
production. The behavior and effective ABI for software-protected VMs is
|
||||
unstable.
|
||||
|
||||
9. Known KVM API problems
|
||||
=========================
|
||||
|
||||
|
|
115
MAINTAINERS
115
MAINTAINERS
|
@ -1395,6 +1395,7 @@ F: drivers/hwmon/max31760.c
|
|||
|
||||
ANALOGBITS PLL LIBRARIES
|
||||
M: Paul Walmsley <paul.walmsley@sifive.com>
|
||||
M: Samuel Holland <samuel.holland@sifive.com>
|
||||
S: Supported
|
||||
F: drivers/clk/analogbits/*
|
||||
F: include/linux/clk/analogbits*
|
||||
|
@ -2156,7 +2157,7 @@ M: Shawn Guo <shawnguo@kernel.org>
|
|||
M: Sascha Hauer <s.hauer@pengutronix.de>
|
||||
R: Pengutronix Kernel Team <kernel@pengutronix.de>
|
||||
R: Fabio Estevam <festevam@gmail.com>
|
||||
R: NXP Linux Team <linux-imx@nxp.com>
|
||||
L: imx@lists.linux.dev
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
|
||||
|
@ -4169,14 +4170,14 @@ F: drivers/firmware/broadcom/tee_bnxt_fw.c
|
|||
F: drivers/net/ethernet/broadcom/bnxt/
|
||||
F: include/linux/firmware/broadcom/tee_bnxt_fw.h
|
||||
|
||||
BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
|
||||
M: Arend van Spriel <aspriel@gmail.com>
|
||||
M: Franky Lin <franky.lin@broadcom.com>
|
||||
M: Hante Meuleman <hante.meuleman@broadcom.com>
|
||||
BROADCOM BRCM80211 IEEE802.11 WIRELESS DRIVERS
|
||||
M: Arend van Spriel <arend.vanspriel@broadcom.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: brcm80211@lists.linux.dev
|
||||
L: brcm80211-dev-list.pdl@broadcom.com
|
||||
S: Supported
|
||||
F: drivers/net/wireless/broadcom/brcm80211/
|
||||
F: include/linux/platform_data/brcmfmac.h
|
||||
|
||||
BROADCOM BRCMSTB GPIO DRIVER
|
||||
M: Doug Berger <opendmb@gmail.com>
|
||||
|
@ -5378,7 +5379,7 @@ CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)
|
|||
M: Johannes Weiner <hannes@cmpxchg.org>
|
||||
M: Michal Hocko <mhocko@kernel.org>
|
||||
M: Roman Gushchin <roman.gushchin@linux.dev>
|
||||
M: Shakeel Butt <shakeelb@google.com>
|
||||
M: Shakeel Butt <shakeel.butt@linux.dev>
|
||||
R: Muchun Song <muchun.song@linux.dev>
|
||||
L: cgroups@vger.kernel.org
|
||||
L: linux-mm@kvack.org
|
||||
|
@ -5610,6 +5611,11 @@ S: Maintained
|
|||
F: Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml
|
||||
F: drivers/net/can/ctucanfd/
|
||||
|
||||
CVE ASSIGNMENT CONTACT
|
||||
M: CVE Assignment Team <cve@kernel.org>
|
||||
S: Maintained
|
||||
F: Documentation/process/cve.rst
|
||||
|
||||
CW1200 WLAN driver
|
||||
S: Orphan
|
||||
F: drivers/net/wireless/st/cw1200/
|
||||
|
@ -8490,7 +8496,7 @@ FREESCALE IMX / MXC FEC DRIVER
|
|||
M: Wei Fang <wei.fang@nxp.com>
|
||||
R: Shenwei Wang <shenwei.wang@nxp.com>
|
||||
R: Clark Wang <xiaoning.wang@nxp.com>
|
||||
R: NXP Linux Team <linux-imx@nxp.com>
|
||||
L: imx@lists.linux.dev
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/net/fsl,fec.yaml
|
||||
|
@ -8525,7 +8531,7 @@ F: drivers/i2c/busses/i2c-imx.c
|
|||
FREESCALE IMX LPI2C DRIVER
|
||||
M: Dong Aisheng <aisheng.dong@nxp.com>
|
||||
L: linux-i2c@vger.kernel.org
|
||||
L: linux-imx@nxp.com
|
||||
L: imx@lists.linux.dev
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
|
||||
F: drivers/i2c/busses/i2c-imx-lpi2c.c
|
||||
|
@ -10729,7 +10735,7 @@ INTEL DRM I915 DRIVER (Meteor Lake, DG2 and older excluding Poulsbo, Moorestown
|
|||
M: Jani Nikula <jani.nikula@linux.intel.com>
|
||||
M: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
||||
M: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
||||
M: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
|
||||
M: Tvrtko Ursulin <tursulin@ursulin.net>
|
||||
L: intel-gfx@lists.freedesktop.org
|
||||
S: Supported
|
||||
W: https://drm.pages.freedesktop.org/intel-docs/
|
||||
|
@ -10801,11 +10807,11 @@ F: drivers/gpio/gpio-tangier.h
|
|||
|
||||
INTEL GVT-g DRIVERS (Intel GPU Virtualization)
|
||||
M: Zhenyu Wang <zhenyuw@linux.intel.com>
|
||||
M: Zhi Wang <zhi.a.wang@intel.com>
|
||||
M: Zhi Wang <zhi.wang.linux@gmail.com>
|
||||
L: intel-gvt-dev@lists.freedesktop.org
|
||||
L: intel-gfx@lists.freedesktop.org
|
||||
S: Supported
|
||||
W: https://01.org/igvt-g
|
||||
W: https://github.com/intel/gvt-linux/wiki
|
||||
T: git https://github.com/intel/gvt-linux.git
|
||||
F: drivers/gpu/drm/i915/gvt/
|
||||
|
||||
|
@ -11127,7 +11133,6 @@ S: Supported
|
|||
F: drivers/net/wireless/intel/iwlegacy/
|
||||
|
||||
INTEL WIRELESS WIFI LINK (iwlwifi)
|
||||
M: Gregory Greenman <gregory.greenman@intel.com>
|
||||
M: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Supported
|
||||
|
@ -14107,6 +14112,17 @@ F: mm/
|
|||
F: tools/mm/
|
||||
F: tools/testing/selftests/mm/
|
||||
|
||||
MEMORY MAPPING
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
R: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
R: Vlastimil Babka <vbabka@suse.cz>
|
||||
R: Lorenzo Stoakes <lstoakes@gmail.com>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
W: http://www.linux-mm.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
|
||||
F: mm/mmap.c
|
||||
|
||||
MEMORY TECHNOLOGY DEVICES (MTD)
|
||||
M: Miquel Raynal <miquel.raynal@bootlin.com>
|
||||
M: Richard Weinberger <richard@nod.at>
|
||||
|
@ -14365,7 +14381,7 @@ MICROCHIP MCP16502 PMIC DRIVER
|
|||
M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
|
||||
F: Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml
|
||||
F: drivers/regulator/mcp16502.c
|
||||
|
||||
MICROCHIP MCP3564 ADC DRIVER
|
||||
|
@ -15238,6 +15254,8 @@ F: Documentation/networking/
|
|||
F: Documentation/networking/net_cachelines/
|
||||
F: Documentation/process/maintainer-netdev.rst
|
||||
F: Documentation/userspace-api/netlink/
|
||||
F: include/linux/framer/framer-provider.h
|
||||
F: include/linux/framer/framer.h
|
||||
F: include/linux/in.h
|
||||
F: include/linux/indirect_call_wrapper.h
|
||||
F: include/linux/net.h
|
||||
|
@ -15325,7 +15343,7 @@ K: \bmdo_
|
|||
NETWORKING [MPTCP]
|
||||
M: Matthieu Baerts <matttbe@kernel.org>
|
||||
M: Mat Martineau <martineau@kernel.org>
|
||||
R: Geliang Tang <geliang.tang@linux.dev>
|
||||
R: Geliang Tang <geliang@kernel.org>
|
||||
L: netdev@vger.kernel.org
|
||||
L: mptcp@lists.linux.dev
|
||||
S: Maintained
|
||||
|
@ -15710,7 +15728,7 @@ F: drivers/iio/gyro/fxas21002c_spi.c
|
|||
NXP i.MX 7D/6SX/6UL/93 AND VF610 ADC DRIVER
|
||||
M: Haibo Chen <haibo.chen@nxp.com>
|
||||
L: linux-iio@vger.kernel.org
|
||||
L: linux-imx@nxp.com
|
||||
L: imx@lists.linux.dev
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/iio/adc/fsl,imx7d-adc.yaml
|
||||
F: Documentation/devicetree/bindings/iio/adc/fsl,vf610-adc.yaml
|
||||
|
@ -15747,7 +15765,7 @@ F: drivers/gpu/drm/imx/dcss/
|
|||
NXP i.MX 8QXP ADC DRIVER
|
||||
M: Cai Huoqing <cai.huoqing@linux.dev>
|
||||
M: Haibo Chen <haibo.chen@nxp.com>
|
||||
L: linux-imx@nxp.com
|
||||
L: imx@lists.linux.dev
|
||||
L: linux-iio@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml
|
||||
|
@ -15755,7 +15773,7 @@ F: drivers/iio/adc/imx8qxp-adc.c
|
|||
|
||||
NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER
|
||||
M: Mirela Rabulea <mirela.rabulea@nxp.com>
|
||||
R: NXP Linux Team <linux-imx@nxp.com>
|
||||
L: imx@lists.linux.dev
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
|
||||
|
@ -15765,7 +15783,7 @@ NXP i.MX CLOCK DRIVERS
|
|||
M: Abel Vesa <abelvesa@kernel.org>
|
||||
R: Peng Fan <peng.fan@nxp.com>
|
||||
L: linux-clk@vger.kernel.org
|
||||
L: linux-imx@nxp.com
|
||||
L: imx@lists.linux.dev
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/abelvesa/linux.git clk/imx
|
||||
F: Documentation/devicetree/bindings/clock/imx*
|
||||
|
@ -16726,6 +16744,7 @@ F: drivers/pci/controller/dwc/*layerscape*
|
|||
PCI DRIVER FOR FU740
|
||||
M: Paul Walmsley <paul.walmsley@sifive.com>
|
||||
M: Greentime Hu <greentime.hu@sifive.com>
|
||||
M: Samuel Holland <samuel.holland@sifive.com>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml
|
||||
|
@ -16838,6 +16857,7 @@ F: drivers/pci/controller/dwc/*designware*
|
|||
|
||||
PCI DRIVER FOR TI DRA7XX/J721E
|
||||
M: Vignesh Raghavendra <vigneshr@ti.com>
|
||||
R: Siddharth Vadapalli <s-vadapalli@ti.com>
|
||||
L: linux-omap@vger.kernel.org
|
||||
L: linux-pci@vger.kernel.org
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
|
@ -17183,7 +17203,7 @@ R: John Garry <john.g.garry@oracle.com>
|
|||
R: Will Deacon <will@kernel.org>
|
||||
R: James Clark <james.clark@arm.com>
|
||||
R: Mike Leach <mike.leach@linaro.org>
|
||||
R: Leo Yan <leo.yan@linaro.org>
|
||||
R: Leo Yan <leo.yan@linux.dev>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
F: tools/build/feature/test-libopencsd.c
|
||||
|
@ -17977,33 +17997,34 @@ F: drivers/media/tuners/qt1010*
|
|||
|
||||
QUALCOMM ATH12K WIRELESS DRIVER
|
||||
M: Kalle Valo <kvalo@kernel.org>
|
||||
M: Jeff Johnson <quic_jjohnson@quicinc.com>
|
||||
M: Jeff Johnson <jjohnson@kernel.org>
|
||||
L: ath12k@lists.infradead.org
|
||||
S: Supported
|
||||
W: https://wireless.wiki.kernel.org/en/users/Drivers/ath12k
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
|
||||
F: drivers/net/wireless/ath/ath12k/
|
||||
N: ath12k
|
||||
|
||||
QUALCOMM ATHEROS ATH10K WIRELESS DRIVER
|
||||
M: Kalle Valo <kvalo@kernel.org>
|
||||
M: Jeff Johnson <quic_jjohnson@quicinc.com>
|
||||
M: Jeff Johnson <jjohnson@kernel.org>
|
||||
L: ath10k@lists.infradead.org
|
||||
S: Supported
|
||||
W: https://wireless.wiki.kernel.org/en/users/Drivers/ath10k
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
|
||||
F: Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
|
||||
F: drivers/net/wireless/ath/ath10k/
|
||||
N: ath10k
|
||||
|
||||
QUALCOMM ATHEROS ATH11K WIRELESS DRIVER
|
||||
M: Kalle Valo <kvalo@kernel.org>
|
||||
M: Jeff Johnson <quic_jjohnson@quicinc.com>
|
||||
M: Jeff Johnson <jjohnson@kernel.org>
|
||||
L: ath11k@lists.infradead.org
|
||||
S: Supported
|
||||
W: https://wireless.wiki.kernel.org/en/users/Drivers/ath11k
|
||||
B: https://wireless.wiki.kernel.org/en/users/Drivers/ath11k/bugreport
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
|
||||
F: Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
|
||||
F: drivers/net/wireless/ath/ath11k/
|
||||
N: ath11k
|
||||
|
||||
QUALCOMM ATHEROS ATH9K WIRELESS DRIVER
|
||||
M: Toke Høiland-Jørgensen <toke@toke.dk>
|
||||
|
@ -18432,7 +18453,7 @@ S: Supported
|
|||
F: drivers/infiniband/sw/rdmavt
|
||||
|
||||
RDS - RELIABLE DATAGRAM SOCKETS
|
||||
M: Santosh Shilimkar <santosh.shilimkar@oracle.com>
|
||||
M: Allison Henderson <allison.henderson@oracle.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: linux-rdma@vger.kernel.org
|
||||
L: rds-devel@oss.oracle.com (moderated for non-subscribers)
|
||||
|
@ -19634,7 +19655,7 @@ F: drivers/mmc/host/sdhci-of-at91.c
|
|||
|
||||
SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) NXP i.MX DRIVER
|
||||
M: Haibo Chen <haibo.chen@nxp.com>
|
||||
L: linux-imx@nxp.com
|
||||
L: imx@lists.linux.dev
|
||||
L: linux-mmc@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/mmc/host/sdhci-esdhc-imx.c
|
||||
|
@ -19969,35 +19990,14 @@ S: Maintained
|
|||
F: drivers/watchdog/simatic-ipc-wdt.c
|
||||
|
||||
SIFIVE DRIVERS
|
||||
M: Palmer Dabbelt <palmer@dabbelt.com>
|
||||
M: Paul Walmsley <paul.walmsley@sifive.com>
|
||||
M: Samuel Holland <samuel.holland@sifive.com>
|
||||
L: linux-riscv@lists.infradead.org
|
||||
S: Supported
|
||||
N: sifive
|
||||
K: [^@]sifive
|
||||
|
||||
SIFIVE CACHE DRIVER
|
||||
M: Conor Dooley <conor@kernel.org>
|
||||
L: linux-riscv@lists.infradead.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/cache/sifive,ccache0.yaml
|
||||
F: drivers/cache/sifive_ccache.c
|
||||
|
||||
SIFIVE FU540 SYSTEM-ON-CHIP
|
||||
M: Paul Walmsley <paul.walmsley@sifive.com>
|
||||
M: Palmer Dabbelt <palmer@dabbelt.com>
|
||||
L: linux-riscv@lists.infradead.org
|
||||
S: Supported
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/pjw/sifive.git
|
||||
N: fu540
|
||||
K: fu540
|
||||
|
||||
SIFIVE PDMA DRIVER
|
||||
M: Green Wan <green.wan@sifive.com>
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml
|
||||
F: drivers/dma/sf-pdma/
|
||||
|
||||
N: sifive
|
||||
K: fu[57]40
|
||||
K: [^@]sifive
|
||||
|
||||
SILEAD TOUCHSCREEN DRIVER
|
||||
M: Hans de Goede <hdegoede@redhat.com>
|
||||
|
@ -20207,8 +20207,8 @@ F: Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml
|
|||
F: drivers/net/ethernet/socionext/sni_ave.c
|
||||
|
||||
SOCIONEXT (SNI) NETSEC NETWORK DRIVER
|
||||
M: Jassi Brar <jaswinder.singh@linaro.org>
|
||||
M: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
||||
M: Masahisa Kojima <kojima.masahisa@socionext.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/net/socionext,synquacer-netsec.yaml
|
||||
|
@ -22010,6 +22010,14 @@ F: Documentation/devicetree/bindings/media/i2c/ti,ds90*
|
|||
F: drivers/media/i2c/ds90*
|
||||
F: include/media/i2c/ds90*
|
||||
|
||||
TI HDC302X HUMIDITY DRIVER
|
||||
M: Javier Carrasco <javier.carrasco.cruz@gmail.com>
|
||||
M: Li peiyu <579lpy@gmail.com>
|
||||
L: linux-iio@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/iio/humidity/ti,hdc3020.yaml
|
||||
F: drivers/iio/humidity/hdc3020.c
|
||||
|
||||
TI ICSSG ETHERNET DRIVER (ICSSG)
|
||||
R: MD Danish Anwar <danishanwar@ti.com>
|
||||
R: Roger Quadros <rogerq@kernel.org>
|
||||
|
@ -22865,9 +22873,8 @@ S: Maintained
|
|||
F: drivers/usb/typec/mux/pi3usb30532.c
|
||||
|
||||
USB TYPEC PORT CONTROLLER DRIVERS
|
||||
M: Guenter Roeck <linux@roeck-us.net>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
S: Orphan
|
||||
F: drivers/usb/typec/tcpm/
|
||||
|
||||
USB UHCI DRIVER
|
||||
|
|
14
Makefile
14
Makefile
|
@ -2,7 +2,7 @@
|
|||
VERSION = 6
|
||||
PATCHLEVEL = 8
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc3
|
||||
EXTRAVERSION =
|
||||
NAME = Hurr durr I'ma ninja sloth
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
@ -294,15 +294,15 @@ may-sync-config := 1
|
|||
single-build :=
|
||||
|
||||
ifneq ($(filter $(no-dot-config-targets), $(MAKECMDGOALS)),)
|
||||
ifeq ($(filter-out $(no-dot-config-targets), $(MAKECMDGOALS)),)
|
||||
ifeq ($(filter-out $(no-dot-config-targets), $(MAKECMDGOALS)),)
|
||||
need-config :=
|
||||
endif
|
||||
endif
|
||||
endif
|
||||
|
||||
ifneq ($(filter $(no-sync-config-targets), $(MAKECMDGOALS)),)
|
||||
ifeq ($(filter-out $(no-sync-config-targets), $(MAKECMDGOALS)),)
|
||||
ifeq ($(filter-out $(no-sync-config-targets), $(MAKECMDGOALS)),)
|
||||
may-sync-config :=
|
||||
endif
|
||||
endif
|
||||
endif
|
||||
|
||||
need-compiler := $(may-sync-config)
|
||||
|
@ -323,9 +323,9 @@ endif
|
|||
# We cannot build single targets and the others at the same time
|
||||
ifneq ($(filter $(single-targets), $(MAKECMDGOALS)),)
|
||||
single-build := 1
|
||||
ifneq ($(filter-out $(single-targets), $(MAKECMDGOALS)),)
|
||||
ifneq ($(filter-out $(single-targets), $(MAKECMDGOALS)),)
|
||||
mixed-build := 1
|
||||
endif
|
||||
endif
|
||||
endif
|
||||
|
||||
# For "make -j clean all", "make -j mrproper defconfig all", etc.
|
||||
|
|
|
@ -31,7 +31,7 @@
|
|||
static __always_inline bool arch_static_branch(struct static_key *key,
|
||||
bool branch)
|
||||
{
|
||||
asm_volatile_goto(".balign "__stringify(JUMP_LABEL_NOP_SIZE)" \n"
|
||||
asm goto(".balign "__stringify(JUMP_LABEL_NOP_SIZE)" \n"
|
||||
"1: \n"
|
||||
"nop \n"
|
||||
".pushsection __jump_table, \"aw\" \n"
|
||||
|
@ -47,7 +47,7 @@ l_yes:
|
|||
static __always_inline bool arch_static_branch_jump(struct static_key *key,
|
||||
bool branch)
|
||||
{
|
||||
asm_volatile_goto(".balign "__stringify(JUMP_LABEL_NOP_SIZE)" \n"
|
||||
asm goto(".balign "__stringify(JUMP_LABEL_NOP_SIZE)" \n"
|
||||
"1: \n"
|
||||
"b %l[l_yes] \n"
|
||||
".pushsection __jump_table, \"aw\" \n"
|
||||
|
|
|
@ -167,7 +167,6 @@
|
|||
msix: msix@fbe00000 {
|
||||
compatible = "al,alpine-msix";
|
||||
reg = <0x0 0xfbe00000 0x0 0x100000>;
|
||||
interrupt-controller;
|
||||
msi-controller;
|
||||
al,msi-base-spi = <96>;
|
||||
al,msi-num-spis = <64>;
|
||||
|
|
|
@ -466,7 +466,6 @@
|
|||
i2c0: i2c-bus@40 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x40 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
@ -482,7 +481,6 @@
|
|||
i2c1: i2c-bus@80 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x80 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
@ -498,7 +496,6 @@
|
|||
i2c2: i2c-bus@c0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0xc0 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
@ -515,7 +512,6 @@
|
|||
i2c3: i2c-bus@100 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x100 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
@ -532,7 +528,6 @@
|
|||
i2c4: i2c-bus@140 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x140 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
@ -549,7 +544,6 @@
|
|||
i2c5: i2c-bus@180 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x180 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
@ -566,7 +560,6 @@
|
|||
i2c6: i2c-bus@1c0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x1c0 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
@ -583,7 +576,6 @@
|
|||
i2c7: i2c-bus@300 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x300 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
@ -600,7 +592,6 @@
|
|||
i2c8: i2c-bus@340 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x340 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
@ -617,7 +608,6 @@
|
|||
i2c9: i2c-bus@380 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x380 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
@ -634,7 +624,6 @@
|
|||
i2c10: i2c-bus@3c0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x3c0 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
@ -651,7 +640,6 @@
|
|||
i2c11: i2c-bus@400 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x400 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
@ -668,7 +656,6 @@
|
|||
i2c12: i2c-bus@440 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x440 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
@ -685,7 +672,6 @@
|
|||
i2c13: i2c-bus@480 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x480 0x40>;
|
||||
compatible = "aspeed,ast2400-i2c-bus";
|
||||
|
|
|
@ -363,6 +363,7 @@
|
|||
interrupts = <40>;
|
||||
reg = <0x1e780200 0x0100>;
|
||||
clocks = <&syscon ASPEED_CLK_APB>;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
bus-frequency = <12000000>;
|
||||
pinctrl-names = "default";
|
||||
|
@ -594,7 +595,6 @@
|
|||
i2c0: i2c-bus@40 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x40 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
@ -610,7 +610,6 @@
|
|||
i2c1: i2c-bus@80 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x80 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
@ -626,7 +625,6 @@
|
|||
i2c2: i2c-bus@c0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0xc0 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
@ -643,7 +641,6 @@
|
|||
i2c3: i2c-bus@100 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x100 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
@ -660,7 +657,6 @@
|
|||
i2c4: i2c-bus@140 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x140 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
@ -677,7 +673,6 @@
|
|||
i2c5: i2c-bus@180 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x180 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
@ -694,7 +689,6 @@
|
|||
i2c6: i2c-bus@1c0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x1c0 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
@ -711,7 +705,6 @@
|
|||
i2c7: i2c-bus@300 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x300 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
@ -728,7 +721,6 @@
|
|||
i2c8: i2c-bus@340 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x340 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
@ -745,7 +737,6 @@
|
|||
i2c9: i2c-bus@380 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x380 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
@ -762,7 +753,6 @@
|
|||
i2c10: i2c-bus@3c0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x3c0 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
@ -779,7 +769,6 @@
|
|||
i2c11: i2c-bus@400 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x400 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
@ -796,7 +785,6 @@
|
|||
i2c12: i2c-bus@440 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x440 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
@ -813,7 +801,6 @@
|
|||
i2c13: i2c-bus@480 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
reg = <0x480 0x40>;
|
||||
compatible = "aspeed,ast2500-i2c-bus";
|
||||
|
|
|
@ -474,6 +474,7 @@
|
|||
reg = <0x1e780500 0x100>;
|
||||
interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
bus-frequency = <12000000>;
|
||||
pinctrl-names = "default";
|
||||
|
@ -488,6 +489,7 @@
|
|||
reg = <0x1e780600 0x100>;
|
||||
interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
bus-frequency = <12000000>;
|
||||
pinctrl-names = "default";
|
||||
|
@ -902,7 +904,6 @@
|
|||
i2c0: i2c-bus@80 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x80 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -917,7 +918,6 @@
|
|||
i2c1: i2c-bus@100 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x100 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -932,7 +932,6 @@
|
|||
i2c2: i2c-bus@180 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x180 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -947,7 +946,6 @@
|
|||
i2c3: i2c-bus@200 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x200 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -962,7 +960,6 @@
|
|||
i2c4: i2c-bus@280 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x280 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -977,7 +974,6 @@
|
|||
i2c5: i2c-bus@300 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x300 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -992,7 +988,6 @@
|
|||
i2c6: i2c-bus@380 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x380 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -1007,7 +1002,6 @@
|
|||
i2c7: i2c-bus@400 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x400 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -1022,7 +1016,6 @@
|
|||
i2c8: i2c-bus@480 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x480 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -1037,7 +1030,6 @@
|
|||
i2c9: i2c-bus@500 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x500 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -1052,7 +1044,6 @@
|
|||
i2c10: i2c-bus@580 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x580 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -1067,7 +1058,6 @@
|
|||
i2c11: i2c-bus@600 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x600 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -1082,7 +1072,6 @@
|
|||
i2c12: i2c-bus@680 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x680 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -1097,7 +1086,6 @@
|
|||
i2c13: i2c-bus@700 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x700 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -1112,7 +1100,6 @@
|
|||
i2c14: i2c-bus@780 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x780 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
@ -1127,7 +1114,6 @@
|
|||
i2c15: i2c-bus@800 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
reg = <0x800 0x80>;
|
||||
compatible = "aspeed,ast2600-i2c-bus";
|
||||
clocks = <&syscon ASPEED_CLK_APB2>;
|
||||
|
|
|
@ -167,6 +167,7 @@
|
|||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-parent = <&mailbox>;
|
||||
interrupts = <0>;
|
||||
};
|
||||
|
@ -247,6 +248,7 @@
|
|||
gpio-controller;
|
||||
interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
||||
|
||||
i2c1: i2c@1800b000 {
|
||||
|
@ -518,6 +520,7 @@
|
|||
gpio-controller;
|
||||
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
|
||||
gpio-ranges = <&pinctrl 0 42 1>,
|
||||
<&pinctrl 1 44 3>,
|
||||
|
|
|
@ -200,6 +200,7 @@
|
|||
gpio-controller;
|
||||
ngpios = <4>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
||||
|
||||
|
|
|
@ -180,6 +180,7 @@
|
|||
gpio-controller;
|
||||
ngpios = <32>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
|
||||
gpio-ranges = <&pinctrl 0 0 32>;
|
||||
};
|
||||
|
@ -352,6 +353,7 @@
|
|||
gpio-controller;
|
||||
ngpios = <4>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
||||
|
||||
|
|
|
@ -60,6 +60,8 @@
|
|||
* We have slots (IDSEL) 1 and 2 with one assigned IRQ
|
||||
* each handling all IRQs.
|
||||
*/
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-map-mask = <0xf800 0 0 7>;
|
||||
interrupt-map =
|
||||
/* IDSEL 1 */
|
||||
<0x0800 0 0 1 &gpio0 11 IRQ_TYPE_LEVEL_LOW>, /* INT A on slot 1 is irq 11 */
|
||||
|
|
|
@ -89,6 +89,8 @@
|
|||
* The slots have Ethernet, Ethernet, NEC and MPCI.
|
||||
* The IDSELs are 11, 12, 13, 14.
|
||||
*/
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-map-mask = <0xf800 0 0 7>;
|
||||
interrupt-map =
|
||||
/* IDSEL 11 - Ethernet A */
|
||||
<0x5800 0 0 1 &gpio0 4 IRQ_TYPE_LEVEL_LOW>, /* INT A on slot 11 is irq 4 */
|
||||
|
|
|
@ -65,6 +65,7 @@
|
|||
gpio2: gpio-expander@20 {
|
||||
#gpio-cells = <2>;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
compatible = "semtech,sx1505q";
|
||||
reg = <0x20>;
|
||||
|
||||
|
@ -79,6 +80,7 @@
|
|||
gpio3: gpio-expander@21 {
|
||||
#gpio-cells = <2>;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
compatible = "semtech,sx1505q";
|
||||
reg = <0x21>;
|
||||
|
||||
|
|
|
@ -120,6 +120,7 @@
|
|||
interrupts = <2 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<3 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<4 IRQ_TYPE_LEVEL_HIGH>;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
};
|
||||
|
||||
|
@ -128,6 +129,7 @@
|
|||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
};
|
||||
|
||||
|
|
|
@ -997,7 +997,6 @@
|
|||
compatible = "st,stmpe811";
|
||||
reg = <0x41>;
|
||||
irq-gpio = <&gpio TEGRA_GPIO(V, 0) GPIO_ACTIVE_LOW>;
|
||||
interrupt-controller;
|
||||
id = <0>;
|
||||
blocks = <0x5>;
|
||||
irq-trigger = <0x1>;
|
||||
|
|
|
@ -980,7 +980,6 @@
|
|||
compatible = "st,stmpe811";
|
||||
reg = <0x41>;
|
||||
irq-gpio = <&gpio TEGRA_GPIO(V, 0) GPIO_ACTIVE_LOW>;
|
||||
interrupt-controller;
|
||||
id = <0>;
|
||||
blocks = <0x5>;
|
||||
irq-trigger = <0x1>;
|
||||
|
|
|
@ -861,7 +861,6 @@
|
|||
compatible = "st,stmpe811";
|
||||
reg = <0x41>;
|
||||
irq-gpio = <&gpio TEGRA_GPIO(V, 0) GPIO_ACTIVE_LOW>;
|
||||
interrupt-controller;
|
||||
id = <0>;
|
||||
blocks = <0x5>;
|
||||
irq-trigger = <0x1>;
|
||||
|
|
|
@ -227,7 +227,6 @@
|
|||
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
bridge@2,1 {
|
||||
compatible = "pci10b5,8605";
|
||||
|
@ -235,7 +234,6 @@
|
|||
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
/* Intel Corporation I210 Gigabit Network Connection */
|
||||
ethernet@3,0 {
|
||||
|
@ -250,7 +248,6 @@
|
|||
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
#interrupt-cells = <1>;
|
||||
|
||||
/* Intel Corporation I210 Gigabit Network Connection */
|
||||
switch_nic: ethernet@4,0 {
|
||||
|
|
|
@ -245,6 +245,7 @@
|
|||
reg = <0x74>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
interrupt-parent = <&gpio2>;
|
||||
interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
@ -390,7 +391,6 @@
|
|||
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
@ -626,7 +626,6 @@
|
|||
blocks = <0x5>;
|
||||
id = <0>;
|
||||
interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
interrupt-parent = <&gpio4>;
|
||||
irq-trigger = <0x1>;
|
||||
pinctrl-names = "default";
|
||||
|
|
|
@ -550,7 +550,6 @@
|
|||
blocks = <0x5>;
|
||||
interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-parent = <&gpio6>;
|
||||
interrupt-controller;
|
||||
id = <0>;
|
||||
irq-trigger = <0x1>;
|
||||
pinctrl-names = "default";
|
||||
|
|
|
@ -225,7 +225,6 @@
|
|||
pinctrl-0 = <&pinctrl_pmic>;
|
||||
interrupt-parent = <&gpio2>;
|
||||
interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
|
||||
onkey {
|
||||
compatible = "dlg,da9063-onkey";
|
||||
|
|
|
@ -124,6 +124,7 @@
|
|||
reg = <0x58>;
|
||||
interrupt-parent = <&gpio2>;
|
||||
interrupts = <9 IRQ_TYPE_LEVEL_LOW>; /* active-low GPIO2_9 */
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
|
||||
regulators {
|
||||
|
|
|
@ -100,6 +100,7 @@
|
|||
interrupt-parent = <&gpio1>;
|
||||
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
|
||||
|
|
|
@ -63,6 +63,7 @@
|
|||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
reg = <0x25>;
|
||||
};
|
||||
|
||||
|
|
|
@ -834,16 +834,6 @@
|
|||
<&clks IMX7D_LCDIF_PIXEL_ROOT_CLK>;
|
||||
clock-names = "pix", "axi";
|
||||
status = "disabled";
|
||||
|
||||
port {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
lcdif_out_mipi_dsi: endpoint@0 {
|
||||
reg = <0>;
|
||||
remote-endpoint = <&mipi_dsi_in_lcdif>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
mipi_csi: mipi-csi@30750000 {
|
||||
|
@ -895,22 +885,6 @@
|
|||
samsung,esc-clock-frequency = <20000000>;
|
||||
samsung,pll-clock-frequency = <24000000>;
|
||||
status = "disabled";
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
mipi_dsi_in_lcdif: endpoint@0 {
|
||||
reg = <0>;
|
||||
remote-endpoint = <&lcdif_out_mipi_dsi>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
@ -338,6 +338,7 @@
|
|||
reg = <0x22>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
interrupt-parent = <&gpio3>;
|
||||
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
|
|
@ -340,10 +340,10 @@
|
|||
"msi8";
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-map-mask = <0 0 0 0x7>;
|
||||
interrupt-map = <0 0 0 1 &intc 0 0 0 141 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
|
||||
<0 0 0 2 &intc 0 0 0 142 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
|
||||
<0 0 0 3 &intc 0 0 0 143 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
|
||||
<0 0 0 4 &intc 0 0 0 144 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
|
||||
interrupt-map = <0 0 0 1 &intc 0 141 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
|
||||
<0 0 0 2 &intc 0 142 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
|
||||
<0 0 0 3 &intc 0 143 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
|
||||
<0 0 0 4 &intc 0 144 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
|
||||
|
||||
clocks = <&gcc GCC_PCIE_PIPE_CLK>,
|
||||
<&gcc GCC_PCIE_AUX_CLK>,
|
||||
|
|
|
@ -447,6 +447,7 @@
|
|||
interrupt-parent = <&irqc0>;
|
||||
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
rtc {
|
||||
compatible = "dlg,da9063-rtc";
|
||||
|
|
|
@ -347,6 +347,7 @@
|
|||
interrupt-parent = <&irqc0>;
|
||||
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
onkey {
|
||||
compatible = "dlg,da9063-onkey";
|
||||
|
|
|
@ -819,6 +819,7 @@
|
|||
interrupt-parent = <&irqc0>;
|
||||
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
rtc {
|
||||
compatible = "dlg,da9063-rtc";
|
||||
|
|
|
@ -413,6 +413,7 @@
|
|||
interrupt-parent = <&irqc0>;
|
||||
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
watchdog {
|
||||
compatible = "dlg,da9063-watchdog";
|
||||
|
|
|
@ -381,6 +381,7 @@
|
|||
interrupt-parent = <&irqc>;
|
||||
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
rtc {
|
||||
compatible = "dlg,da9063-rtc";
|
||||
|
|
|
@ -759,6 +759,7 @@
|
|||
interrupt-parent = <&irqc0>;
|
||||
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
rtc {
|
||||
compatible = "dlg,da9063-rtc";
|
||||
|
|
|
@ -453,6 +453,7 @@
|
|||
interrupt-parent = <&gpio3>;
|
||||
interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
rtc {
|
||||
compatible = "dlg,da9063-rtc";
|
||||
|
|
|
@ -439,6 +439,7 @@
|
|||
interrupt-parent = <&gpio3>;
|
||||
interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
onkey {
|
||||
compatible = "dlg,da9063-onkey";
|
||||
|
|
|
@ -196,7 +196,6 @@
|
|||
pwm4: pwm@10280000 {
|
||||
compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
|
||||
reg = <0x10280000 0x10>;
|
||||
interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru SCLK_PWM>, <&cru PCLK_PWM>;
|
||||
clock-names = "pwm", "pclk";
|
||||
pinctrl-names = "default";
|
||||
|
@ -208,7 +207,6 @@
|
|||
pwm5: pwm@10280010 {
|
||||
compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
|
||||
reg = <0x10280010 0x10>;
|
||||
interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru SCLK_PWM>, <&cru PCLK_PWM>;
|
||||
clock-names = "pwm", "pclk";
|
||||
pinctrl-names = "default";
|
||||
|
@ -220,7 +218,6 @@
|
|||
pwm6: pwm@10280020 {
|
||||
compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
|
||||
reg = <0x10280020 0x10>;
|
||||
interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru SCLK_PWM>, <&cru PCLK_PWM>;
|
||||
clock-names = "pwm", "pclk";
|
||||
pinctrl-names = "default";
|
||||
|
@ -232,7 +229,6 @@
|
|||
pwm7: pwm@10280030 {
|
||||
compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
|
||||
reg = <0x10280030 0x10>;
|
||||
interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru SCLK_PWM>, <&cru PCLK_PWM>;
|
||||
clock-names = "pwm", "pclk";
|
||||
pinctrl-names = "default";
|
||||
|
@ -386,7 +382,6 @@
|
|||
pwm0: pwm@20040000 {
|
||||
compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
|
||||
reg = <0x20040000 0x10>;
|
||||
interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru SCLK_PWM0_PMU>, <&cru PCLK_PWM0_PMU>;
|
||||
clock-names = "pwm", "pclk";
|
||||
pinctrl-names = "default";
|
||||
|
@ -398,7 +393,6 @@
|
|||
pwm1: pwm@20040010 {
|
||||
compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
|
||||
reg = <0x20040010 0x10>;
|
||||
interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru SCLK_PWM0_PMU>, <&cru PCLK_PWM0_PMU>;
|
||||
clock-names = "pwm", "pclk";
|
||||
pinctrl-names = "default";
|
||||
|
@ -410,7 +404,6 @@
|
|||
pwm2: pwm@20040020 {
|
||||
compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
|
||||
reg = <0x20040020 0x10>;
|
||||
interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru SCLK_PWM0_PMU>, <&cru PCLK_PWM0_PMU>;
|
||||
clock-names = "pwm", "pclk";
|
||||
pinctrl-names = "default";
|
||||
|
@ -422,7 +415,6 @@
|
|||
pwm3: pwm@20040030 {
|
||||
compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
|
||||
reg = <0x20040030 0x10>;
|
||||
interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru SCLK_PWM0_PMU>, <&cru PCLK_PWM0_PMU>;
|
||||
clock-names = "pwm", "pclk";
|
||||
pinctrl-names = "default";
|
||||
|
|
|
@ -222,7 +222,6 @@
|
|||
reg = <0x42>;
|
||||
interrupts = <8 3>;
|
||||
interrupt-parent = <&gpioi>;
|
||||
interrupt-controller;
|
||||
wakeup-source;
|
||||
|
||||
stmpegpio: stmpe_gpio {
|
||||
|
|
|
@ -64,7 +64,6 @@
|
|||
reg = <0x38>;
|
||||
interrupts = <2 2>;
|
||||
interrupt-parent = <&gpiof>;
|
||||
interrupt-controller;
|
||||
touchscreen-size-x = <480>;
|
||||
touchscreen-size-y = <800>;
|
||||
status = "okay";
|
||||
|
|
|
@ -415,7 +415,6 @@
|
|||
reg = <0x41>;
|
||||
interrupts = <30 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupt-parent = <&gpio2>;
|
||||
interrupt-controller;
|
||||
id = <0>;
|
||||
blocks = <0x5>;
|
||||
irq-trigger = <0x1>;
|
||||
|
|
|
@ -297,6 +297,7 @@ CONFIG_FB_MODE_HELPERS=y
|
|||
CONFIG_LCD_CLASS_DEVICE=y
|
||||
CONFIG_LCD_L4F00242T03=y
|
||||
CONFIG_LCD_PLATFORM=y
|
||||
CONFIG_BACKLIGHT_CLASS_DEVICE=y
|
||||
CONFIG_BACKLIGHT_PWM=y
|
||||
CONFIG_BACKLIGHT_GPIO=y
|
||||
CONFIG_FRAMEBUFFER_CONSOLE=y
|
||||
|
|
|
@ -11,7 +11,7 @@
|
|||
|
||||
static __always_inline bool arch_static_branch(struct static_key *key, bool branch)
|
||||
{
|
||||
asm_volatile_goto("1:\n\t"
|
||||
asm goto("1:\n\t"
|
||||
WASM(nop) "\n\t"
|
||||
".pushsection __jump_table, \"aw\"\n\t"
|
||||
".word 1b, %l[l_yes], %c0\n\t"
|
||||
|
@ -25,7 +25,7 @@ l_yes:
|
|||
|
||||
static __always_inline bool arch_static_branch_jump(struct static_key *key, bool branch)
|
||||
{
|
||||
asm_volatile_goto("1:\n\t"
|
||||
asm goto("1:\n\t"
|
||||
WASM(b) " %l[l_yes]\n\t"
|
||||
".pushsection __jump_table, \"aw\"\n\t"
|
||||
".word 1b, %l[l_yes], %c0\n\t"
|
||||
|
|
|
@ -339,6 +339,7 @@ static struct gpiod_lookup_table ep93xx_i2c_gpiod_table = {
|
|||
GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
|
||||
GPIO_LOOKUP_IDX("G", 0, NULL, 1,
|
||||
GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
|
||||
{ }
|
||||
},
|
||||
};
|
||||
|
||||
|
|
|
@ -298,6 +298,8 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
|
|||
goto done;
|
||||
}
|
||||
count_vm_vma_lock_event(VMA_LOCK_RETRY);
|
||||
if (fault & VM_FAULT_MAJOR)
|
||||
flags |= FAULT_FLAG_TRIED;
|
||||
|
||||
/* Quick path to respond to signals */
|
||||
if (fault_signal_pending(fault, regs)) {
|
||||
|
|
|
@ -42,5 +42,6 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-cb1-manta.dtb
|
|||
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-bigtreetech-pi.dtb
|
||||
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
|
||||
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
|
||||
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-orangepi-zero2w.dtb
|
||||
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-orangepi-zero3.dtb
|
||||
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h618-transpeed-8k618-t.dtb
|
||||
|
|
|
@ -145,7 +145,6 @@
|
|||
msix: msix@fbe00000 {
|
||||
compatible = "al,alpine-msix";
|
||||
reg = <0x0 0xfbe00000 0x0 0x100000>;
|
||||
interrupt-controller;
|
||||
msi-controller;
|
||||
al,msi-base-spi = <160>;
|
||||
al,msi-num-spis = <160>;
|
||||
|
|
|
@ -355,7 +355,6 @@
|
|||
msix: msix@fbe00000 {
|
||||
compatible = "al,alpine-msix";
|
||||
reg = <0x0 0xfbe00000 0x0 0x100000>;
|
||||
interrupt-controller;
|
||||
msi-controller;
|
||||
al,msi-base-spi = <336>;
|
||||
al,msi-num-spis = <959>;
|
||||
|
|
|
@ -586,6 +586,7 @@
|
|||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
||||
|
||||
|
|
|
@ -450,6 +450,7 @@
|
|||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
|
||||
gpio-ranges = <&pinmux 0 0 16>,
|
||||
<&pinmux 16 71 2>,
|
||||
|
|
|
@ -20,23 +20,41 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1046a-frwy.dtb
|
|||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1046a-qds.dtb
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1046a-rdb.dtb
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1046a-tqmls1046a-mbls10xxa.dtb
|
||||
DTC_FLAGS_fsl-ls1088a-qds := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-qds.dtb
|
||||
DTC_FLAGS_fsl-ls1088a-rdb := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-rdb.dtb
|
||||
DTC_FLAGS_fsl-ls1088a-ten64 := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-ten64.dtb
|
||||
DTC_FLAGS_fsl-ls1088a-tqmls1088a-mbls10xxa := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1088a-tqmls1088a-mbls10xxa.dtb
|
||||
DTC_FLAGS_fsl-ls2080a-qds := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-qds.dtb
|
||||
DTC_FLAGS_fsl-ls2080a-rdb := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
|
||||
DTC_FLAGS_fsl-ls2081a-rdb := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2081a-rdb.dtb
|
||||
DTC_FLAGS_fsl-ls2080a-simu := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
|
||||
DTC_FLAGS_fsl-ls2088a-qds := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
|
||||
DTC_FLAGS_fsl-ls2088a-rdb := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb
|
||||
DTC_FLAGS_fsl-lx2160a-bluebox3 := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-bluebox3.dtb
|
||||
DTC_FLAGS_fsl-lx2160a-bluebox3-rev-a := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-bluebox3-rev-a.dtb
|
||||
DTC_FLAGS_fsl-lx2160a-clearfog-cx := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-clearfog-cx.dtb
|
||||
DTC_FLAGS_fsl-lx2160a-honeycomb := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-honeycomb.dtb
|
||||
DTC_FLAGS_fsl-lx2160a-qds := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-qds.dtb
|
||||
DTC_FLAGS_fsl-lx2160a-rdb := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb
|
||||
DTC_FLAGS_fsl-lx2162a-clearfog := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2162a-clearfog.dtb
|
||||
DTC_FLAGS_fsl-lx2162a-qds := -Wno-interrupt_map
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2162a-qds.dtb
|
||||
|
||||
fsl-ls1028a-qds-13bb-dtbs := fsl-ls1028a-qds.dtb fsl-ls1028a-qds-13bb.dtbo
|
||||
|
@ -53,6 +71,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-qds-85bb.dtb
|
|||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-qds-899b.dtb
|
||||
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-qds-9999.dtb
|
||||
|
||||
DTC_FLAGS_fsl-lx2160a-tqmlx2160a-mblx2160a := -Wno-interrupt_map
|
||||
fsl-lx2160a-tqmlx2160a-mblx2160a-12-11-x-dtbs := fsl-lx2160a-tqmlx2160a-mblx2160a.dtb \
|
||||
fsl-lx2160a-tqmlx2160a-mblx2160a_12_x_x.dtbo \
|
||||
fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtbo
|
||||
|
|
|
@ -128,14 +128,9 @@
|
|||
pinctrl-0 = <&pinctrl_ptn5150>;
|
||||
status = "okay";
|
||||
|
||||
connector {
|
||||
compatible = "usb-c-connector";
|
||||
label = "USB-C";
|
||||
|
||||
port {
|
||||
typec1_dr_sw: endpoint {
|
||||
remote-endpoint = <&usb1_drd_sw>;
|
||||
};
|
||||
port {
|
||||
typec1_dr_sw: endpoint {
|
||||
remote-endpoint = <&usb1_drd_sw>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
@ -486,7 +486,7 @@
|
|||
&uart4 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_uart4>;
|
||||
status = "okay";
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
&usb3_phy0 {
|
||||
|
|
|
@ -175,14 +175,10 @@
|
|||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_ptn5150>;
|
||||
|
||||
connector {
|
||||
compatible = "usb-c-connector";
|
||||
label = "USB-C";
|
||||
port {
|
||||
|
||||
port {
|
||||
ptn5150_out_ep: endpoint {
|
||||
remote-endpoint = <&dwc3_0_ep>;
|
||||
};
|
||||
ptn5150_out_ep: endpoint {
|
||||
remote-endpoint = <&dwc3_0_ep>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
@ -255,7 +255,7 @@
|
|||
<&clk IMX8MP_AUDIO_PLL2_OUT>;
|
||||
assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL2_OUT>;
|
||||
assigned-clock-rates = <13000000>, <13000000>, <156000000>;
|
||||
reset-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
|
||||
reset-gpios = <&gpio4 1 GPIO_ACTIVE_HIGH>;
|
||||
status = "disabled";
|
||||
|
||||
ports {
|
||||
|
|
|
@ -184,6 +184,13 @@
|
|||
enable-active-high;
|
||||
};
|
||||
|
||||
reg_vcc_1v8: regulator-1v8 {
|
||||
compatible = "regulator-fixed";
|
||||
regulator-name = "VCC_1V8";
|
||||
regulator-min-microvolt = <1800000>;
|
||||
regulator-max-microvolt = <1800000>;
|
||||
};
|
||||
|
||||
reg_vcc_3v3: regulator-3v3 {
|
||||
compatible = "regulator-fixed";
|
||||
regulator-name = "VCC_3V3";
|
||||
|
@ -480,7 +487,7 @@
|
|||
clock-names = "mclk";
|
||||
clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>;
|
||||
reset-gpios = <&gpio4 29 GPIO_ACTIVE_LOW>;
|
||||
iov-supply = <®_vcc_3v3>;
|
||||
iov-supply = <®_vcc_1v8>;
|
||||
ldoin-supply = <®_vcc_3v3>;
|
||||
};
|
||||
|
||||
|
|
|
@ -1820,7 +1820,7 @@
|
|||
compatible = "fsl,imx8mp-ldb";
|
||||
reg = <0x5c 0x4>, <0x128 0x4>;
|
||||
reg-names = "ldb", "lvds";
|
||||
clocks = <&clk IMX8MP_CLK_MEDIA_LDB>;
|
||||
clocks = <&clk IMX8MP_CLK_MEDIA_LDB_ROOT>;
|
||||
clock-names = "ldb";
|
||||
assigned-clocks = <&clk IMX8MP_CLK_MEDIA_LDB>;
|
||||
assigned-clock-parents = <&clk IMX8MP_VIDEO_PLL1_OUT>;
|
||||
|
|
|
@ -126,7 +126,6 @@
|
|||
amba {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
#interrupt-cells = <3>;
|
||||
|
||||
compatible = "simple-bus";
|
||||
interrupt-parent = <&gic>;
|
||||
|
|
|
@ -126,7 +126,6 @@
|
|||
amba {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
#interrupt-cells = <3>;
|
||||
|
||||
compatible = "simple-bus";
|
||||
interrupt-parent = <&gic>;
|
||||
|
|
|
@ -138,7 +138,6 @@
|
|||
|
||||
odmi: odmi@300000 {
|
||||
compatible = "marvell,odmi-controller";
|
||||
interrupt-controller;
|
||||
msi-controller;
|
||||
marvell,odmi-frames = <4>;
|
||||
reg = <0x300000 0x4000>,
|
||||
|
|
|
@ -128,6 +128,7 @@
|
|||
compatible = "mediatek,mt6360";
|
||||
reg = <0x34>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupts-extended = <&pio 101 IRQ_TYPE_EDGE_FALLING>;
|
||||
interrupt-names = "IRQB";
|
||||
|
||||
|
|
|
@ -175,7 +175,7 @@
|
|||
status = "okay";
|
||||
|
||||
phy-handle = <&mgbe0_phy>;
|
||||
phy-mode = "usxgmii";
|
||||
phy-mode = "10gbase-r";
|
||||
|
||||
mdio {
|
||||
#address-cells = <1>;
|
||||
|
|
|
@ -1459,7 +1459,7 @@
|
|||
<&mc TEGRA234_MEMORY_CLIENT_MGBEAWR &emc>;
|
||||
interconnect-names = "dma-mem", "write";
|
||||
iommus = <&smmu_niso0 TEGRA234_SID_MGBE>;
|
||||
power-domains = <&bpmp TEGRA234_POWER_DOMAIN_MGBEA>;
|
||||
power-domains = <&bpmp TEGRA234_POWER_DOMAIN_MGBEB>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
|
@ -1493,7 +1493,7 @@
|
|||
<&mc TEGRA234_MEMORY_CLIENT_MGBEBWR &emc>;
|
||||
interconnect-names = "dma-mem", "write";
|
||||
iommus = <&smmu_niso0 TEGRA234_SID_MGBE_VF1>;
|
||||
power-domains = <&bpmp TEGRA234_POWER_DOMAIN_MGBEB>;
|
||||
power-domains = <&bpmp TEGRA234_POWER_DOMAIN_MGBEC>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
|
@ -1527,7 +1527,7 @@
|
|||
<&mc TEGRA234_MEMORY_CLIENT_MGBECWR &emc>;
|
||||
interconnect-names = "dma-mem", "write";
|
||||
iommus = <&smmu_niso0 TEGRA234_SID_MGBE_VF2>;
|
||||
power-domains = <&bpmp TEGRA234_POWER_DOMAIN_MGBEC>;
|
||||
power-domains = <&bpmp TEGRA234_POWER_DOMAIN_MGBED>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
|
|
|
@ -830,10 +830,10 @@
|
|||
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-map-mask = <0 0 0 0x7>;
|
||||
interrupt-map = <0 0 0 1 &intc 0 75 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
|
||||
<0 0 0 2 &intc 0 78 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
|
||||
<0 0 0 3 &intc 0 79 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
|
||||
<0 0 0 4 &intc 0 83 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
|
||||
interrupt-map = <0 0 0 1 &intc 0 0 0 75 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
|
||||
<0 0 0 2 &intc 0 0 0 78 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
|
||||
<0 0 0 3 &intc 0 0 0 79 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
|
||||
<0 0 0 4 &intc 0 0 0 83 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
|
||||
|
||||
clocks = <&gcc GCC_SYS_NOC_PCIE0_AXI_CLK>,
|
||||
<&gcc GCC_PCIE0_AXI_M_CLK>,
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user