mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2025-01-01 10:43:43 +00:00
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
Cross merge. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
Jakub Kicinski
commit
621cde16e4
10
.mailmap
10
.mailmap
@ -97,6 +97,11 @@ Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@linaro.org>
|
||||
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@spreadtrum.com>
|
||||
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@unisoc.com>
|
||||
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang7@gmail.com>
|
||||
Barry Song <baohua@kernel.org> <21cnbao@gmail.com>
|
||||
Barry Song <baohua@kernel.org> <v-songbaohua@oppo.com>
|
||||
Barry Song <baohua@kernel.org> <song.bao.hua@hisilicon.com>
|
||||
Barry Song <baohua@kernel.org> <Baohua.Song@csr.com>
|
||||
Barry Song <baohua@kernel.org> <barry.song@analog.com>
|
||||
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@sandisk.com>
|
||||
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
|
||||
Bartosz Golaszewski <brgl@bgdev.pl> <bgolaszewski@baylibre.com>
|
||||
@ -128,6 +133,7 @@ Bryan Tan <bryan-bt.tan@broadcom.com> <bryantan@vmware.com>
|
||||
Cai Huoqing <cai.huoqing@linux.dev> <caihuoqing@baidu.com>
|
||||
Can Guo <quic_cang@quicinc.com> <cang@codeaurora.org>
|
||||
Carl Huang <quic_cjhuang@quicinc.com> <cjhuang@codeaurora.org>
|
||||
Carlos Bilbao <carlos.bilbao.osdev@gmail.com> <carlos.bilbao@amd.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
|
||||
Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
|
||||
@ -304,6 +310,7 @@ Johan Hovold <johan@kernel.org> <jhovold@gmail.com>
|
||||
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 Garry <john.g.garry@oracle.com> <john.garry@huawei.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>
|
||||
@ -461,7 +468,8 @@ Nadia Yvette Chambers <nyc@holomorphy.com> William Lee Irwin III <wli@holomorphy
|
||||
Naoya Horiguchi <nao.horiguchi@gmail.com> <n-horiguchi@ah.jp.nec.com>
|
||||
Naoya Horiguchi <nao.horiguchi@gmail.com> <naoya.horiguchi@nec.com>
|
||||
Nathan Chancellor <nathan@kernel.org> <natechancellor@gmail.com>
|
||||
Neeraj Upadhyay <quic_neeraju@quicinc.com> <neeraju@codeaurora.org>
|
||||
Neeraj Upadhyay <neeraj.upadhyay@kernel.org> <quic_neeraju@quicinc.com>
|
||||
Neeraj Upadhyay <neeraj.upadhyay@kernel.org> <neeraju@codeaurora.org>
|
||||
Neil Armstrong <neil.armstrong@linaro.org> <narmstrong@baylibre.com>
|
||||
Nguyen Anh Quynh <aquynh@gmail.com>
|
||||
Nicholas Piggin <npiggin@gmail.com> <npiggen@suse.de>
|
||||
|
||||
12
Documentation/ABI/removed/sysfs-firmware-efi-vars
Normal file
12
Documentation/ABI/removed/sysfs-firmware-efi-vars
Normal file
@ -0,0 +1,12 @@
|
||||
What: /sys/firmware/efi/vars
|
||||
Date: April 2004, removed March 2023
|
||||
Description:
|
||||
This directory exposed interfaces for interacting with
|
||||
EFI variables. For more information on EFI variables,
|
||||
see 'Variable Services' in the UEFI specification
|
||||
(section 7.2 in specification version 2.3 Errata D).
|
||||
|
||||
The 'efivars' sysfs interface was removed in March of 2023,
|
||||
after being considered deprecated no later than September
|
||||
of 2020. Its functionality has been replaced by the
|
||||
'efivarfs' filesystem.
|
||||
@ -101,6 +101,16 @@ Description:
|
||||
devices that support receiving integrity metadata.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/partscan
|
||||
Date: May 2024
|
||||
Contact: Christoph Hellwig <hch@lst.de>
|
||||
Description:
|
||||
The /sys/block/<disk>/partscan files reports if partition
|
||||
scanning is enabled for the disk. It returns "1" if partition
|
||||
scanning is enabled, or "0" if not. The value type is a 32-bit
|
||||
unsigned integer, but only "0" and "1" are valid values.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/<partition>/alignment_offset
|
||||
Date: April 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
@ -584,18 +594,6 @@ Description:
|
||||
the data. If no such restriction exists, this file will contain
|
||||
'0'. This file is writable for testing purposes.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/throttle_sample_time
|
||||
Date: March 2017
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] This is the time window that blk-throttle samples data, in
|
||||
millisecond. blk-throttle makes decision based on the
|
||||
samplings. Lower time means cgroups have more smooth throughput,
|
||||
but higher CPU overhead. This exists only when
|
||||
CONFIG_BLK_DEV_THROTTLING_LOW is enabled.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/virt_boundary_mask
|
||||
Date: April 2021
|
||||
Contact: linux-block@vger.kernel.org
|
||||
|
||||
@ -1,79 +0,0 @@
|
||||
What: /sys/firmware/efi/vars
|
||||
Date: April 2004
|
||||
Contact: Matt Domsch <Matt_Domsch@dell.com>
|
||||
Description:
|
||||
This directory exposes interfaces for interactive with
|
||||
EFI variables. For more information on EFI variables,
|
||||
see 'Variable Services' in the UEFI specification
|
||||
(section 7.2 in specification version 2.3 Errata D).
|
||||
|
||||
In summary, EFI variables are named, and are classified
|
||||
into separate namespaces through the use of a vendor
|
||||
GUID. They also have an arbitrary binary value
|
||||
associated with them.
|
||||
|
||||
The efivars module enumerates these variables and
|
||||
creates a separate directory for each one found. Each
|
||||
directory has a name of the form "<key>-<vendor guid>"
|
||||
and contains the following files:
|
||||
|
||||
=============== ========================================
|
||||
attributes: A read-only text file enumerating the
|
||||
EFI variable flags. Potential values
|
||||
include:
|
||||
|
||||
EFI_VARIABLE_NON_VOLATILE
|
||||
EFI_VARIABLE_BOOTSERVICE_ACCESS
|
||||
EFI_VARIABLE_RUNTIME_ACCESS
|
||||
EFI_VARIABLE_HARDWARE_ERROR_RECORD
|
||||
EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
|
||||
|
||||
See the EFI documentation for an
|
||||
explanation of each of these variables.
|
||||
|
||||
data: A read-only binary file that can be read
|
||||
to attain the value of the EFI variable
|
||||
|
||||
guid: The vendor GUID of the variable. This
|
||||
should always match the GUID in the
|
||||
variable's name.
|
||||
|
||||
raw_var: A binary file that can be read to obtain
|
||||
a structure that contains everything
|
||||
there is to know about the variable.
|
||||
For structure definition see "struct
|
||||
efi_variable" in the kernel sources.
|
||||
|
||||
This file can also be written to in
|
||||
order to update the value of a variable.
|
||||
For this to work however, all fields of
|
||||
the "struct efi_variable" passed must
|
||||
match byte for byte with the structure
|
||||
read out of the file, save for the value
|
||||
portion.
|
||||
|
||||
**Note** the efi_variable structure
|
||||
read/written with this file contains a
|
||||
'long' type that may change widths
|
||||
depending on your underlying
|
||||
architecture.
|
||||
|
||||
size: As ASCII representation of the size of
|
||||
the variable's value.
|
||||
=============== ========================================
|
||||
|
||||
|
||||
In addition, two other magic binary files are provided
|
||||
in the top-level directory and are used for adding and
|
||||
removing variables:
|
||||
|
||||
=============== ========================================
|
||||
new_var: Takes a "struct efi_variable" and
|
||||
instructs the EFI firmware to create a
|
||||
new variable.
|
||||
|
||||
del_var: Takes a "struct efi_variable" and
|
||||
instructs the EFI firmware to remove any
|
||||
variable that has a matching vendor GUID
|
||||
and variable key name.
|
||||
=============== ========================================
|
||||
@ -28,6 +28,10 @@ BUILDDIR = $(obj)/output
|
||||
PDFLATEX = xelatex
|
||||
LATEXOPTS = -interaction=batchmode -no-shell-escape
|
||||
|
||||
# For denylisting "variable font" files
|
||||
# Can be overridden by setting as an env variable
|
||||
FONTS_CONF_DENY_VF ?= $(HOME)/deny-vf
|
||||
|
||||
ifeq ($(findstring 1, $(KBUILD_VERBOSE)),)
|
||||
SPHINXOPTS += "-q"
|
||||
endif
|
||||
@ -151,10 +155,11 @@ pdfdocs:
|
||||
|
||||
else # HAVE_PDFLATEX
|
||||
|
||||
pdfdocs: DENY_VF = XDG_CONFIG_HOME=$(FONTS_CONF_DENY_VF)
|
||||
pdfdocs: latexdocs
|
||||
@$(srctree)/scripts/sphinx-pre-install --version-check
|
||||
$(foreach var,$(SPHINXDIRS), \
|
||||
$(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit; \
|
||||
$(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" $(DENY_VF) -C $(BUILDDIR)/$(var)/latex || sh $(srctree)/scripts/check-variable-fonts.sh || exit; \
|
||||
mkdir -p $(BUILDDIR)/$(var)/pdf; \
|
||||
mv $(subst .tex,.pdf,$(wildcard $(BUILDDIR)/$(var)/latex/*.tex)) $(BUILDDIR)/$(var)/pdf/; \
|
||||
)
|
||||
|
||||
@ -427,7 +427,7 @@ their assorted primitives.
|
||||
|
||||
This section shows a simple use of the core RCU API to protect a
|
||||
global pointer to a dynamically allocated structure. More-typical
|
||||
uses of RCU may be found in listRCU.rst, arrayRCU.rst, and NMI-RCU.rst.
|
||||
uses of RCU may be found in listRCU.rst and NMI-RCU.rst.
|
||||
::
|
||||
|
||||
struct foo {
|
||||
@ -510,8 +510,8 @@ So, to sum up:
|
||||
data item.
|
||||
|
||||
See checklist.rst for additional rules to follow when using RCU.
|
||||
And again, more-typical uses of RCU may be found in listRCU.rst,
|
||||
arrayRCU.rst, and NMI-RCU.rst.
|
||||
And again, more-typical uses of RCU may be found in listRCU.rst
|
||||
and NMI-RCU.rst.
|
||||
|
||||
.. _4_whatisRCU:
|
||||
|
||||
|
||||
@ -1572,6 +1572,15 @@ PAGE_SIZE multiple when read back.
|
||||
pglazyfreed (npn)
|
||||
Amount of reclaimed lazyfree pages
|
||||
|
||||
zswpin
|
||||
Number of pages moved in to memory from zswap.
|
||||
|
||||
zswpout
|
||||
Number of pages moved out of memory to zswap.
|
||||
|
||||
zswpwb
|
||||
Number of pages written from zswap to swap.
|
||||
|
||||
thp_fault_alloc (npn)
|
||||
Number of transparent hugepages which were allocated to satisfy
|
||||
a page fault. This counter is not present when CONFIG_TRANSPARENT_HUGEPAGE
|
||||
|
||||
@ -113,6 +113,11 @@ same_cpu_crypt
|
||||
The default is to use an unbound workqueue so that encryption work
|
||||
is automatically balanced between available CPUs.
|
||||
|
||||
high_priority
|
||||
Set dm-crypt workqueues and the writer thread to high priority. This
|
||||
improves throughput and latency of dm-crypt while degrading general
|
||||
responsiveness of the system.
|
||||
|
||||
submit_from_crypt_cpus
|
||||
Disable offloading writes to a separate thread after encryption.
|
||||
There are some situations where offloading write bios from the
|
||||
|
||||
@ -67,8 +67,8 @@ arg4:
|
||||
will be performed for all tasks in the task group of ``pid``.
|
||||
|
||||
arg5:
|
||||
userspace pointer to an unsigned long for storing the cookie returned by
|
||||
``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands.
|
||||
userspace pointer to an unsigned long long for storing the cookie returned
|
||||
by ``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands.
|
||||
|
||||
In order for a process to push a cookie to, or pull a cookie from a process, it
|
||||
is required to have the ptrace access mode: `PTRACE_MODE_READ_REALCREDS` to the
|
||||
|
||||
@ -135,7 +135,7 @@ and does not want to suffer the performance impact, one can always
|
||||
disable the mitigation with spec_rstack_overflow=off.
|
||||
|
||||
Similarly, 'Mitigation: IBPB' is another full mitigation type employing
|
||||
an indrect branch prediction barrier after having applied the required
|
||||
an indirect branch prediction barrier after having applied the required
|
||||
microcode patch for one's system. This mitigation comes also at
|
||||
a performance cost.
|
||||
|
||||
|
||||
@ -431,6 +431,9 @@
|
||||
arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards
|
||||
Format: <io>,<irq>,<nodeID>
|
||||
|
||||
arm64.no32bit_el0 [ARM64] Unconditionally disable the execution of
|
||||
32 bit applications.
|
||||
|
||||
arm64.nobti [ARM64] Unconditionally disable Branch Target
|
||||
Identification support
|
||||
|
||||
@ -2251,6 +2254,8 @@
|
||||
no_x2apic_optout
|
||||
BIOS x2APIC opt-out request will be ignored
|
||||
nopost disable Interrupt Posting
|
||||
posted_msi
|
||||
enable MSIs delivered as posted interrupts
|
||||
|
||||
iomem= Disable strict checking of access to MMIO memory
|
||||
strict regions from userspace.
|
||||
@ -4173,13 +4178,11 @@
|
||||
|
||||
page_alloc.shuffle=
|
||||
[KNL] Boolean flag to control whether the page allocator
|
||||
should randomize its free lists. The randomization may
|
||||
be automatically enabled if the kernel detects it is
|
||||
running on a platform with a direct-mapped memory-side
|
||||
cache, and this parameter can be used to
|
||||
override/disable that behavior. The state of the flag
|
||||
can be read from sysfs at:
|
||||
should randomize its free lists. This parameter can be
|
||||
used to enable/disable page randomization. The state of
|
||||
the flag can be read from sysfs at:
|
||||
/sys/module/page_alloc/parameters/shuffle.
|
||||
This parameter is only available if CONFIG_SHUFFLE_PAGE_ALLOCATOR=y.
|
||||
|
||||
page_owner= [KNL,EARLY] Boot-time page_owner enabling option.
|
||||
Storage of the information about who allocated
|
||||
@ -4785,7 +4788,9 @@
|
||||
|
||||
prot_virt= [S390] enable hosting protected virtual machines
|
||||
isolated from the hypervisor (if hardware supports
|
||||
that).
|
||||
that). If enabled, the default kernel base address
|
||||
might be overridden even when Kernel Address Space
|
||||
Layout Randomization is disabled.
|
||||
Format: <bool>
|
||||
|
||||
psi= [KNL] Enable or disable pressure stall information
|
||||
@ -5096,6 +5101,20 @@
|
||||
delay, memory pressure or callback list growing too
|
||||
big.
|
||||
|
||||
rcutree.rcu_normal_wake_from_gp= [KNL]
|
||||
Reduces a latency of synchronize_rcu() call. This approach
|
||||
maintains its own track of synchronize_rcu() callers, so it
|
||||
does not interact with regular callbacks because it does not
|
||||
use a call_rcu[_hurry]() path. Please note, this is for a
|
||||
normal grace period.
|
||||
|
||||
How to enable it:
|
||||
|
||||
echo 1 > /sys/module/rcutree/parameters/rcu_normal_wake_from_gp
|
||||
or pass a boot parameter "rcutree.rcu_normal_wake_from_gp=1"
|
||||
|
||||
Default is 0.
|
||||
|
||||
rcuscale.gp_async= [KNL]
|
||||
Measure performance of asynchronous
|
||||
grace-period primitives such as call_rcu().
|
||||
@ -5812,6 +5831,7 @@
|
||||
but is useful for debugging and performance tuning.
|
||||
|
||||
sched_thermal_decay_shift=
|
||||
[Deprecated]
|
||||
[KNL, SMP] Set a decay shift for scheduler thermal
|
||||
pressure signal. Thermal pressure signal follows the
|
||||
default decay period of other scheduler pelt
|
||||
@ -6749,6 +6769,7 @@
|
||||
- "tpm"
|
||||
- "tee"
|
||||
- "caam"
|
||||
- "dcp"
|
||||
If not specified then it defaults to iterating through
|
||||
the trust source list starting with TPM and assigns the
|
||||
first trust source as a backend which is initialized
|
||||
@ -6764,6 +6785,18 @@
|
||||
If not specified, "default" is used. In this case,
|
||||
the RNG's choice is left to each individual trust source.
|
||||
|
||||
trusted.dcp_use_otp_key
|
||||
This is intended to be used in combination with
|
||||
trusted.source=dcp and will select the DCP OTP key
|
||||
instead of the DCP UNIQUE key blob encryption.
|
||||
|
||||
trusted.dcp_skip_zk_test
|
||||
This is intended to be used in combination with
|
||||
trusted.source=dcp and will disable the check if the
|
||||
blob key is all zeros. This is helpful for situations where
|
||||
having this key zero'ed is acceptable. E.g. in testing
|
||||
scenarios.
|
||||
|
||||
tsc= Disable clocksource stability checks for TSC.
|
||||
Format: <string>
|
||||
[x86] reliable: mark tsc clocksource as reliable, this
|
||||
@ -7324,7 +7357,7 @@
|
||||
This can be changed after boot by writing to the
|
||||
matching /sys/module/workqueue/parameters file. All
|
||||
workqueues with the "default" affinity scope will be
|
||||
updated accordignly.
|
||||
updated accordingly.
|
||||
|
||||
workqueue.debug_force_rr_cpu
|
||||
Workqueue used to implicitly guarantee that work
|
||||
|
||||
@ -308,7 +308,7 @@ limited by the ``advisor_max_cpu`` parameter. In addition there is also the
|
||||
``advisor_target_scan_time`` parameter. This parameter sets the target time to
|
||||
scan all the KSM candidate pages. The parameter ``advisor_target_scan_time``
|
||||
decides how aggressive the scan time advisor scans candidate pages. Lower
|
||||
values make the scan time advisor to scan more aggresively. This is the most
|
||||
values make the scan time advisor to scan more aggressively. This is the most
|
||||
important parameter for the configuration of the scan time advisor.
|
||||
|
||||
The initial value and the maximum value can be changed with
|
||||
|
||||
@ -20,7 +20,6 @@ interrupt, and the PMU driver shall register perf PMU drivers like L3C,
|
||||
HHA and DDRC etc. The available events and configuration options shall
|
||||
be described in the sysfs, see:
|
||||
|
||||
/sys/devices/hisi_sccl{X}_<l3c{Y}/hha{Y}/ddrc{Y}>/, or
|
||||
/sys/bus/event_source/devices/hisi_sccl{X}_<l3c{Y}/hha{Y}/ddrc{Y}>.
|
||||
The "perf list" command shall list the available events from sysfs.
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@ HNS3 PMU driver
|
||||
|
||||
The HNS3 PMU driver registers a perf PMU with the name of its sicl id.::
|
||||
|
||||
/sys/devices/hns3_pmu_sicl_<sicl_id>
|
||||
/sys/bus/event_source/devices/hns3_pmu_sicl_<sicl_id>
|
||||
|
||||
PMU driver provides description of available events, filter modes, format,
|
||||
identifier and cpumask in sysfs.
|
||||
@ -40,9 +40,9 @@ device.
|
||||
|
||||
Example usage of checking event code and subevent code::
|
||||
|
||||
$# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time
|
||||
$# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time
|
||||
config=0x00204
|
||||
$# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num
|
||||
$# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num
|
||||
config=0x10204
|
||||
|
||||
Each performance statistic has a pair of events to get two values to
|
||||
@ -60,7 +60,7 @@ computation to calculate real performance data is:::
|
||||
|
||||
Example usage of checking supported filter mode::
|
||||
|
||||
$# cat /sys/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num
|
||||
$# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num
|
||||
filter mode supported: global/port/port-tc/func/func-queue/
|
||||
|
||||
Example usage of perf::
|
||||
|
||||
@ -10,7 +10,7 @@ There is one logical L2 PMU exposed, which aggregates the results from
|
||||
the physical PMUs.
|
||||
|
||||
The driver provides a description of its available events and configuration
|
||||
options in sysfs, see /sys/devices/l2cache_0.
|
||||
options in sysfs, see /sys/bus/event_source/devices/l2cache_0.
|
||||
|
||||
The "format" directory describes the format of the events.
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ PMU with device name l3cache_<socket>_<instance>. User space is responsible
|
||||
for aggregating across slices.
|
||||
|
||||
The driver provides a description of its available events and configuration
|
||||
options in sysfs, see /sys/devices/l3cache*. Given that these are uncore PMUs
|
||||
options in sysfs, see /sys/bus/event_source/devices/l3cache*. Given that these are uncore PMUs
|
||||
the driver also exposes a "cpumask" sysfs attribute which contains a mask
|
||||
consisting of one CPU per socket which will be used to handle all the PMU
|
||||
events on that socket.
|
||||
|
||||
@ -22,7 +22,7 @@ The thunderx2_pmu driver registers per-socket perf PMUs for the DMC and
|
||||
L3C devices. Each PMU can be used to count up to 4 (DMC/L3C) or up to 8
|
||||
(CCPI2) events simultaneously. The PMUs provide a description of their
|
||||
available events and configuration options under sysfs, see
|
||||
/sys/devices/uncore_<l3c_S/dmc_S/ccpi2_S/>; S is the socket id.
|
||||
/sys/bus/event_source/devices/uncore_<l3c_S/dmc_S/ccpi2_S/>; S is the socket id.
|
||||
|
||||
The driver does not support sampling, therefore "perf record" will not
|
||||
work. Per-task perf sessions are also not supported.
|
||||
|
||||
@ -13,7 +13,7 @@ PMU (perf) driver
|
||||
|
||||
The xgene-pmu driver registers several perf PMU drivers. Each of the perf
|
||||
driver provides description of its available events and configuration options
|
||||
in sysfs, see /sys/devices/<l3cX/iobX/mcbX/mcX>/.
|
||||
in sysfs, see /sys/bus/event_source/devices/<l3cX/iobX/mcbX/mcX>/.
|
||||
|
||||
The "format" directory describes format of the config (event ID),
|
||||
config1 (agent ID) fields of the perf_event_attr structure. The "events"
|
||||
|
||||
@ -42,12 +42,12 @@ The important basics
|
||||
--------------------
|
||||
|
||||
|
||||
What is a "regression" and what is the "no regressions rule"?
|
||||
What is a "regression" and what is the "no regressions" rule?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It's a regression if some application or practical use case running fine with
|
||||
one Linux kernel works worse or not at all with a newer version compiled using a
|
||||
similar configuration. The "no regressions rule" forbids this to take place; if
|
||||
similar configuration. The "no regressions" rule forbids this to take place; if
|
||||
it happens by accident, developers that caused it are expected to quickly fix
|
||||
the issue.
|
||||
|
||||
@ -173,7 +173,7 @@ Additional details about regressions
|
||||
------------------------------------
|
||||
|
||||
|
||||
What is the goal of the "no regressions rule"?
|
||||
What is the goal of the "no regressions" rule?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Users should feel safe when updating kernel versions and not have to worry
|
||||
@ -199,8 +199,8 @@ Exceptions to this rule are extremely rare; in the past developers almost always
|
||||
turned out to be wrong when they assumed a particular situation was warranting
|
||||
an exception.
|
||||
|
||||
Who ensures the "no regressions" is actually followed?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Who ensures the "no regressions" rule is actually followed?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The subsystem maintainers should take care of that, which are watched and
|
||||
supported by the tree maintainers -- e.g. Linus Torvalds for mainline and
|
||||
|
||||
@ -72,6 +72,7 @@ two flavors of JITs, the newer eBPF JIT currently supported on:
|
||||
- riscv64
|
||||
- riscv32
|
||||
- loongarch64
|
||||
- arc
|
||||
|
||||
And the older cBPF JIT supported on the following archs:
|
||||
|
||||
|
||||
@ -173,7 +173,7 @@ When accessing IDE registers with A6=1 (for example $84x),
|
||||
the timing will always be mode 0 8-bit compatible, no matter
|
||||
what you have selected in the speed register:
|
||||
|
||||
781ns select, IOR/IOW after 4 clock cycles (=314ns) aktive.
|
||||
781ns select, IOR/IOW after 4 clock cycles (=314ns) active.
|
||||
|
||||
All the timings with a very short select-signal (the 355ns
|
||||
fast accesses) depend on the accelerator card used in the
|
||||
|
||||
@ -8,6 +8,7 @@ s390 Architecture
|
||||
cds
|
||||
3270
|
||||
driver-model
|
||||
mm
|
||||
monreader
|
||||
qeth
|
||||
s390dbf
|
||||
|
||||
111
Documentation/arch/s390/mm.rst
Normal file
111
Documentation/arch/s390/mm.rst
Normal file
@ -0,0 +1,111 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=================
|
||||
Memory Management
|
||||
=================
|
||||
|
||||
Virtual memory layout
|
||||
=====================
|
||||
|
||||
.. note::
|
||||
|
||||
- Some aspects of the virtual memory layout setup are not
|
||||
clarified (number of page levels, alignment, DMA memory).
|
||||
|
||||
- Unused gaps in the virtual memory layout could be present
|
||||
or not - depending on how partucular system is configured.
|
||||
No page tables are created for the unused gaps.
|
||||
|
||||
- The virtual memory regions are tracked or untracked by KASAN
|
||||
instrumentation, as well as the KASAN shadow memory itself is
|
||||
created only when CONFIG_KASAN configuration option is enabled.
|
||||
|
||||
::
|
||||
|
||||
=============================================================================
|
||||
| Physical | Virtual | VM area description
|
||||
=============================================================================
|
||||
+- 0 --------------+- 0 --------------+
|
||||
| | S390_lowcore | Low-address memory
|
||||
| +- 8 KB -----------+
|
||||
| | |
|
||||
| | |
|
||||
| | ... unused gap | KASAN untracked
|
||||
| | |
|
||||
+- AMODE31_START --+- AMODE31_START --+ .amode31 rand. phys/virt start
|
||||
|.amode31 text/data|.amode31 text/data| KASAN untracked
|
||||
+- AMODE31_END ----+- AMODE31_END ----+ .amode31 rand. phys/virt end (<2GB)
|
||||
| | |
|
||||
| | |
|
||||
+- __kaslr_offset_phys | kernel rand. phys start
|
||||
| | |
|
||||
| kernel text/data | |
|
||||
| | |
|
||||
+------------------+ | kernel phys end
|
||||
| | |
|
||||
| | |
|
||||
| | |
|
||||
| | |
|
||||
+- ident_map_size -+ |
|
||||
| |
|
||||
| ... unused gap | KASAN untracked
|
||||
| |
|
||||
+- __identity_base + identity mapping start (>= 2GB)
|
||||
| |
|
||||
| identity | phys == virt - __identity_base
|
||||
| mapping | virt == phys + __identity_base
|
||||
| |
|
||||
| | KASAN tracked
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
+---- vmemmap -----+ 'struct page' array start
|
||||
| |
|
||||
| virtually mapped |
|
||||
| memory map | KASAN untracked
|
||||
| |
|
||||
+- __abs_lowcore --+
|
||||
| |
|
||||
| Absolute Lowcore | KASAN untracked
|
||||
| |
|
||||
+- __memcpy_real_area
|
||||
| |
|
||||
| Real Memory Copy| KASAN untracked
|
||||
| |
|
||||
+- VMALLOC_START --+ vmalloc area start
|
||||
| | KASAN untracked or
|
||||
| vmalloc area | KASAN shallowly populated in case
|
||||
| | CONFIG_KASAN_VMALLOC=y
|
||||
+- MODULES_VADDR --+ modules area start
|
||||
| | KASAN allocated per module or
|
||||
| modules area | KASAN shallowly populated in case
|
||||
| | CONFIG_KASAN_VMALLOC=y
|
||||
+- __kaslr_offset -+ kernel rand. virt start
|
||||
| | KASAN tracked
|
||||
| kernel text/data | phys == (kvirt - __kaslr_offset) +
|
||||
| | __kaslr_offset_phys
|
||||
+- kernel .bss end + kernel rand. virt end
|
||||
| |
|
||||
| ... unused gap | KASAN untracked
|
||||
| |
|
||||
+------------------+ UltraVisor Secure Storage limit
|
||||
| |
|
||||
| ... unused gap | KASAN untracked
|
||||
| |
|
||||
+KASAN_SHADOW_START+ KASAN shadow memory start
|
||||
| |
|
||||
| KASAN shadow | KASAN untracked
|
||||
| |
|
||||
+------------------+ ASCE limit
|
||||
@ -380,6 +380,36 @@ matrix device.
|
||||
control_domains:
|
||||
A read-only file for displaying the control domain numbers assigned to the
|
||||
vfio_ap mediated device.
|
||||
ap_config:
|
||||
A read/write file that, when written to, allows all three of the
|
||||
vfio_ap mediated device's ap matrix masks to be replaced in one shot.
|
||||
Three masks are given, one for adapters, one for domains, and one for
|
||||
control domains. If the given state cannot be set then no changes are
|
||||
made to the vfio-ap mediated device.
|
||||
|
||||
The format of the data written to ap_config is as follows:
|
||||
{amask},{dmask},{cmask}\n
|
||||
|
||||
\n is a newline character.
|
||||
|
||||
amask, dmask, and cmask are masks identifying which adapters, domains,
|
||||
and control domains should be assigned to the mediated device.
|
||||
|
||||
The format of a mask is as follows:
|
||||
0xNN..NN
|
||||
|
||||
Where NN..NN is 64 hexadecimal characters representing a 256-bit value.
|
||||
The leftmost (highest order) bit represents adapter/domain 0.
|
||||
|
||||
For an example set of masks that represent your mdev's current
|
||||
configuration, simply cat ap_config.
|
||||
|
||||
Setting an adapter or domain number greater than the maximum allowed for
|
||||
the system will result in an error.
|
||||
|
||||
This attribute is intended to be used by automation. End users would be
|
||||
better served using the respective assign/unassign attributes for
|
||||
adapters, domains, and control domains.
|
||||
|
||||
* functions:
|
||||
|
||||
@ -550,7 +580,7 @@ These are the steps:
|
||||
following Kconfig elements selected:
|
||||
* IOMMU_SUPPORT
|
||||
* S390
|
||||
* ZCRYPT
|
||||
* AP
|
||||
* VFIO
|
||||
* KVM
|
||||
|
||||
|
||||
@ -41,7 +41,7 @@ Chapter 36. Coprocessor services
|
||||
submissions until they succeed; waiting for an outstanding CCB to complete is not necessary, and would
|
||||
not be a guarantee that a future submission would succeed.
|
||||
|
||||
The availablility of DAX coprocessor command service is indicated by the presence of the DAX virtual
|
||||
The availability of DAX coprocessor command service is indicated by the presence of the DAX virtual
|
||||
device node in the guest MD (Section 8.24.17, “Database Analytics Accelerators (DAX) virtual-device
|
||||
node”).
|
||||
|
||||
|
||||
@ -446,6 +446,12 @@ during mkdir.
|
||||
max_threshold_occupancy is a user configurable value to determine the
|
||||
occupancy at which an RMID can be freed.
|
||||
|
||||
The mon_llc_occupancy_limbo tracepoint gives the precise occupancy in bytes
|
||||
for a subset of RMID that are not immediately available for allocation.
|
||||
This can't be relied on to produce output every second, it may be necessary
|
||||
to attempt to create an empty monitor group to force an update. Output may
|
||||
only be produced if creation of a control or monitor group fails.
|
||||
|
||||
Schemata files - general concepts
|
||||
---------------------------------
|
||||
Each line in the file describes one resource. The line starts with
|
||||
|
||||
@ -138,7 +138,7 @@ Note this example does not include the sigaltstack preparation.
|
||||
Dynamic features in signal frames
|
||||
---------------------------------
|
||||
|
||||
Dynamcally enabled features are not written to the signal frame upon signal
|
||||
Dynamically enabled features are not written to the signal frame upon signal
|
||||
entry if the feature is in its initial configuration. This differs from
|
||||
non-dynamic features which are always written regardless of their
|
||||
configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV
|
||||
|
||||
@ -171,14 +171,14 @@ The rule of thumb:
|
||||
- RMW operations that are conditional are unordered on FAILURE,
|
||||
otherwise the above rules apply.
|
||||
|
||||
Except of course when an operation has an explicit ordering like:
|
||||
Except of course when a successful operation has an explicit ordering like:
|
||||
|
||||
{}_relaxed: unordered
|
||||
{}_acquire: the R of the RMW (or atomic_read) is an ACQUIRE
|
||||
{}_release: the W of the RMW (or atomic_set) is a RELEASE
|
||||
|
||||
Where 'unordered' is against other memory locations. Address dependencies are
|
||||
not defeated.
|
||||
not defeated. Conditional operations are still unordered on FAILURE.
|
||||
|
||||
Fully ordered primitives are ordered against everything prior and everything
|
||||
subsequent. Therefore a fully ordered primitive is like having an smp_mb()
|
||||
|
||||
@ -5,7 +5,11 @@
|
||||
BPF Instruction Set Architecture (ISA)
|
||||
======================================
|
||||
|
||||
This document specifies the BPF instruction set architecture (ISA).
|
||||
eBPF (which is no longer an acronym for anything), also commonly
|
||||
referred to as BPF, is a technology with origins in the Linux kernel
|
||||
that can run untrusted programs in a privileged context such as an
|
||||
operating system kernel. This document specifies the BPF instruction
|
||||
set architecture (ISA).
|
||||
|
||||
Documentation conventions
|
||||
=========================
|
||||
@ -43,7 +47,7 @@ a type's signedness (`S`) and bit width (`N`), respectively.
|
||||
===== =========
|
||||
|
||||
For example, `u32` is a type whose valid values are all the 32-bit unsigned
|
||||
numbers and `s16` is a types whose valid values are all the 16-bit signed
|
||||
numbers and `s16` is a type whose valid values are all the 16-bit signed
|
||||
numbers.
|
||||
|
||||
Functions
|
||||
@ -108,7 +112,7 @@ conformance group means it must support all instructions in that conformance
|
||||
group.
|
||||
|
||||
The use of named conformance groups enables interoperability between a runtime
|
||||
that executes instructions, and tools as such compilers that generate
|
||||
that executes instructions, and tools such as compilers that generate
|
||||
instructions for the runtime. Thus, capability discovery in terms of
|
||||
conformance groups might be done manually by users or automatically by tools.
|
||||
|
||||
@ -181,10 +185,13 @@ A basic instruction is encoded as follows::
|
||||
(`64-bit immediate instructions`_ reuse this field for other purposes)
|
||||
|
||||
**dst_reg**
|
||||
destination register number (0-10)
|
||||
destination register number (0-10), unless otherwise specified
|
||||
(future instructions might reuse this field for other purposes)
|
||||
|
||||
**offset**
|
||||
signed integer offset used with pointer arithmetic
|
||||
signed integer offset used with pointer arithmetic, except where
|
||||
otherwise specified (some arithmetic instructions reuse this field
|
||||
for other purposes)
|
||||
|
||||
**imm**
|
||||
signed integer immediate value
|
||||
@ -228,10 +235,12 @@ This is depicted in the following figure::
|
||||
operation to perform, encoded as explained above
|
||||
|
||||
**regs**
|
||||
The source and destination register numbers, encoded as explained above
|
||||
The source and destination register numbers (unless otherwise
|
||||
specified), encoded as explained above
|
||||
|
||||
**offset**
|
||||
signed integer offset used with pointer arithmetic
|
||||
signed integer offset used with pointer arithmetic, unless
|
||||
otherwise specified
|
||||
|
||||
**imm**
|
||||
signed integer immediate value
|
||||
@ -342,8 +351,8 @@ where '(u32)' indicates that the upper 32 bits are zeroed.
|
||||
|
||||
dst = dst ^ imm
|
||||
|
||||
Note that most instructions have instruction offset of 0. Only three instructions
|
||||
(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero offset.
|
||||
Note that most arithmetic instructions have 'offset' set to 0. Only three instructions
|
||||
(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero 'offset'.
|
||||
|
||||
Division, multiplication, and modulo operations for ``ALU`` are part
|
||||
of the "divmul32" conformance group, and division, multiplication, and
|
||||
@ -365,15 +374,15 @@ Note that there are varying definitions of the signed modulo operation
|
||||
when the dividend or divisor are negative, where implementations often
|
||||
vary by language such that Python, Ruby, etc. differ from C, Go, Java,
|
||||
etc. This specification requires that signed modulo use truncated division
|
||||
(where -13 % 3 == -1) as implemented in C, Go, etc.:
|
||||
(where -13 % 3 == -1) as implemented in C, Go, etc.::
|
||||
|
||||
a % n = a - n * trunc(a / n)
|
||||
|
||||
The ``MOVSX`` instruction does a move operation with sign extension.
|
||||
``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into 32
|
||||
bit operands, and zeroes the remaining upper 32 bits.
|
||||
``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into
|
||||
32-bit operands, and zeroes the remaining upper 32 bits.
|
||||
``{MOVSX, X, ALU64}`` :term:`sign extends<Sign Extend>` 8-bit, 16-bit, and 32-bit
|
||||
operands into 64 bit operands. Unlike other arithmetic instructions,
|
||||
operands into 64-bit operands. Unlike other arithmetic instructions,
|
||||
``MOVSX`` is only defined for register source operands (``X``).
|
||||
|
||||
The ``NEG`` instruction is only defined when the source bit is clear
|
||||
@ -411,19 +420,19 @@ conformance group.
|
||||
|
||||
Examples:
|
||||
|
||||
``{END, TO_LE, ALU}`` with imm = 16/32/64 means::
|
||||
``{END, TO_LE, ALU}`` with 'imm' = 16/32/64 means::
|
||||
|
||||
dst = htole16(dst)
|
||||
dst = htole32(dst)
|
||||
dst = htole64(dst)
|
||||
|
||||
``{END, TO_BE, ALU}`` with imm = 16/32/64 means::
|
||||
``{END, TO_BE, ALU}`` with 'imm' = 16/32/64 means::
|
||||
|
||||
dst = htobe16(dst)
|
||||
dst = htobe32(dst)
|
||||
dst = htobe64(dst)
|
||||
|
||||
``{END, TO_LE, ALU64}`` with imm = 16/32/64 means::
|
||||
``{END, TO_LE, ALU64}`` with 'imm' = 16/32/64 means::
|
||||
|
||||
dst = bswap16(dst)
|
||||
dst = bswap32(dst)
|
||||
@ -438,27 +447,33 @@ otherwise identical operations, and indicates the base64 conformance
|
||||
group unless otherwise specified.
|
||||
The 'code' field encodes the operation as below:
|
||||
|
||||
======== ===== ======= =============================== ===================================================
|
||||
code value src_reg description notes
|
||||
======== ===== ======= =============================== ===================================================
|
||||
JA 0x0 0x0 PC += offset {JA, K, JMP} only
|
||||
JA 0x0 0x0 PC += imm {JA, K, JMP32} only
|
||||
======== ===== ======= ================================= ===================================================
|
||||
code value src_reg description notes
|
||||
======== ===== ======= ================================= ===================================================
|
||||
JA 0x0 0x0 PC += offset {JA, K, JMP} only
|
||||
JA 0x0 0x0 PC += imm {JA, K, JMP32} only
|
||||
JEQ 0x1 any PC += offset if dst == src
|
||||
JGT 0x2 any PC += offset if dst > src unsigned
|
||||
JGE 0x3 any PC += offset if dst >= src unsigned
|
||||
JGT 0x2 any PC += offset if dst > src unsigned
|
||||
JGE 0x3 any PC += offset if dst >= src unsigned
|
||||
JSET 0x4 any PC += offset if dst & src
|
||||
JNE 0x5 any PC += offset if dst != src
|
||||
JSGT 0x6 any PC += offset if dst > src signed
|
||||
JSGE 0x7 any PC += offset if dst >= src signed
|
||||
CALL 0x8 0x0 call helper function by address {CALL, K, JMP} only, see `Helper functions`_
|
||||
CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_
|
||||
CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_
|
||||
EXIT 0x9 0x0 return {CALL, K, JMP} only
|
||||
JLT 0xa any PC += offset if dst < src unsigned
|
||||
JLE 0xb any PC += offset if dst <= src unsigned
|
||||
JSLT 0xc any PC += offset if dst < src signed
|
||||
JSLE 0xd any PC += offset if dst <= src signed
|
||||
======== ===== ======= =============================== ===================================================
|
||||
JSGT 0x6 any PC += offset if dst > src signed
|
||||
JSGE 0x7 any PC += offset if dst >= src signed
|
||||
CALL 0x8 0x0 call helper function by static ID {CALL, K, JMP} only, see `Helper functions`_
|
||||
CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_
|
||||
CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_
|
||||
EXIT 0x9 0x0 return {CALL, K, JMP} only
|
||||
JLT 0xa any PC += offset if dst < src unsigned
|
||||
JLE 0xb any PC += offset if dst <= src unsigned
|
||||
JSLT 0xc any PC += offset if dst < src signed
|
||||
JSLE 0xd any PC += offset if dst <= src signed
|
||||
======== ===== ======= ================================= ===================================================
|
||||
|
||||
where 'PC' denotes the program counter, and the offset to increment by
|
||||
is in units of 64-bit instructions relative to the instruction following
|
||||
the jump instruction. Thus 'PC += 1' skips execution of the next
|
||||
instruction if it's a basic instruction or results in undefined behavior
|
||||
if the next instruction is a 128-bit wide instruction.
|
||||
|
||||
The BPF program needs to store the return value into register R0 before doing an
|
||||
``EXIT``.
|
||||
@ -475,7 +490,7 @@ where 's>=' indicates a signed '>=' comparison.
|
||||
|
||||
gotol +imm
|
||||
|
||||
where 'imm' means the branch offset comes from insn 'imm' field.
|
||||
where 'imm' means the branch offset comes from the 'imm' field.
|
||||
|
||||
Note that there are two flavors of ``JA`` instructions. The
|
||||
``JMP`` class permits a 16-bit jump offset specified by the 'offset'
|
||||
@ -493,26 +508,26 @@ Helper functions
|
||||
Helper functions are a concept whereby BPF programs can call into a
|
||||
set of function calls exposed by the underlying platform.
|
||||
|
||||
Historically, each helper function was identified by an address
|
||||
encoded in the imm field. The available helper functions may differ
|
||||
for each program type, but address values are unique across all program types.
|
||||
Historically, each helper function was identified by a static ID
|
||||
encoded in the 'imm' field. The available helper functions may differ
|
||||
for each program type, but static IDs are unique across all program types.
|
||||
|
||||
Platforms that support the BPF Type Format (BTF) support identifying
|
||||
a helper function by a BTF ID encoded in the imm field, where the BTF ID
|
||||
a helper function by a BTF ID encoded in the 'imm' field, where the BTF ID
|
||||
identifies the helper name and type.
|
||||
|
||||
Program-local functions
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Program-local functions are functions exposed by the same BPF program as the
|
||||
caller, and are referenced by offset from the call instruction, similar to
|
||||
``JA``. The offset is encoded in the imm field of the call instruction.
|
||||
A ``EXIT`` within the program-local function will return to the caller.
|
||||
``JA``. The offset is encoded in the 'imm' field of the call instruction.
|
||||
An ``EXIT`` within the program-local function will return to the caller.
|
||||
|
||||
Load and store instructions
|
||||
===========================
|
||||
|
||||
For load and store instructions (``LD``, ``LDX``, ``ST``, and ``STX``), the
|
||||
8-bit 'opcode' field is divided as::
|
||||
8-bit 'opcode' field is divided as follows::
|
||||
|
||||
+-+-+-+-+-+-+-+-+
|
||||
|mode |sz |class|
|
||||
@ -580,7 +595,7 @@ instructions that transfer data between a register and memory.
|
||||
|
||||
dst = *(signed size *) (src + offset)
|
||||
|
||||
Where size is one of: ``B``, ``H``, or ``W``, and
|
||||
Where '<size>' is one of: ``B``, ``H``, or ``W``, and
|
||||
'signed size' is one of: s8, s16, or s32.
|
||||
|
||||
Atomic operations
|
||||
@ -662,11 +677,11 @@ src_reg pseudocode imm type dst type
|
||||
======= ========================================= =========== ==============
|
||||
0x0 dst = (next_imm << 32) | imm integer integer
|
||||
0x1 dst = map_by_fd(imm) map fd map
|
||||
0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer
|
||||
0x3 dst = var_addr(imm) variable id data pointer
|
||||
0x4 dst = code_addr(imm) integer code pointer
|
||||
0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data address
|
||||
0x3 dst = var_addr(imm) variable id data address
|
||||
0x4 dst = code_addr(imm) integer code address
|
||||
0x5 dst = map_by_idx(imm) map index map
|
||||
0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer
|
||||
0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data address
|
||||
======= ========================================= =========== ==============
|
||||
|
||||
where
|
||||
|
||||
@ -75,6 +75,8 @@ if major >= 3:
|
||||
"__rcu",
|
||||
"__user",
|
||||
"__force",
|
||||
"__counted_by_le",
|
||||
"__counted_by_be",
|
||||
|
||||
# include/linux/compiler_attributes.h:
|
||||
"__alias",
|
||||
|
||||
@ -203,13 +203,33 @@ setting the DMA mask fails. In this manner, if a user of your driver reports
|
||||
that performance is bad or that the device is not even detected, you can ask
|
||||
them for the kernel messages to find out exactly why.
|
||||
|
||||
The standard 64-bit addressing device would do something like this::
|
||||
The 24-bit addressing device would do something like this::
|
||||
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(24))) {
|
||||
dev_warn(dev, "mydev: No suitable DMA available\n");
|
||||
goto ignore_this_device;
|
||||
}
|
||||
|
||||
The standard 64-bit addressing device would do something like this::
|
||||
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))
|
||||
|
||||
dma_set_mask_and_coherent() never return fail when DMA_BIT_MASK(64). Typical
|
||||
error code like::
|
||||
|
||||
/* Wrong code */
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)))
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))
|
||||
|
||||
dma_set_mask_and_coherent() will never return failure when bigger than 32.
|
||||
So typical code like::
|
||||
|
||||
/* Recommended code */
|
||||
if (support_64bit)
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
|
||||
else
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
|
||||
|
||||
If the device only supports 32-bit addressing for descriptors in the
|
||||
coherent allocations, but supports full 64-bits for streaming mappings
|
||||
it would look like this::
|
||||
|
||||
@ -18,7 +18,7 @@ exceptions`_, `NMI and NMI-like exceptions`_.
|
||||
Non-instrumentable code - noinstr
|
||||
---------------------------------
|
||||
|
||||
Most instrumentation facilities depend on RCU, so intrumentation is prohibited
|
||||
Most instrumentation facilities depend on RCU, so instrumentation is prohibited
|
||||
for entry code before RCU starts watching and exit code after RCU stops
|
||||
watching. In addition, many architectures must save and restore register state,
|
||||
which means that (for example) a breakpoint in the breakpoint entry code would
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
Printk Index
|
||||
============
|
||||
|
||||
There are many ways how to monitor the state of the system. One important
|
||||
There are many ways to monitor the state of the system. One important
|
||||
source of information is the system log. It provides a lot of information,
|
||||
including more or less important warnings and error messages.
|
||||
|
||||
@ -101,7 +101,7 @@ their own wrappers adding __printk_index_emit().
|
||||
|
||||
Only few subsystem specific wrappers have been updated so far,
|
||||
for example, dev_printk(). As a result, the printk formats from
|
||||
some subsystes can be missing in the printk index.
|
||||
some subsystems can be missing in the printk index.
|
||||
|
||||
|
||||
Subsystem specific prefix
|
||||
|
||||
@ -91,6 +91,16 @@ the below options are available:
|
||||
behaviour when encountering a data race is deemed safe. Please see
|
||||
`"Marking Shared-Memory Accesses" in the LKMM`_ for more information.
|
||||
|
||||
* Similar to ``data_race(...)``, the type qualifier ``__data_racy`` can be used
|
||||
to document that all data races due to accesses to a variable are intended
|
||||
and should be ignored by KCSAN::
|
||||
|
||||
struct foo {
|
||||
...
|
||||
int __data_racy stats_counter;
|
||||
...
|
||||
};
|
||||
|
||||
* Disabling data race detection for entire functions can be accomplished by
|
||||
using the function attribute ``__no_kcsan``::
|
||||
|
||||
|
||||
@ -183,7 +183,7 @@ expected time it takes to run a test. If you have control over the systems
|
||||
which will run the tests you can configure a test runner on those systems to
|
||||
use a greater or lower timeout on the command line as with the `-o` or
|
||||
the `--override-timeout` argument. For example to use 165 seconds instead
|
||||
one would use:
|
||||
one would use::
|
||||
|
||||
$ ./run_kselftest.sh --override-timeout 165
|
||||
|
||||
|
||||
@ -0,0 +1,84 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/access-controllers/access-controllers.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Generic Domain Access Controllers
|
||||
|
||||
maintainers:
|
||||
- Oleksii Moisieiev <oleksii_moisieiev@epam.com>
|
||||
|
||||
description: |+
|
||||
Common access controllers properties
|
||||
|
||||
Access controllers are in charge of stating which of the hardware blocks under
|
||||
their responsibility (their domain) can be accesssed by which compartment. A
|
||||
compartment can be a cluster of CPUs (or coprocessors), a range of addresses
|
||||
or a group of hardware blocks. An access controller's domain is the set of
|
||||
resources covered by the access controller.
|
||||
|
||||
This device tree binding can be used to bind devices to their access
|
||||
controller provided by access-controllers property. In this case, the device
|
||||
is a consumer and the access controller is the provider.
|
||||
|
||||
An access controller can be represented by any node in the device tree and
|
||||
can provide one or more configuration parameters, needed to control parameters
|
||||
of the consumer device. A consumer node can refer to the provider by phandle
|
||||
and a set of phandle arguments, specified by '#access-controller-cells'
|
||||
property in the access controller node.
|
||||
|
||||
Access controllers are typically used to set/read the permissions of a
|
||||
hardware block and grant access to it. Any of which depends on the access
|
||||
controller. The capabilities of each access controller are defined by the
|
||||
binding of the access controller device.
|
||||
|
||||
Each node can be a consumer for the several access controllers.
|
||||
|
||||
# always select the core schema
|
||||
select: true
|
||||
|
||||
properties:
|
||||
"#access-controller-cells":
|
||||
description:
|
||||
Number of cells in an access-controllers specifier;
|
||||
Can be any value as specified by device tree binding documentation
|
||||
of a particular provider. The node is an access controller.
|
||||
|
||||
access-controller-names:
|
||||
$ref: /schemas/types.yaml#/definitions/string-array
|
||||
description:
|
||||
A list of access-controllers names, sorted in the same order as
|
||||
access-controllers entries. Consumer drivers will use
|
||||
access-controller-names to match with existing access-controllers entries.
|
||||
|
||||
access-controllers:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
A list of access controller specifiers, as defined by the
|
||||
bindings of the access-controllers provider.
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
examples:
|
||||
- |
|
||||
clock_controller: access-controllers@50000 {
|
||||
reg = <0x50000 0x400>;
|
||||
#access-controller-cells = <2>;
|
||||
};
|
||||
|
||||
bus_controller: bus@60000 {
|
||||
reg = <0x60000 0x10000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
#access-controller-cells = <3>;
|
||||
|
||||
uart4: serial@60100 {
|
||||
reg = <0x60100 0x400>;
|
||||
clocks = <&clk_serial>;
|
||||
access-controllers = <&clock_controller 1 2>,
|
||||
<&bus_controller 1 3 5>;
|
||||
access-controller-names = "clock", "bus";
|
||||
};
|
||||
};
|
||||
@ -53,6 +53,7 @@ properties:
|
||||
- description: BCM4709 based boards
|
||||
items:
|
||||
- enum:
|
||||
- asus,rt-ac3200
|
||||
- asus,rt-ac87u
|
||||
- buffalo,wxr-1900dhp
|
||||
- linksys,ea9200
|
||||
@ -67,6 +68,7 @@ properties:
|
||||
items:
|
||||
- enum:
|
||||
- asus,rt-ac3100
|
||||
- asus,rt-ac5300
|
||||
- asus,rt-ac88u
|
||||
- dlink,dir-885l
|
||||
- dlink,dir-890l
|
||||
|
||||
@ -46,6 +46,30 @@ properties:
|
||||
- compatible
|
||||
- "#clock-cells"
|
||||
|
||||
gpio:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: raspberrypi,firmware-gpio
|
||||
|
||||
gpio-controller: true
|
||||
|
||||
"#gpio-cells":
|
||||
const: 2
|
||||
description:
|
||||
The first cell is the pin number, and the second cell is used to
|
||||
specify the gpio polarity (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW).
|
||||
|
||||
gpio-line-names:
|
||||
minItems: 8
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- gpio-controller
|
||||
- "#gpio-cells"
|
||||
|
||||
reset:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
@ -96,6 +120,12 @@ examples:
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
expgpio: gpio {
|
||||
compatible = "raspberrypi,firmware-gpio";
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
|
||||
reset: reset {
|
||||
compatible = "raspberrypi,firmware-reset";
|
||||
#reset-cells = <1>;
|
||||
|
||||
@ -813,6 +813,14 @@ properties:
|
||||
- const: tq,imx6ull-tqma6ull2l # MCIMX6Y2, LGA SoM variant
|
||||
- const: fsl,imx6ull
|
||||
|
||||
- description: Seeed Stuido i.MX6ULL SoM on dev boards
|
||||
items:
|
||||
- enum:
|
||||
- seeed,imx6ull-seeed-npi-emmc
|
||||
- seeed,imx6ull-seeed-npi-nand
|
||||
- const: seeed,imx6ull-seeed-npi
|
||||
- const: fsl,imx6ull
|
||||
|
||||
- description: i.MX6ULZ based Boards
|
||||
items:
|
||||
- enum:
|
||||
@ -1050,6 +1058,7 @@ properties:
|
||||
- enum:
|
||||
- beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit
|
||||
- dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC
|
||||
- emcraft,imx8mp-navqp # i.MX8MP Emcraft Systems NavQ+ Kit
|
||||
- fsl,imx8mp-evk # i.MX8MP EVK Board
|
||||
- gateworks,imx8mp-gw71xx-2x # i.MX8MP Gateworks Board
|
||||
- gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board
|
||||
@ -1218,7 +1227,6 @@ properties:
|
||||
- enum:
|
||||
- einfochips,imx8qxp-ai_ml # i.MX8QXP AI_ML Board
|
||||
- fsl,imx8qxp-mek # i.MX8QXP MEK Board
|
||||
- toradex,colibri-imx8x # Colibri iMX8X Modules
|
||||
- const: fsl,imx8qxp
|
||||
|
||||
- description: i.MX8DXL based Boards
|
||||
@ -1227,7 +1235,7 @@ properties:
|
||||
- fsl,imx8dxl-evk # i.MX8DXL EVK Board
|
||||
- const: fsl,imx8dxl
|
||||
|
||||
- description: i.MX8QXP Boards with Toradex Colibri iMX8X Modules
|
||||
- description: i.MX8QXP/i.MX8DX Boards with Toradex Colibri iMX8X Modules
|
||||
items:
|
||||
- enum:
|
||||
- toradex,colibri-imx8x-aster # Colibri iMX8X Module on Aster Board
|
||||
@ -1235,7 +1243,9 @@ properties:
|
||||
- toradex,colibri-imx8x-iris # Colibri iMX8X Module on Iris Board
|
||||
- toradex,colibri-imx8x-iris-v2 # Colibri iMX8X Module on Iris Board V2
|
||||
- const: toradex,colibri-imx8x
|
||||
- const: fsl,imx8qxp
|
||||
- enum:
|
||||
- fsl,imx8qxp
|
||||
- fsl,imx8dx
|
||||
|
||||
- description:
|
||||
TQMa8Xx is a series of SOM featuring NXP i.MX8X system-on-chip
|
||||
@ -1536,6 +1546,12 @@ properties:
|
||||
- nxp,s32g274a-rdb2
|
||||
- const: nxp,s32g2
|
||||
|
||||
- description: S32G3 based Boards
|
||||
items:
|
||||
- enum:
|
||||
- nxp,s32g399a-rdb3
|
||||
- const: nxp,s32g3
|
||||
|
||||
- description: S32V234 based Boards
|
||||
items:
|
||||
- enum:
|
||||
|
||||
@ -61,10 +61,6 @@ properties:
|
||||
mboxes:
|
||||
minItems: 2
|
||||
|
||||
ti,system-reboot-controller:
|
||||
description: Determines If system reboot can be triggered by SoC reboot
|
||||
type: boolean
|
||||
|
||||
ti,host-id:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
@ -94,7 +90,6 @@ examples:
|
||||
- |
|
||||
pmmc: system-controller@2921800 {
|
||||
compatible = "ti,k2g-sci";
|
||||
ti,system-reboot-controller;
|
||||
mbox-names = "rx", "tx";
|
||||
mboxes = <&msgmgr 5 2>,
|
||||
<&msgmgr 0 0>;
|
||||
|
||||
@ -137,6 +137,7 @@ properties:
|
||||
- microsoft,dempsey
|
||||
- microsoft,makepeace
|
||||
- microsoft,moneypenny
|
||||
- motorola,falcon
|
||||
- samsung,s3ve3g
|
||||
- const: qcom,msm8226
|
||||
|
||||
@ -184,13 +185,16 @@ properties:
|
||||
- oneplus,bacon
|
||||
- samsung,klte
|
||||
- sony,xperia-castor
|
||||
- sony,xperia-leo
|
||||
- const: qcom,msm8974pro
|
||||
- const: qcom,msm8974
|
||||
|
||||
- items:
|
||||
- const: qcom,msm8916-mtp
|
||||
- const: qcom,msm8916-mtp/1
|
||||
- const: qcom,msm8916
|
||||
- enum:
|
||||
- samsung,kltechn
|
||||
- const: samsung,klte
|
||||
- const: qcom,msm8974pro
|
||||
- const: qcom,msm8974
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
@ -200,6 +204,8 @@ properties:
|
||||
- gplus,fl8005a
|
||||
- huawei,g7
|
||||
- longcheer,l8910
|
||||
- longcheer,l8150
|
||||
- qcom,msm8916-mtp
|
||||
- samsung,a3u-eur
|
||||
- samsung,a5u-eur
|
||||
- samsung,e5
|
||||
@ -220,11 +226,6 @@ properties:
|
||||
- yiming,uz801-v3
|
||||
- const: qcom,msm8916
|
||||
|
||||
- items:
|
||||
- const: longcheer,l8150
|
||||
- const: qcom,msm8916-v1-qrd/9-v1
|
||||
- const: qcom,msm8916
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- motorola,potter
|
||||
@ -1003,6 +1004,7 @@ properties:
|
||||
- qcom,sm8550-hdk
|
||||
- qcom,sm8550-mtp
|
||||
- qcom,sm8550-qrd
|
||||
- sony,pdx234
|
||||
- const: qcom,sm8550
|
||||
|
||||
- items:
|
||||
|
||||
@ -49,6 +49,11 @@ properties:
|
||||
- anbernic,rg-arc-s
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: ArmSoM Sige7 board
|
||||
items:
|
||||
- const: armsom,sige7
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: Asus Tinker board
|
||||
items:
|
||||
- const: asus,rk3288-tinker
|
||||
@ -198,6 +203,13 @@ properties:
|
||||
- const: firefly,rk3568-roc-pc
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Forlinx FET3588-C SoM
|
||||
items:
|
||||
- enum:
|
||||
- forlinx,ok3588-c
|
||||
- const: forlinx,fet3588-c
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: FriendlyElec NanoPi R2 series boards
|
||||
items:
|
||||
- enum:
|
||||
@ -236,6 +248,11 @@ properties:
|
||||
- const: friendlyarm,nanopc-t6
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: GameForce Chi
|
||||
items:
|
||||
- const: gameforce,chi
|
||||
- const: rockchip,rk3326
|
||||
|
||||
- description: GeekBuying GeekBox
|
||||
items:
|
||||
- const: geekbuying,geekbox
|
||||
@ -631,7 +648,7 @@ properties:
|
||||
- const: phytec,rk3288-phycore-som
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Pine64 PinebookPro
|
||||
- description: Pine64 Pinebook Pro
|
||||
items:
|
||||
- const: pine64,pinebook-pro
|
||||
- const: rockchip,rk3399
|
||||
@ -644,7 +661,7 @@ properties:
|
||||
- const: pine64,pinenote
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: Pine64 PinePhonePro
|
||||
- description: Pine64 PinePhone Pro
|
||||
items:
|
||||
- const: pine64,pinephone-pro
|
||||
- const: rockchip,rk3399
|
||||
@ -682,7 +699,7 @@ properties:
|
||||
- const: pine64,quartzpro64
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: Pine64 SoQuartz SoM
|
||||
- description: Pine64 SOQuartz
|
||||
items:
|
||||
- enum:
|
||||
- pine64,soquartz-blade
|
||||
@ -700,12 +717,17 @@ properties:
|
||||
- powkiddy,x55
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: Protonic MECSBC board
|
||||
items:
|
||||
- const: prt,mecsbc
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: QNAP TS-433-4G 4-Bay NAS
|
||||
items:
|
||||
- const: qnap,ts433
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Radxa Compute Module 3(CM3)
|
||||
- description: Radxa Compute Module 3 (CM3)
|
||||
items:
|
||||
- enum:
|
||||
- radxa,cm3-io
|
||||
@ -767,22 +789,27 @@ properties:
|
||||
- const: radxa,rockpis
|
||||
- const: rockchip,rk3308
|
||||
|
||||
- description: Radxa Rock2 Square
|
||||
- description: Radxa Rock 2 Square
|
||||
items:
|
||||
- const: radxa,rock2-square
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Radxa ROCK3 Model A
|
||||
- description: Radxa ROCK 3A
|
||||
items:
|
||||
- const: radxa,rock3a
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Radxa ROCK 5 Model A
|
||||
- description: Radxa ROCK 3C
|
||||
items:
|
||||
- const: radxa,rock-3c
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: Radxa ROCK 5A
|
||||
items:
|
||||
- const: radxa,rock-5a
|
||||
- const: rockchip,rk3588s
|
||||
|
||||
- description: Radxa ROCK 5 Model B
|
||||
- description: Radxa ROCK 5B
|
||||
items:
|
||||
- const: radxa,rock-5b
|
||||
- const: rockchip,rk3588
|
||||
@ -927,6 +954,11 @@ properties:
|
||||
- const: turing,rk1
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: WolfVision PF5 mainboard
|
||||
items:
|
||||
- const: wolfvision,rk3568-pf5
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Xunlong Orange Pi 5 Plus
|
||||
items:
|
||||
- const: xunlong,orangepi-5-plus
|
||||
|
||||
@ -56,6 +56,21 @@ properties:
|
||||
- const: anbernic,rg-nano
|
||||
- const: allwinner,sun8i-v3s
|
||||
|
||||
- description: Anbernic RG35XX (2024)
|
||||
- items:
|
||||
- const: anbernic,rg35xx-2024
|
||||
- const: allwinner,sun50i-h700
|
||||
|
||||
- description: Anbernic RG35XX Plus
|
||||
- items:
|
||||
- const: anbernic,rg35xx-plus
|
||||
- const: allwinner,sun50i-h700
|
||||
|
||||
- description: Anbernic RG35XX H
|
||||
- items:
|
||||
- const: anbernic,rg35xx-h
|
||||
- const: allwinner,sun50i-h700
|
||||
|
||||
- description: Amarula A64 Relic
|
||||
items:
|
||||
- const: amarula,a64-relic
|
||||
@ -774,6 +789,11 @@ properties:
|
||||
- const: pocketbook,touch-lux-3
|
||||
- const: allwinner,sun5i-a13
|
||||
|
||||
- description: PocketBook 614 Plus
|
||||
items:
|
||||
- const: pocketbook,614-plus
|
||||
- const: allwinner,sun5i-a13
|
||||
|
||||
- description: Point of View Protab2-IPS9
|
||||
items:
|
||||
- const: pov,protab2-ips9
|
||||
@ -860,6 +880,11 @@ properties:
|
||||
- const: allwinner,sl631
|
||||
- const: allwinner,sun8i-v3
|
||||
|
||||
- description: Tanix TX1
|
||||
items:
|
||||
- const: oranth,tanix-tx1
|
||||
- const: allwinner,sun50i-h616
|
||||
|
||||
- description: Tanix TX6
|
||||
items:
|
||||
- const: oranth,tanix-tx6
|
||||
|
||||
@ -1,18 +0,0 @@
|
||||
Device tree binding for the TI DA850 AHCI SATA Controller
|
||||
---------------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "ti,da850-ahci"
|
||||
- reg: physical base addresses and sizes of the two register regions
|
||||
used by the controller: the register map as defined by the
|
||||
AHCI 1.1 standard and the Power Down Control Register (PWRDN)
|
||||
for enabling/disabling the SATA clock receiver
|
||||
- interrupts: interrupt specifier (refer to the interrupt binding)
|
||||
|
||||
Example:
|
||||
|
||||
sata: sata@218000 {
|
||||
compatible = "ti,da850-ahci";
|
||||
reg = <0x218000 0x2000>, <0x22c018 0x4>;
|
||||
interrupts = <67>;
|
||||
};
|
||||
42
Documentation/devicetree/bindings/ata/fsl,imx-pata.yaml
Normal file
42
Documentation/devicetree/bindings/ata/fsl,imx-pata.yaml
Normal file
@ -0,0 +1,42 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/ata/fsl,imx-pata.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Freescale i.MX PATA Controller
|
||||
|
||||
maintainers:
|
||||
- Animesh Agarwal <animeshagarwal28@gmail.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,imx31-pata
|
||||
- fsl,imx51-pata
|
||||
- const: fsl,imx27-pata
|
||||
- const: fsl,imx27-pata
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
items:
|
||||
- description: PATA Controller interrupts
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: PATA Controller clocks
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
pata: pata@83fe0000 {
|
||||
compatible = "fsl,imx51-pata", "fsl,imx27-pata";
|
||||
reg = <0x83fe0000 0x4000>;
|
||||
interrupts = <70>;
|
||||
clocks = <&clks 161>;
|
||||
};
|
||||
@ -1,16 +0,0 @@
|
||||
* Freescale i.MX PATA Controller
|
||||
|
||||
Required properties:
|
||||
- compatible: "fsl,imx27-pata"
|
||||
- reg: Address range of the PATA Controller
|
||||
- interrupts: The interrupt of the PATA Controller
|
||||
- clocks: the clocks for the PATA Controller
|
||||
|
||||
Example:
|
||||
|
||||
pata: pata@83fe0000 {
|
||||
compatible = "fsl,imx51-pata", "fsl,imx27-pata";
|
||||
reg = <0x83fe0000 0x4000>;
|
||||
interrupts = <70>;
|
||||
clocks = <&clks 161>;
|
||||
};
|
||||
39
Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml
Normal file
39
Documentation/devicetree/bindings/ata/ti,da850-ahci.yaml
Normal file
@ -0,0 +1,39 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/ata/ti,da850-ahci.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: TI DA850 AHCI SATA Controller
|
||||
|
||||
maintainers:
|
||||
- Animesh Agarwal <animeshagarwal28@gmail.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: ti,da850-ahci
|
||||
|
||||
reg:
|
||||
items:
|
||||
- description: Address and size of the register map as defined by the AHCI 1.1 standard.
|
||||
- description:
|
||||
Address and size of Power Down Control Register (PWRDN) for enabling/disabling the SATA clock
|
||||
receiver.
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
sata@218000 {
|
||||
compatible = "ti,da850-ahci";
|
||||
reg = <0x218000 0x2000>, <0x22c018 0x4>;
|
||||
interrupts = <67>;
|
||||
};
|
||||
96
Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml
Normal file
96
Documentation/devicetree/bindings/bus/st,stm32-etzpc.yaml
Normal file
@ -0,0 +1,96 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/bus/st,stm32-etzpc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: STM32 Extended TrustZone protection controller
|
||||
|
||||
description: |
|
||||
The ETZPC configures TrustZone security in a SoC having bus masters and
|
||||
devices with programmable-security attributes (securable resources).
|
||||
|
||||
maintainers:
|
||||
- Gatien Chevallier <gatien.chevallier@foss.st.com>
|
||||
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: st,stm32-etzpc
|
||||
required:
|
||||
- compatible
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: st,stm32-etzpc
|
||||
- const: simple-bus
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 1
|
||||
|
||||
ranges: true
|
||||
|
||||
"#access-controller-cells":
|
||||
const: 1
|
||||
description:
|
||||
Contains the firewall ID associated to the peripheral.
|
||||
|
||||
patternProperties:
|
||||
"^.*@[0-9a-f]+$":
|
||||
description: Peripherals
|
||||
type: object
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
required:
|
||||
- access-controllers
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
- "#access-controller-cells"
|
||||
- ranges
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
// In this example, the usart2 device refers to rifsc as its access
|
||||
// controller.
|
||||
// Access rights are verified before creating devices.
|
||||
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/clock/stm32mp13-clks.h>
|
||||
#include <dt-bindings/reset/stm32mp13-resets.h>
|
||||
|
||||
etzpc: bus@5c007000 {
|
||||
compatible = "st,stm32-etzpc", "simple-bus";
|
||||
reg = <0x5c007000 0x400>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
#access-controller-cells = <1>;
|
||||
ranges;
|
||||
|
||||
usart2: serial@4c001000 {
|
||||
compatible = "st,stm32h7-uart";
|
||||
reg = <0x4c001000 0x400>;
|
||||
interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&rcc USART2_K>;
|
||||
resets = <&rcc USART2_R>;
|
||||
wakeup-source;
|
||||
dmas = <&dmamux1 43 0x400 0x5>,
|
||||
<&dmamux1 44 0x400 0x1>;
|
||||
dma-names = "rx", "tx";
|
||||
access-controllers = <&etzpc 17>;
|
||||
};
|
||||
};
|
||||
105
Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
Normal file
105
Documentation/devicetree/bindings/bus/st,stm32mp25-rifsc.yaml
Normal file
@ -0,0 +1,105 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/bus/st,stm32mp25-rifsc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: STM32 Resource isolation framework security controller
|
||||
|
||||
maintainers:
|
||||
- Gatien Chevallier <gatien.chevallier@foss.st.com>
|
||||
|
||||
description: |
|
||||
Resource isolation framework (RIF) is a comprehensive set of hardware blocks
|
||||
designed to enforce and manage isolation of STM32 hardware resources like
|
||||
memory and peripherals.
|
||||
|
||||
The RIFSC (RIF security controller) is composed of three sets of registers,
|
||||
each managing a specific set of hardware resources:
|
||||
- RISC registers associated with RISUP logic (resource isolation device unit
|
||||
for peripherals), assign all non-RIF aware peripherals to zero, one or
|
||||
any security domains (secure, privilege, compartment).
|
||||
- RIMC registers: associated with RIMU logic (resource isolation master
|
||||
unit), assign all non RIF-aware bus master to one security domain by
|
||||
setting secure, privileged and compartment information on the system bus.
|
||||
Alternatively, the RISUP logic controlling the device port access to a
|
||||
peripheral can assign target bus attributes to this peripheral master port
|
||||
(supported attribute: CID).
|
||||
- RISC registers associated with RISAL logic (resource isolation device unit
|
||||
for address space - Lite version), assign address space subregions to one
|
||||
security domains (secure, privilege, compartment).
|
||||
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: st,stm32mp25-rifsc
|
||||
required:
|
||||
- compatible
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: st,stm32mp25-rifsc
|
||||
- const: simple-bus
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 1
|
||||
|
||||
ranges: true
|
||||
|
||||
"#access-controller-cells":
|
||||
const: 1
|
||||
description:
|
||||
Contains the firewall ID associated to the peripheral.
|
||||
|
||||
patternProperties:
|
||||
"^.*@[0-9a-f]+$":
|
||||
description: Peripherals
|
||||
type: object
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
required:
|
||||
- access-controllers
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
- "#access-controller-cells"
|
||||
- ranges
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
// In this example, the usart2 device refers to rifsc as its domain
|
||||
// controller.
|
||||
// Access rights are verified before creating devices.
|
||||
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
rifsc: bus@42080000 {
|
||||
compatible = "st,stm32mp25-rifsc", "simple-bus";
|
||||
reg = <0x42080000 0x1000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
#access-controller-cells = <1>;
|
||||
ranges;
|
||||
|
||||
usart2: serial@400e0000 {
|
||||
compatible = "st,stm32h7-uart";
|
||||
reg = <0x400e0000 0x400>;
|
||||
interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&ck_flexgen_08>;
|
||||
access-controllers = <&rifsc 32>;
|
||||
};
|
||||
};
|
||||
@ -30,16 +30,18 @@ properties:
|
||||
- google,gs101-cmu-top
|
||||
- google,gs101-cmu-apm
|
||||
- google,gs101-cmu-misc
|
||||
- google,gs101-cmu-hsi0
|
||||
- google,gs101-cmu-hsi2
|
||||
- google,gs101-cmu-peric0
|
||||
- google,gs101-cmu-peric1
|
||||
|
||||
clocks:
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
maxItems: 5
|
||||
|
||||
clock-names:
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
maxItems: 5
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
@ -72,6 +74,55 @@ allOf:
|
||||
items:
|
||||
- const: oscclk
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: google,gs101-cmu-hsi0
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: External reference clock (24.576 MHz)
|
||||
- description: HSI0 bus clock (from CMU_TOP)
|
||||
- description: DPGTC (from CMU_TOP)
|
||||
- description: USB DRD controller clock (from CMU_TOP)
|
||||
- description: USB Display Port debug clock (from CMU_TOP)
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: oscclk
|
||||
- const: bus
|
||||
- const: dpgtc
|
||||
- const: usb31drd
|
||||
- const: usbdpdbg
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- google,gs101-cmu-hsi2
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: External reference clock (24.576 MHz)
|
||||
- description: High Speed Interface bus clock (from CMU_TOP)
|
||||
- description: High Speed Interface pcie clock (from CMU_TOP)
|
||||
- description: High Speed Interface ufs clock (from CMU_TOP)
|
||||
- description: High Speed Interface mmc clock (from CMU_TOP)
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: oscclk
|
||||
- const: bus
|
||||
- const: pcie
|
||||
- const: ufs
|
||||
- const: mmc
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@ -38,6 +38,7 @@ properties:
|
||||
- qcom,sc7280-cpufreq-epss
|
||||
- qcom,sc8280xp-cpufreq-epss
|
||||
- qcom,sdx75-cpufreq-epss
|
||||
- qcom,sm4450-cpufreq-epss
|
||||
- qcom,sm6375-cpufreq-epss
|
||||
- qcom,sm8250-cpufreq-epss
|
||||
- qcom,sm8350-cpufreq-epss
|
||||
@ -133,6 +134,7 @@ allOf:
|
||||
- qcom,sc8280xp-cpufreq-epss
|
||||
- qcom,sdm670-cpufreq-hw
|
||||
- qcom,sdm845-cpufreq-hw
|
||||
- qcom,sm4450-cpufreq-epss
|
||||
- qcom,sm6115-cpufreq-hw
|
||||
- qcom,sm6350-cpufreq-hw
|
||||
- qcom,sm6375-cpufreq-epss
|
||||
|
||||
@ -0,0 +1,52 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/crypto/nvidia,tegra234-se-aes.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NVIDIA Tegra Security Engine for AES algorithms
|
||||
|
||||
description:
|
||||
The Tegra Security Engine accelerates the following AES encryption/decryption
|
||||
algorithms - AES-ECB, AES-CBC, AES-OFB, AES-XTS, AES-CTR, AES-GCM, AES-CCM,
|
||||
AES-CMAC
|
||||
|
||||
maintainers:
|
||||
- Akhil R <akhilrajeev@nvidia.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: nvidia,tegra234-se-aes
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
iommus:
|
||||
maxItems: 1
|
||||
|
||||
dma-coherent: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- iommus
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/memory/tegra234-mc.h>
|
||||
#include <dt-bindings/clock/tegra234-clock.h>
|
||||
|
||||
crypto@15820000 {
|
||||
compatible = "nvidia,tegra234-se-aes";
|
||||
reg = <0x15820000 0x10000>;
|
||||
clocks = <&bpmp TEGRA234_CLK_SE>;
|
||||
iommus = <&smmu TEGRA234_SID_SES_SE1>;
|
||||
dma-coherent;
|
||||
};
|
||||
...
|
||||
@ -0,0 +1,52 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/crypto/nvidia,tegra234-se-hash.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NVIDIA Tegra Security Engine for HASH algorithms
|
||||
|
||||
description:
|
||||
The Tegra Security HASH Engine accelerates the following HASH functions -
|
||||
SHA1, SHA224, SHA256, SHA384, SHA512, SHA3-224, SHA3-256, SHA3-384, SHA3-512
|
||||
HMAC(SHA224), HMAC(SHA256), HMAC(SHA384), HMAC(SHA512)
|
||||
|
||||
maintainers:
|
||||
- Akhil R <akhilrajeev@nvidia.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: nvidia,tegra234-se-hash
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
iommus:
|
||||
maxItems: 1
|
||||
|
||||
dma-coherent: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- iommus
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/memory/tegra234-mc.h>
|
||||
#include <dt-bindings/clock/tegra234-clock.h>
|
||||
|
||||
crypto@15840000 {
|
||||
compatible = "nvidia,tegra234-se-hash";
|
||||
reg = <0x15840000 0x10000>;
|
||||
clocks = <&bpmp TEGRA234_CLK_SE>;
|
||||
iommus = <&smmu TEGRA234_SID_SES_SE2>;
|
||||
dma-coherent;
|
||||
};
|
||||
...
|
||||
@ -1,28 +0,0 @@
|
||||
OMAP SoC SHA crypto Module
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should contain entries for this and backward compatible
|
||||
SHAM versions:
|
||||
- "ti,omap2-sham" for OMAP2 & OMAP3.
|
||||
- "ti,omap4-sham" for OMAP4 and AM33XX.
|
||||
- "ti,omap5-sham" for OMAP5, DRA7 and AM43XX.
|
||||
- ti,hwmods: Name of the hwmod associated with the SHAM module
|
||||
- reg : Offset and length of the register set for the module
|
||||
- interrupts : the interrupt-specifier for the SHAM module.
|
||||
|
||||
Optional properties:
|
||||
- dmas: DMA specifiers for the rx dma. See the DMA client binding,
|
||||
Documentation/devicetree/bindings/dma/dma.txt
|
||||
- dma-names: DMA request name. Should be "rx" if a dma is present.
|
||||
|
||||
Example:
|
||||
/* AM335x */
|
||||
sham: sham@53100000 {
|
||||
compatible = "ti,omap4-sham";
|
||||
ti,hwmods = "sham";
|
||||
reg = <0x53100000 0x200>;
|
||||
interrupts = <109>;
|
||||
dmas = <&edma 36>;
|
||||
dma-names = "rx";
|
||||
};
|
||||
@ -15,6 +15,7 @@ properties:
|
||||
- enum:
|
||||
- qcom,sa8775p-inline-crypto-engine
|
||||
- qcom,sc7180-inline-crypto-engine
|
||||
- qcom,sc7280-inline-crypto-engine
|
||||
- qcom,sm8450-inline-crypto-engine
|
||||
- qcom,sm8550-inline-crypto-engine
|
||||
- qcom,sm8650-inline-crypto-engine
|
||||
|
||||
@ -46,6 +46,10 @@ properties:
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -51,6 +51,10 @@ properties:
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -12,7 +12,9 @@ maintainers:
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: starfive,jh7110-crypto
|
||||
enum:
|
||||
- starfive,jh7110-crypto
|
||||
- starfive,jh8100-crypto
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
@ -28,7 +30,10 @@ properties:
|
||||
- const: ahb
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
minItems: 1
|
||||
items:
|
||||
- description: SHA2 module irq
|
||||
- description: SM3 module irq
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
@ -54,6 +59,27 @@ required:
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
const: starfive,jh7110-crypto
|
||||
|
||||
then:
|
||||
properties:
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
const: starfive,jh8100-crypto
|
||||
|
||||
then:
|
||||
properties:
|
||||
interrupts:
|
||||
minItems: 2
|
||||
|
||||
examples:
|
||||
- |
|
||||
crypto: crypto@16000000 {
|
||||
|
||||
56
Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml
Normal file
56
Documentation/devicetree/bindings/crypto/ti,omap-sham.yaml
Normal file
@ -0,0 +1,56 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/crypto/ti,omap-sham.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: OMAP SoC SHA crypto Module
|
||||
|
||||
maintainers:
|
||||
- Animesh Agarwal <animeshagarwal28@gmail.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ti,omap2-sham
|
||||
- ti,omap4-sham
|
||||
- ti,omap5-sham
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
dmas:
|
||||
maxItems: 1
|
||||
|
||||
dma-names:
|
||||
const: rx
|
||||
|
||||
ti,hwmods:
|
||||
description: Name of the hwmod associated with the SHAM module
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
enum: [sham]
|
||||
|
||||
dependencies:
|
||||
dmas: [dma-names]
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- ti,hwmods
|
||||
- reg
|
||||
- interrupts
|
||||
|
||||
examples:
|
||||
- |
|
||||
sham@53100000 {
|
||||
compatible = "ti,omap4-sham";
|
||||
ti,hwmods = "sham";
|
||||
reg = <0x53100000 0x200>;
|
||||
interrupts = <109>;
|
||||
dmas = <&edma 36>;
|
||||
dma-names = "rx";
|
||||
};
|
||||
@ -348,15 +348,6 @@ properties:
|
||||
# Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel
|
||||
- yes-optoelectronics,ytc700tlag-05-201c
|
||||
|
||||
backlight: true
|
||||
ddc-i2c-bus: true
|
||||
enable-gpios: true
|
||||
port: true
|
||||
power-supply: true
|
||||
no-hpd: true
|
||||
hpd-gpios: true
|
||||
data-mapping: true
|
||||
|
||||
if:
|
||||
not:
|
||||
properties:
|
||||
@ -367,7 +358,7 @@ then:
|
||||
properties:
|
||||
data-mapping: false
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
@ -177,6 +177,15 @@ allOf:
|
||||
|
||||
required:
|
||||
- reg-names
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- nvidia,tegra194-host1x
|
||||
then:
|
||||
properties:
|
||||
dma-coherent: true
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
@ -226,6 +235,8 @@ allOf:
|
||||
use. Should be a mapping of IDs 0..n to IOMMU entries corresponding to
|
||||
usable stream IDs.
|
||||
|
||||
dma-coherent: true
|
||||
|
||||
required:
|
||||
- reg-names
|
||||
|
||||
|
||||
@ -82,6 +82,10 @@ properties:
|
||||
description: if defined, it indicates that the controller
|
||||
supports memory-to-memory transfer
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -28,6 +28,10 @@ properties:
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -247,6 +247,37 @@ properties:
|
||||
reg:
|
||||
const: 0x18
|
||||
|
||||
protocol@19:
|
||||
type: object
|
||||
allOf:
|
||||
- $ref: '#/$defs/protocol-node'
|
||||
- $ref: /schemas/pinctrl/pinctrl.yaml
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
reg:
|
||||
const: 0x19
|
||||
|
||||
patternProperties:
|
||||
'-pins$':
|
||||
type: object
|
||||
allOf:
|
||||
- $ref: /schemas/pinctrl/pincfg-node.yaml#
|
||||
- $ref: /schemas/pinctrl/pinmux-node.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
description:
|
||||
A pin multiplexing sub-node describes how to configure a
|
||||
set of pins in some desired function.
|
||||
A single sub-node may define several pin configurations.
|
||||
This sub-node is using the default pinctrl bindings to configure
|
||||
pin multiplexing and using SCMI protocol to apply a specified
|
||||
configuration.
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
$defs:
|
||||
@ -355,7 +386,7 @@ examples:
|
||||
|
||||
scmi_dvfs: protocol@13 {
|
||||
reg = <0x13>;
|
||||
#clock-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
|
||||
mboxes = <&mhuB 1 0>,
|
||||
<&mhuB 1 1>;
|
||||
@ -401,6 +432,25 @@ examples:
|
||||
scmi_powercap: protocol@18 {
|
||||
reg = <0x18>;
|
||||
};
|
||||
|
||||
scmi_pinctrl: protocol@19 {
|
||||
reg = <0x19>;
|
||||
|
||||
i2c2-pins {
|
||||
groups = "g_i2c2_a", "g_i2c2_b";
|
||||
function = "f_i2c2";
|
||||
};
|
||||
|
||||
mdio-pins {
|
||||
groups = "g_avb_mdio";
|
||||
drive-strength = <24>;
|
||||
};
|
||||
|
||||
keys_pins: keys-pins {
|
||||
pins = "gpio_5_17", "gpio_5_20", "gpio_5_22", "gpio_2_1";
|
||||
bias-pull-up;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
@ -468,7 +518,7 @@ examples:
|
||||
reg = <0x13>;
|
||||
linaro,optee-channel-id = <1>;
|
||||
shmem = <&cpu_optee_lpri0>;
|
||||
#clock-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
scmi_clk0: protocol@14 {
|
||||
|
||||
@ -62,6 +62,8 @@ properties:
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
gpio-ranges: true
|
||||
|
||||
wakeup-source:
|
||||
type: boolean
|
||||
description: >
|
||||
@ -88,6 +90,7 @@ examples:
|
||||
interrupt-parent = <&irq0_intc>;
|
||||
interrupts = <0x6>;
|
||||
brcm,gpio-bank-widths = <32 32 32 24>;
|
||||
gpio-ranges = <&pinctrl 0 0 120>;
|
||||
};
|
||||
|
||||
upg_gio_aon: gpio@f04172c0 {
|
||||
|
||||
@ -14,6 +14,7 @@ properties:
|
||||
items:
|
||||
- enum:
|
||||
- microchip,mpfs-gpio
|
||||
- microchip,coregpio-rtl-v3
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
@ -43,6 +44,7 @@ properties:
|
||||
default: 32
|
||||
|
||||
gpio-controller: true
|
||||
gpio-line-names: true
|
||||
|
||||
patternProperties:
|
||||
"^.+-hog(-[0-9]+)?$":
|
||||
@ -62,12 +64,21 @@ patternProperties:
|
||||
- gpio-hog
|
||||
- gpios
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: microchip,mpfs-gpio
|
||||
then:
|
||||
required:
|
||||
- interrupts
|
||||
- "#interrupt-cells"
|
||||
- interrupt-controller
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- "#interrupt-cells"
|
||||
- interrupt-controller
|
||||
- "#gpio-cells"
|
||||
- gpio-controller
|
||||
- clocks
|
||||
|
||||
@ -1,30 +0,0 @@
|
||||
Raspberry Pi GPIO expander
|
||||
|
||||
The Raspberry Pi 3 GPIO expander is controlled by the VC4 firmware. The
|
||||
firmware exposes a mailbox interface that allows the ARM core to control the
|
||||
GPIO lines on the expander.
|
||||
|
||||
The Raspberry Pi GPIO expander node must be a child node of the Raspberry Pi
|
||||
firmware node.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should be "raspberrypi,firmware-gpio"
|
||||
- gpio-controller : Marks the device node as a gpio controller
|
||||
- #gpio-cells : Should be two. The first cell is the pin number, and
|
||||
the second cell is used to specify the gpio polarity:
|
||||
0 = active high
|
||||
1 = active low
|
||||
|
||||
Example:
|
||||
|
||||
firmware: firmware-rpi {
|
||||
compatible = "raspberrypi,bcm2835-firmware";
|
||||
mboxes = <&mailbox>;
|
||||
|
||||
expgpio: gpio {
|
||||
compatible = "raspberrypi,firmware-gpio";
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
};
|
||||
@ -1,38 +0,0 @@
|
||||
TI ADC128D818 ADC System Monitor With Temperature Sensor
|
||||
--------------------------------------------------------
|
||||
|
||||
Operation modes:
|
||||
|
||||
- Mode 0: 7 single-ended voltage readings (IN0-IN6),
|
||||
1 temperature reading (internal)
|
||||
- Mode 1: 8 single-ended voltage readings (IN0-IN7),
|
||||
no temperature
|
||||
- Mode 2: 4 pseudo-differential voltage readings
|
||||
(IN0-IN1, IN3-IN2, IN4-IN5, IN7-IN6),
|
||||
1 temperature reading (internal)
|
||||
- Mode 3: 4 single-ended voltage readings (IN0-IN3),
|
||||
2 pseudo-differential voltage readings
|
||||
(IN4-IN5, IN7-IN6),
|
||||
1 temperature reading (internal)
|
||||
|
||||
If no operation mode is configured via device tree, the driver keeps the
|
||||
currently active chip operation mode (default is mode 0).
|
||||
|
||||
|
||||
Required node properties:
|
||||
|
||||
- compatible: must be set to "ti,adc128d818"
|
||||
- reg: I2C address of the device
|
||||
|
||||
Optional node properties:
|
||||
|
||||
- ti,mode: Operation mode (u8) (see above).
|
||||
|
||||
|
||||
Example (operation mode 2):
|
||||
|
||||
adc128d818@1d {
|
||||
compatible = "ti,adc128d818";
|
||||
reg = <0x1d>;
|
||||
ti,mode = /bits/ 8 <2>;
|
||||
};
|
||||
@ -5,7 +5,7 @@
|
||||
$id: http://devicetree.org/schemas/hwmon/adi,adm1275.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Analog Devices ADM1075/ADM127x/ADM129x digital power monitors
|
||||
title: Analog Devices ADM1075/ADM127x/ADM1281/ADM129x digital power monitors
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzk@kernel.org>
|
||||
@ -27,6 +27,7 @@ properties:
|
||||
- adi,adm1275
|
||||
- adi,adm1276
|
||||
- adi,adm1278
|
||||
- adi,adm1281
|
||||
- adi,adm1293
|
||||
- adi,adm1294
|
||||
|
||||
@ -91,6 +92,7 @@ allOf:
|
||||
contains:
|
||||
enum:
|
||||
- adi,adm1278
|
||||
- adi,adm1281
|
||||
- adi,adm1293
|
||||
- adi,adm1294
|
||||
then:
|
||||
|
||||
@ -1,11 +0,0 @@
|
||||
Bindings for Synaptics AS370 PVT sensors
|
||||
|
||||
Required properties:
|
||||
- compatible : "syna,as370-hwmon"
|
||||
- reg : address and length of the register set.
|
||||
|
||||
Example:
|
||||
hwmon@ea0810 {
|
||||
compatible = "syna,as370-hwmon";
|
||||
reg = <0xea0810 0xc>;
|
||||
};
|
||||
37
Documentation/devicetree/bindings/hwmon/ibm,opal-sensor.yaml
Normal file
37
Documentation/devicetree/bindings/hwmon/ibm,opal-sensor.yaml
Normal file
@ -0,0 +1,37 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwmon/ibm,opal-sensor.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: IBM POWERNV platform sensors
|
||||
|
||||
maintainers:
|
||||
- Javier Carrasco <javier.carrasco.cruz@gmail.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ibm,opal-sensor-cooling-fan
|
||||
- ibm,opal-sensor-amb-temp
|
||||
- ibm,opal-sensor-power-supply
|
||||
- ibm,opal-sensor-power
|
||||
|
||||
sensor-id:
|
||||
description:
|
||||
An opaque id provided by the firmware to the kernel, identifies a
|
||||
given sensor and its attribute data.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- sensor-id
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
sensor {
|
||||
compatible = "ibm,opal-sensor-cooling-fan";
|
||||
sensor-id = <0x7052107>;
|
||||
};
|
||||
@ -1,25 +0,0 @@
|
||||
Device-tree bindings for I2C-based On-Chip Controller hwmon device
|
||||
------------------------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible = "ibm,p8-occ-hwmon";
|
||||
- reg = <I2C address>; : I2C bus address
|
||||
|
||||
Examples:
|
||||
|
||||
i2c-bus@100 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
clock-frequency = <100000>;
|
||||
< more properties >
|
||||
|
||||
occ-hwmon@1 {
|
||||
compatible = "ibm,p8-occ-hwmon";
|
||||
reg = <0x50>;
|
||||
};
|
||||
|
||||
occ-hwmon@2 {
|
||||
compatible = "ibm,p8-occ-hwmon";
|
||||
reg = <0x51>;
|
||||
};
|
||||
};
|
||||
@ -1,23 +0,0 @@
|
||||
IBM POWERNV platform sensors
|
||||
----------------------------
|
||||
|
||||
Required node properties:
|
||||
- compatible: must be one of
|
||||
"ibm,opal-sensor-cooling-fan"
|
||||
"ibm,opal-sensor-amb-temp"
|
||||
"ibm,opal-sensor-power-supply"
|
||||
"ibm,opal-sensor-power"
|
||||
- sensor-id: an opaque id provided by the firmware to the kernel, identifies a
|
||||
given sensor and its attribute data
|
||||
|
||||
Example sensors node:
|
||||
|
||||
cooling-fan#8-data {
|
||||
sensor-id = <0x7052107>;
|
||||
compatible = "ibm,opal-sensor-cooling-fan";
|
||||
};
|
||||
|
||||
amb-temp#1-thrs {
|
||||
sensor-id = <0x5096000>;
|
||||
compatible = "ibm,opal-sensor-amb-temp";
|
||||
};
|
||||
@ -1,30 +0,0 @@
|
||||
*LM87 hwmon sensor.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be
|
||||
"ti,lm87"
|
||||
|
||||
- reg: I2C address
|
||||
|
||||
optional properties:
|
||||
- has-temp3: This configures pins 18 and 19 to be used as a second
|
||||
remote temperature sensing channel. By default the pins
|
||||
are configured as voltage input pins in0 and in5.
|
||||
|
||||
- has-in6: When set, pin 5 is configured to be used as voltage input
|
||||
in6. Otherwise the pin is set as FAN1 input.
|
||||
|
||||
- has-in7: When set, pin 6 is configured to be used as voltage input
|
||||
in7. Otherwise the pin is set as FAN2 input.
|
||||
|
||||
- vcc-supply: a Phandle for the regulator supplying power, can be
|
||||
configured to measure 5.0V power supply. Default is 3.3V.
|
||||
|
||||
Example:
|
||||
|
||||
lm87@2e {
|
||||
compatible = "ti,lm87";
|
||||
reg = <0x2e>;
|
||||
has-temp3;
|
||||
vcc-supply = <®_5v0>;
|
||||
};
|
||||
@ -1,28 +0,0 @@
|
||||
Bindings for MAX6651 and MAX6650 I2C fan controllers
|
||||
|
||||
Reference:
|
||||
[1] https://datasheets.maximintegrated.com/en/ds/MAX6650-MAX6651.pdf
|
||||
|
||||
Required properties:
|
||||
- compatible : One of "maxim,max6650" or "maxim,max6651"
|
||||
- reg : I2C address, one of 0x1b, 0x1f, 0x4b, 0x48.
|
||||
|
||||
Optional properties, default is to retain the chip's current setting:
|
||||
- maxim,fan-microvolt : The supply voltage of the fan, either 5000000 uV or
|
||||
12000000 uV.
|
||||
- maxim,fan-prescale : Pre-scaling value, as per datasheet [1]. Lower values
|
||||
allow more fine-grained control of slower fans.
|
||||
Valid: 1, 2, 4, 8, 16.
|
||||
- maxim,fan-target-rpm: Initial requested fan rotation speed. If specified, the
|
||||
driver selects closed-loop mode and the requested speed.
|
||||
This ensures the fan is already running before userspace
|
||||
takes over.
|
||||
|
||||
Example:
|
||||
fan-max6650: max6650@1b {
|
||||
reg = <0x1b>;
|
||||
compatible = "maxim,max6650";
|
||||
maxim,fan-microvolt = <12000000>;
|
||||
maxim,fan-prescale = <4>;
|
||||
maxim,fan-target-rpm = <1200>;
|
||||
};
|
||||
70
Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml
Normal file
70
Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml
Normal file
@ -0,0 +1,70 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
|
||||
$id: http://devicetree.org/schemas/hwmon/maxim,max6650.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Maxim MAX6650 and MAX6651 I2C Fan Controllers
|
||||
|
||||
maintainers:
|
||||
- Javier Carrasco <javier.carrasco.cruz@gmail.com>
|
||||
|
||||
description: |
|
||||
The MAX6650 and MAX6651 regulate and monitor the speed
|
||||
of 5VDC/12VDC burshless fans with built-in tachometers.
|
||||
|
||||
Datasheets:
|
||||
https://datasheets.maximintegrated.com/en/ds/MAX6650-MAX6651.pdf
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- maxim,max6650
|
||||
- maxim,max6651
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
maxim,fan-microvolt:
|
||||
description:
|
||||
The supply voltage of the fan, either 5000000 uV or
|
||||
12000000 uV.
|
||||
enum: [5000000, 12000000]
|
||||
|
||||
maxim,fan-prescale:
|
||||
description:
|
||||
Pre-scaling value, as per datasheet. Lower values
|
||||
allow more fine-grained control of slower fans.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [1, 2, 4, 8, 16]
|
||||
|
||||
maxim,fan-target-rpm:
|
||||
description:
|
||||
Initial requested fan rotation speed. If specified, the
|
||||
driver selects closed-loop mode and the requested speed.
|
||||
This ensures the fan is already running before userspace
|
||||
takes over.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
maximum: 30000
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
fan-controller@1b {
|
||||
compatible = "maxim,max6650";
|
||||
reg = <0x1b>;
|
||||
maxim,fan-microvolt = <12000000>;
|
||||
maxim,fan-prescale = <4>;
|
||||
maxim,fan-target-rpm = <1200>;
|
||||
};
|
||||
};
|
||||
@ -0,0 +1,49 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwmon/pmbus/adi,adp1050.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Analog Devices ADP1050 digital controller with PMBus interface
|
||||
|
||||
maintainers:
|
||||
- Radu Sabau <radu.sabau@analog.com>
|
||||
|
||||
description: |
|
||||
The ADP1050 is used to monitor system voltages, currents and temperatures.
|
||||
Through the PMBus interface, the ADP1050 targets isolated power supplies
|
||||
and has four individual monitors for input/output voltage, input current
|
||||
and temperature.
|
||||
Datasheet:
|
||||
https://www.analog.com/en/products/adp1050.html
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: adi,adp1050
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
vcc-supply: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- vcc-supply
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
clock-frequency = <100000>;
|
||||
|
||||
hwmon@70 {
|
||||
compatible = "adi,adp1050";
|
||||
reg = <0x70>;
|
||||
vcc-supply = <&vcc>;
|
||||
};
|
||||
};
|
||||
...
|
||||
@ -1 +0,0 @@
|
||||
This file has moved to pwm-fan.yaml.
|
||||
41
Documentation/devicetree/bindings/hwmon/st,stts751.yaml
Normal file
41
Documentation/devicetree/bindings/hwmon/st,stts751.yaml
Normal file
@ -0,0 +1,41 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwmon/st,stts751.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: STTS751 Thermometer
|
||||
|
||||
maintainers:
|
||||
- Javier Carrasco <javier.carrasco.cruz@gmail.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: st,stts751
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
smbus-timeout-disable:
|
||||
description:
|
||||
When set, the smbus timeout function will be disabled.
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
thermometer@48 {
|
||||
compatible = "st,stts751";
|
||||
reg = <0x48>;
|
||||
smbus-timeout-disable;
|
||||
};
|
||||
};
|
||||
@ -1,15 +0,0 @@
|
||||
* STTS751 thermometer.
|
||||
|
||||
Required node properties:
|
||||
- compatible: "stts751"
|
||||
- reg: I2C bus address of the device
|
||||
|
||||
Optional properties:
|
||||
- smbus-timeout-disable: when set, the smbus timeout function will be disabled
|
||||
|
||||
Example stts751 node:
|
||||
|
||||
temp-sensor {
|
||||
compatible = "stts751";
|
||||
reg = <0x48>;
|
||||
}
|
||||
32
Documentation/devicetree/bindings/hwmon/syna,as370.yaml
Normal file
32
Documentation/devicetree/bindings/hwmon/syna,as370.yaml
Normal file
@ -0,0 +1,32 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwmon/syna,as370.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Synaptics AS370 PVT sensors
|
||||
|
||||
maintainers:
|
||||
- Javier Carrasco <javier.carrasco.cruz@gmail.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: syna,as370-hwmon
|
||||
|
||||
reg:
|
||||
description:
|
||||
Address and length of the register set.
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
sensor@ea0810 {
|
||||
compatible = "syna,as370-hwmon";
|
||||
reg = <0xea0810 0xc>;
|
||||
};
|
||||
63
Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml
Normal file
63
Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml
Normal file
@ -0,0 +1,63 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
|
||||
$id: http://devicetree.org/schemas/hwmon/ti,adc128d818.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Texas Instruments ADC128D818 ADC System Monitor With Temperature Sensor
|
||||
|
||||
maintainers:
|
||||
- Javier Carrasco <javier.carrasco.cruz@gmail.com>
|
||||
|
||||
description: |
|
||||
The ADC128D818 is a 12-Bit, 8-Channel Analog to Digital Converter (ADC)
|
||||
with a temperature sensor and an I2C interface.
|
||||
|
||||
Datasheets:
|
||||
https://www.ti.com/product/ADC128D818
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: ti,adc128d818
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
ti,mode:
|
||||
$ref: /schemas/types.yaml#/definitions/uint8
|
||||
description: |
|
||||
Operation mode.
|
||||
Mode 0 - 7 single-ended voltage readings (IN0-IN6), 1 temperature
|
||||
reading (internal).
|
||||
Mode 1 - 8 single-ended voltage readings (IN0-IN7), no temperature.
|
||||
Mode 2 - 4 pseudo-differential voltage readings
|
||||
(IN0-IN1, IN3-IN2, IN4-IN5, IN7-IN6), 1 temperature reading (internal).
|
||||
Mode 3 - 4 single-ended voltage readings (IN0-IN3), 2 pseudo-differential
|
||||
voltage readings (IN4-IN5, IN7-IN6), 1 temperature reading (internal).
|
||||
default: 0
|
||||
|
||||
vref-supply:
|
||||
description:
|
||||
The regulator to use as an external reference. If it does not exist, the
|
||||
internal reference will be used.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
adc@1d {
|
||||
compatible = "ti,adc128d818";
|
||||
reg = <0x1d>;
|
||||
vref-supply = <&vref>;
|
||||
ti,mode = /bits/ 8 <2>;
|
||||
};
|
||||
};
|
||||
69
Documentation/devicetree/bindings/hwmon/ti,lm87.yaml
Normal file
69
Documentation/devicetree/bindings/hwmon/ti,lm87.yaml
Normal file
@ -0,0 +1,69 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
|
||||
$id: http://devicetree.org/schemas/hwmon/ti,lm87.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Texas Instruments LM87 Hardware Monitor
|
||||
|
||||
maintainers:
|
||||
- Javier Carrasco <javier.carrasco.cruz@gmail.com>
|
||||
|
||||
description: |
|
||||
The LM87 is a serial interface system hardware monitor
|
||||
with remote diode temperature sensing.
|
||||
|
||||
Datasheets:
|
||||
https://www.ti.com/product/LM87
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: ti,lm87
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
has-temp3:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
This configures pins 18 and 19 to be used as a second
|
||||
remote temperature sensing channel. By default the pins
|
||||
are configured as voltage input pins in0 and in5.
|
||||
|
||||
has-in6:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
When set, pin 5 is configured to be used as voltage input
|
||||
in6. Otherwise the pin is set as FAN1 input.
|
||||
|
||||
has-in7:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
When set, pin 6 is configured to be used as voltage input
|
||||
in7. Otherwise the pin is set as FAN2 input.
|
||||
|
||||
vcc-supply:
|
||||
description:
|
||||
Regulator supplying power, can be configured to measure
|
||||
5.0V power supply. Default is 3.3V.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
hwmon@2e {
|
||||
compatible = "ti,lm87";
|
||||
reg = <0x2e>;
|
||||
has-temp3;
|
||||
vcc-supply = <®_5v0>;
|
||||
};
|
||||
};
|
||||
@ -127,6 +127,10 @@ properties:
|
||||
|
||||
wakeup-source: true
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -93,6 +93,10 @@ properties:
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
|
||||
@ -59,6 +59,10 @@ properties:
|
||||
If not, SPI CLKOUT frequency will not be accurate.
|
||||
maximum: 20000000
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -45,6 +45,10 @@ properties:
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
|
||||
@ -0,0 +1,172 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/interrupt-controller/riscv,aplic.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: RISC-V Advanced Platform Level Interrupt Controller (APLIC)
|
||||
|
||||
maintainers:
|
||||
- Anup Patel <anup@brainfault.org>
|
||||
|
||||
description:
|
||||
The RISC-V advanced interrupt architecture (AIA) defines an advanced
|
||||
platform level interrupt controller (APLIC) for handling wired interrupts
|
||||
in a RISC-V platform. The RISC-V AIA specification can be found at
|
||||
https://github.com/riscv/riscv-aia.
|
||||
|
||||
The RISC-V APLIC is implemented as hierarchical APLIC domains where all
|
||||
interrupt sources connect to the root APLIC domain and a parent APLIC
|
||||
domain can delegate interrupt sources to it's child APLIC domains. There
|
||||
is one device tree node for each APLIC domain.
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/interrupt-controller.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- qemu,aplic
|
||||
- const: riscv,aplic
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
"#interrupt-cells":
|
||||
const: 2
|
||||
|
||||
interrupts-extended:
|
||||
minItems: 1
|
||||
maxItems: 16384
|
||||
description:
|
||||
Given APLIC domain directly injects external interrupts to a set of
|
||||
RISC-V HARTS (or CPUs). Each node pointed to should be a riscv,cpu-intc
|
||||
node, which has a CPU node (i.e. RISC-V HART) as parent.
|
||||
|
||||
msi-parent:
|
||||
description:
|
||||
Given APLIC domain forwards wired interrupts as MSIs to a AIA incoming
|
||||
message signaled interrupt controller (IMSIC). If both "msi-parent" and
|
||||
"interrupts-extended" properties are present then it means the APLIC
|
||||
domain supports both MSI mode and Direct mode in HW. In this case, the
|
||||
APLIC driver has to choose between MSI mode or Direct mode.
|
||||
|
||||
riscv,num-sources:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 1
|
||||
maximum: 1023
|
||||
description:
|
||||
Specifies the number of wired interrupt sources supported by this
|
||||
APLIC domain.
|
||||
|
||||
riscv,children:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
minItems: 1
|
||||
maxItems: 1024
|
||||
items:
|
||||
maxItems: 1
|
||||
description:
|
||||
A list of child APLIC domains for the given APLIC domain. Each child
|
||||
APLIC domain is assigned a child index in increasing order, with the
|
||||
first child APLIC domain assigned child index 0. The APLIC domain child
|
||||
index is used by firmware to delegate interrupts from the given APLIC
|
||||
domain to a particular child APLIC domain.
|
||||
|
||||
riscv,delegation:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
minItems: 1
|
||||
maxItems: 1024
|
||||
items:
|
||||
items:
|
||||
- description: child APLIC domain phandle
|
||||
- description: first interrupt number of the parent APLIC domain (inclusive)
|
||||
- description: last interrupt number of the parent APLIC domain (inclusive)
|
||||
description:
|
||||
A interrupt delegation list where each entry is a triple consisting
|
||||
of child APLIC domain phandle, first interrupt number of the parent
|
||||
APLIC domain, and last interrupt number of the parent APLIC domain.
|
||||
Firmware must configure interrupt delegation registers based on
|
||||
interrupt delegation list.
|
||||
|
||||
dependencies:
|
||||
riscv,delegation: [ "riscv,children" ]
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupt-controller
|
||||
- "#interrupt-cells"
|
||||
- riscv,num-sources
|
||||
|
||||
anyOf:
|
||||
- required:
|
||||
- interrupts-extended
|
||||
- required:
|
||||
- msi-parent
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
// Example 1 (APLIC domains directly injecting interrupt to HARTs):
|
||||
|
||||
interrupt-controller@c000000 {
|
||||
compatible = "qemu,aplic", "riscv,aplic";
|
||||
interrupts-extended = <&cpu1_intc 11>,
|
||||
<&cpu2_intc 11>,
|
||||
<&cpu3_intc 11>,
|
||||
<&cpu4_intc 11>;
|
||||
reg = <0xc000000 0x4080>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
riscv,num-sources = <63>;
|
||||
riscv,children = <&aplic1>, <&aplic2>;
|
||||
riscv,delegation = <&aplic1 1 63>;
|
||||
};
|
||||
|
||||
aplic1: interrupt-controller@d000000 {
|
||||
compatible = "qemu,aplic", "riscv,aplic";
|
||||
interrupts-extended = <&cpu1_intc 9>,
|
||||
<&cpu2_intc 9>;
|
||||
reg = <0xd000000 0x4080>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
riscv,num-sources = <63>;
|
||||
};
|
||||
|
||||
aplic2: interrupt-controller@e000000 {
|
||||
compatible = "qemu,aplic", "riscv,aplic";
|
||||
interrupts-extended = <&cpu3_intc 9>,
|
||||
<&cpu4_intc 9>;
|
||||
reg = <0xe000000 0x4080>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
riscv,num-sources = <63>;
|
||||
};
|
||||
|
||||
- |
|
||||
// Example 2 (APLIC domains forwarding interrupts as MSIs):
|
||||
|
||||
interrupt-controller@c000000 {
|
||||
compatible = "qemu,aplic", "riscv,aplic";
|
||||
msi-parent = <&imsic_mlevel>;
|
||||
reg = <0xc000000 0x4000>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
riscv,num-sources = <63>;
|
||||
riscv,children = <&aplic3>;
|
||||
riscv,delegation = <&aplic3 1 63>;
|
||||
};
|
||||
|
||||
aplic3: interrupt-controller@d000000 {
|
||||
compatible = "qemu,aplic", "riscv,aplic";
|
||||
msi-parent = <&imsic_slevel>;
|
||||
reg = <0xd000000 0x4000>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
riscv,num-sources = <63>;
|
||||
};
|
||||
...
|
||||
@ -0,0 +1,172 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/interrupt-controller/riscv,imsics.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: RISC-V Incoming MSI Controller (IMSIC)
|
||||
|
||||
maintainers:
|
||||
- Anup Patel <anup@brainfault.org>
|
||||
|
||||
description: |
|
||||
The RISC-V advanced interrupt architecture (AIA) defines a per-CPU incoming
|
||||
MSI controller (IMSIC) for handling MSIs in a RISC-V platform. The RISC-V
|
||||
AIA specification can be found at https://github.com/riscv/riscv-aia.
|
||||
|
||||
The IMSIC is a per-CPU (or per-HART) device with separate interrupt file
|
||||
for each privilege level (machine or supervisor). The configuration of
|
||||
a IMSIC interrupt file is done using AIA CSRs and it also has a 4KB MMIO
|
||||
space to receive MSIs from devices. Each IMSIC interrupt file supports a
|
||||
fixed number of interrupt identities (to distinguish MSIs from devices)
|
||||
which is same for given privilege level across CPUs (or HARTs).
|
||||
|
||||
The device tree of a RISC-V platform will have one IMSIC device tree node
|
||||
for each privilege level (machine or supervisor) which collectively describe
|
||||
IMSIC interrupt files at that privilege level across CPUs (or HARTs).
|
||||
|
||||
The arrangement of IMSIC interrupt files in MMIO space of a RISC-V platform
|
||||
follows a particular scheme defined by the RISC-V AIA specification. A IMSIC
|
||||
group is a set of IMSIC interrupt files co-located in MMIO space and we can
|
||||
have multiple IMSIC groups (i.e. clusters, sockets, chiplets, etc) in a
|
||||
RISC-V platform. The MSI target address of a IMSIC interrupt file at given
|
||||
privilege level (machine or supervisor) encodes group index, HART index,
|
||||
and guest index (shown below).
|
||||
|
||||
XLEN-1 > (HART Index MSB) 12 0
|
||||
| | | |
|
||||
-------------------------------------------------------------
|
||||
|xxxxxx|Group Index|xxxxxxxxxxx|HART Index|Guest Index| 0 |
|
||||
-------------------------------------------------------------
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/interrupt-controller.yaml#
|
||||
- $ref: /schemas/interrupt-controller/msi-controller.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- qemu,imsics
|
||||
- const: riscv,imsics
|
||||
|
||||
reg:
|
||||
minItems: 1
|
||||
maxItems: 16384
|
||||
description:
|
||||
Base address of each IMSIC group.
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
"#interrupt-cells":
|
||||
const: 0
|
||||
|
||||
msi-controller: true
|
||||
|
||||
"#msi-cells":
|
||||
const: 0
|
||||
|
||||
interrupts-extended:
|
||||
minItems: 1
|
||||
maxItems: 16384
|
||||
description:
|
||||
This property represents the set of CPUs (or HARTs) for which given
|
||||
device tree node describes the IMSIC interrupt files. Each node pointed
|
||||
to should be a riscv,cpu-intc node, which has a CPU node (i.e. RISC-V
|
||||
HART) as parent.
|
||||
|
||||
riscv,num-ids:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 63
|
||||
maximum: 2047
|
||||
description:
|
||||
Number of interrupt identities supported by IMSIC interrupt file.
|
||||
|
||||
riscv,num-guest-ids:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 63
|
||||
maximum: 2047
|
||||
description:
|
||||
Number of interrupt identities are supported by IMSIC guest interrupt
|
||||
file. When not specified it is assumed to be same as specified by the
|
||||
riscv,num-ids property.
|
||||
|
||||
riscv,guest-index-bits:
|
||||
minimum: 0
|
||||
maximum: 7
|
||||
default: 0
|
||||
description:
|
||||
Number of guest index bits in the MSI target address.
|
||||
|
||||
riscv,hart-index-bits:
|
||||
minimum: 0
|
||||
maximum: 15
|
||||
description:
|
||||
Number of HART index bits in the MSI target address. When not
|
||||
specified it is calculated based on the interrupts-extended property.
|
||||
|
||||
riscv,group-index-bits:
|
||||
minimum: 0
|
||||
maximum: 7
|
||||
default: 0
|
||||
description:
|
||||
Number of group index bits in the MSI target address.
|
||||
|
||||
riscv,group-index-shift:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 0
|
||||
maximum: 55
|
||||
default: 24
|
||||
description:
|
||||
The least significant bit position of the group index bits in the
|
||||
MSI target address.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupt-controller
|
||||
- msi-controller
|
||||
- "#msi-cells"
|
||||
- interrupts-extended
|
||||
- riscv,num-ids
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
// Example 1 (Machine-level IMSIC files with just one group):
|
||||
|
||||
interrupt-controller@24000000 {
|
||||
compatible = "qemu,imsics", "riscv,imsics";
|
||||
interrupts-extended = <&cpu1_intc 11>,
|
||||
<&cpu2_intc 11>,
|
||||
<&cpu3_intc 11>,
|
||||
<&cpu4_intc 11>;
|
||||
reg = <0x28000000 0x4000>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <0>;
|
||||
msi-controller;
|
||||
#msi-cells = <0>;
|
||||
riscv,num-ids = <127>;
|
||||
};
|
||||
|
||||
- |
|
||||
// Example 2 (Supervisor-level IMSIC files with two groups):
|
||||
|
||||
interrupt-controller@28000000 {
|
||||
compatible = "qemu,imsics", "riscv,imsics";
|
||||
interrupts-extended = <&cpu1_intc 9>,
|
||||
<&cpu2_intc 9>,
|
||||
<&cpu3_intc 9>,
|
||||
<&cpu4_intc 9>;
|
||||
reg = <0x28000000 0x2000>, /* Group0 IMSICs */
|
||||
<0x29000000 0x2000>; /* Group1 IMSICs */
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <0>;
|
||||
msi-controller;
|
||||
#msi-cells = <0>;
|
||||
riscv,num-ids = <127>;
|
||||
riscv,group-index-bits = <1>;
|
||||
riscv,group-index-shift = <24>;
|
||||
};
|
||||
...
|
||||
@ -89,8 +89,23 @@ examples:
|
||||
reg = <0x5000d000 0x400>;
|
||||
};
|
||||
|
||||
- |
|
||||
//Example 2
|
||||
exti2: interrupt-controller@40013c00 {
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
exti2: interrupt-controller@5000d000 {
|
||||
compatible = "st,stm32mp1-exti", "syscon";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
reg = <0x5000d000 0x400>;
|
||||
interrupts-extended =
|
||||
<&intc GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<0>,
|
||||
<&intc GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
||||
|
||||
- |
|
||||
//Example 3
|
||||
exti3: interrupt-controller@40013c00 {
|
||||
compatible = "st,stm32-exti";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
@ -29,6 +29,10 @@ properties:
|
||||
- const: cec
|
||||
- const: hdmi-cec
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -36,6 +36,10 @@ properties:
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
port:
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
unevaluatedProperties: false
|
||||
|
||||
@ -30,6 +30,10 @@ properties:
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@ -0,0 +1,33 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/memory-controllers/samsung,s5pv210-dmc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung S5Pv210 SoC Dynamic Memory Controller
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzk@kernel.org>
|
||||
|
||||
description:
|
||||
Dynamic Memory Controller interfaces external JEDEC DDR-type SDRAM.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: samsung,s5pv210-dmc
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
memory-controller@f0000000 {
|
||||
compatible = "samsung,s5pv210-dmc";
|
||||
reg = <0xf0000000 0x1000>;
|
||||
};
|
||||
@ -50,6 +50,10 @@ properties:
|
||||
Reflects the memory layout with four integer values per bank. Format:
|
||||
<bank-number> 0 <address of the bank> <size>
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
patternProperties:
|
||||
"^.*@[0-4],[a-f0-9]+$":
|
||||
additionalProperties: true
|
||||
|
||||
@ -44,6 +44,10 @@ properties:
|
||||
|
||||
wakeup-source: true
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
pwm:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
@ -67,6 +67,10 @@ properties:
|
||||
"#size-cells":
|
||||
const: 0
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
pwm:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
@ -83,6 +83,7 @@ allOf:
|
||||
enum:
|
||||
- x-powers,axp313a
|
||||
- x-powers,axp15060
|
||||
- x-powers,axp717
|
||||
|
||||
then:
|
||||
properties:
|
||||
@ -99,6 +100,7 @@ properties:
|
||||
- x-powers,axp221
|
||||
- x-powers,axp223
|
||||
- x-powers,axp313a
|
||||
- x-powers,axp717
|
||||
- x-powers,axp803
|
||||
- x-powers,axp806
|
||||
- x-powers,axp809
|
||||
|
||||
@ -79,6 +79,10 @@ properties:
|
||||
- const: rx
|
||||
- const: tx
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
power-domains: true
|
||||
|
||||
resets:
|
||||
|
||||
56
Documentation/devicetree/bindings/net/airoha,en8811h.yaml
Normal file
56
Documentation/devicetree/bindings/net/airoha,en8811h.yaml
Normal file
@ -0,0 +1,56 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/airoha,en8811h.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Airoha EN8811H PHY
|
||||
|
||||
maintainers:
|
||||
- Eric Woudstra <ericwouds@gmail.com>
|
||||
|
||||
description:
|
||||
The Airoha EN8811H PHY has the ability to reverse polarity
|
||||
on the lines to and/or from the MAC. It is reversed by
|
||||
the booleans in the devicetree node of the phy.
|
||||
|
||||
allOf:
|
||||
- $ref: ethernet-phy.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ethernet-phy-id03a2.a411
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
airoha,pnswap-rx:
|
||||
type: boolean
|
||||
description:
|
||||
Reverse rx polarity of the SERDES. This is the receiving
|
||||
side of the lines from the MAC towards the EN881H.
|
||||
|
||||
airoha,pnswap-tx:
|
||||
type: boolean
|
||||
description:
|
||||
Reverse tx polarity of SERDES. This is the transmitting
|
||||
side of the lines from EN8811H towards the MAC.
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
mdio {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
ethernet-phy@1 {
|
||||
compatible = "ethernet-phy-id03a2.a411";
|
||||
reg = <1>;
|
||||
airoha,pnswap-rx;
|
||||
};
|
||||
};
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user