+The cxl driver was removed in 6.15.

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: February 2015, removed February 2025

+Date: February 2015, removed February 2025

+Date: February 2015, removed February 2025

+Date: February 2015, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: September 2014, removed February 2025

+Date: December 2014, removed February 2025

+Date: October 2014, removed February 2025

+Date: July 2015, removed February 2025

+Date: March 2016, removed February 2025

+Date: May 2018, removed February 2025

+What: /sys/devices/system/node/nodeX/memory_side_cache/indexY/address_mode

+Date: March 2025

+Contact: Dave Jiang <dave.jiang@intel.com>

+Description:

+ The address mode: 0 for reserved, 1 for extended-linear.

+

+

+What: /sys/bus/coresight/devices/<tpdm-name>/mcmb_trig_lane

+Date: Feb 2025

+KernelVersion 6.15

+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>

+Description:

+ (RW) Set/Get which lane participates in the output pattern

+ match cross trigger mechanism for the MCMB subunit TPDM.

+

+What: /sys/bus/coresight/devices/<tpdm-name>/mcmb_lanes_select

+Date: Feb 2025

+KernelVersion 6.15

+Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>

+Description:

+ (RW) Set/Get the enablement of the individual lane.

+What: /sys/bus/counter/devices/counterX/countY/compare

+KernelVersion: 6.15

+Contact: linux-iio@vger.kernel.org

+Description:

+ If the counter device supports compare registers -- registers

+ used to compare counter channels against a particular count --

+ the compare count for channel Y is provided by this attribute.

+

+What: /sys/bus/counter/devices/counterX/countY/compare_component_id

+Date: January, 2022

+What: /sys/bus/cxl/devices/memX/payload_max

+Date: December, 2020

+KernelVersion: v5.12

+Contact: linux-cxl@vger.kernel.org

+Description:

+ (RO) Maximum size (in bytes) of the mailbox command payload

+ registers. Linux caps this at 1MB if the device reports a

+ larger size.

+

+

+What: /sys/bus/cxl/devices/memX/label_storage_size

+Date: May, 2021

+KernelVersion: v5.13

+Contact: linux-cxl@vger.kernel.org

+Description:

+ (RO) Size (in bytes) of the Label Storage Area (LSA).

+

+

+ (RO) For CXL host platforms that support "QoS Telemetry"

+ (RO) For CXL host platforms that support "QoS Telemetry"

+ translates from a host physical address range, to a device

+ local address range. Device-local address ranges are further

+ split into a 'ram' (volatile memory) range and 'pmem'

+ (persistent memory) range. The 'mode' attribute emits one of

+ 'ram', 'pmem', or 'none'. The 'none' indicates the decoder is

+ not actively decoding, or no DPA allocation policy has been

+ set.

+ (RO) For CXL host platforms that support "QoS Telemetry" this

+

+

+What: /sys/bus/cxl/devices/nvdimm-bridge0/ndbusX/nmemY/cxl/dirty_shutdown

+Date: Feb, 2025

+KernelVersion: v6.15

+Contact: linux-cxl@vger.kernel.org

+Description:

+ (RO) The device dirty shutdown count value, which is the number

+ of times the device could have incurred in potential data loss.

+ The count is persistent across power loss and wraps back to 0

+ upon overflow. If this file is not present, the device does not

+ have the necessary support for dirty tracking.

+What: /sys/bus/iio/devices/iio:deviceX/in_voltage-voltage_filter_type_available

+ * "wideband" - filter with wideband low ripple passband

+ and sharp transition band.

+

+What: /sys/bus/iio/devices/iio:deviceX/filter_type

+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_filter_type

+KernelVersion: 6.1

+Contact: linux-iio@vger.kernel.org

+Description:

+ Specifies which filter type apply to the channel. The possible

+ values are given by the filter_type_available attribute.

+What: /sys/bus/iio/devices/iio:deviceX/in_voltage-voltage_filter_mode_available

+KernelVersion: 6.2

+Contact: linux-iio@vger.kernel.org

+Description:

+ Reading returns a list with the possible filter modes.

+

+ This ABI is only kept for backwards compatibility and the values

+ returned are identical to filter_type_available attribute

+ documented in Documentation/ABI/testing/sysfs-bus-iio. Please,

+ use filter_type_available like ABI to provide filter options for

+ new drivers.

+

+What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_filter_mode

+KernelVersion: 6.2

+Contact: linux-iio@vger.kernel.org

+Description:

+ This ABI is only kept for backwards compatibility and the values

+ returned are identical to in_voltageY-voltageZ_filter_type

+ attribute documented in Documentation/ABI/testing/sysfs-bus-iio.

+ Please, use in_voltageY-voltageZ_filter_type for new drivers.

+Contact: Peter Colberg <peter.colberg@altera.com>

+Contact: Peter Colberg <peter.colberg@altera.com>

+Contact: Peter Colberg <peter.colberg@altera.com>

+Contact: Peter Colberg <peter.colberg@altera.com>

+Contact: Peter Colberg <peter.colberg@altera.com>

+Contact: Peter Colberg <peter.colberg@altera.com>

+Contact: Peter Colberg <peter.colberg@altera.com>

+Contact: Peter Colberg <peter.colberg@altera.com>

+Contact: Peter Colberg <peter.colberg@altera.com>

+

+What: /sys/kernel/mm/cma/<cma-heap-name>/total_pages

+Date: Jun 2024

+Contact: Frank van der Linden <fvdl@google.com>

+Description:

+ The size of the CMA area in pages.

+

+What: /sys/kernel/mm/cma/<cma-heap-name>/available_pages

+Date: Jun 2024

+Contact: Frank van der Linden <fvdl@google.com>

+Description:

+ The number of pages in the CMA area that are still

+ available for CMA allocation.

+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/intrvals_goal/access_bp

+Date: Feb 2025

+Contact: SeongJae Park <sj@kernel.org>

+Description: Writing a value to this file sets the monitoring intervals

+ auto-tuning target DAMON-observed access events ratio within

+ the given time interval (aggrs in same directory), in bp

+ (1/10,000). Reading this file returns the value.

+

+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/intrvals_goal/aggrs

+Date: Feb 2025

+Contact: SeongJae Park <sj@kernel.org>

+Description: Writing a value to this file sets the time interval to achieve

+ the monitoring intervals auto-tuning target DAMON-observed

+ access events ratio (access_bp in same directory) within.

+ Reading this file returns the value.

+

+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/intrvals_goal/min_sample_us

+Date: Feb 2025

+Contact: SeongJae Park <sj@kernel.org>

+Description: Writing a value to this file sets the minimum value of

+ auto-tuned sampling interval in microseconds. Reading this

+ file returns the value.

+

+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/intrvals_goal/max_sample_us

+Date: Feb 2025

+Contact: SeongJae Park <sj@kernel.org>

+Description: Writing a value to this file sets the maximum value of

+ auto-tuned sampling interval in microseconds. Reading this

+ file returns the value.

+

+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/min

+Date: Feb 2025

+Contact: SeongJae Park <sj@kernel.org>

+Description: If 'hugepage_size' is written to the 'type' file, writing to

+ or reading from this file sets or gets the minimum size of the

+ hugepage for the filter.

+

+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/max

+Date: Feb 2025

+Contact: SeongJae Park <sj@kernel.org>

+Description: If 'hugepage_size' is written to the 'type' file, writing to

+ or reading from this file sets or gets the maximum size of the

+ hugepage for the filter.

+

+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters

+Date: Feb 2025

+Contact: SeongJae Park <sj@kernel.org>

+Description: Directory for DAMON core layer-handled DAMOS filters. Files

+ under this directory works same to those of

+ /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters

+ directory.

+

+What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/ops_filters

+Date: Feb 2025

+Contact: SeongJae Park <sj@kernel.org>

+Description: Directory for DAMON operations set layer-handled DAMOS filters.

+ Files under this directory works same to those of

+ /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters

+ directory.

+

+

+What: /sys/kernel/reboot/hw_protection

+Date: April 2025

+KernelVersion: 6.15

+Contact: Ahmad Fatoum <a.fatoum@pengutronix.de>

+Description: Hardware protection action taken on critical events like

+ overtemperature or imminent voltage loss.

+ Valid values are: reboot shutdown

+What: /sys/class/pps-gen/pps-genx/enable

+Date: April 2025

+KernelVersion: 6.15

+Contact: Subramanian Mohan<subramanian.mohan@intel.com>

+Description:

+ Enable or disable PPS TIO generator output.

+If using refcount_t, the specialized refcount_{add|inc}_not_zero_acquire()

+and refcount_set_release() APIs should be used to ensure correct operation

+ordering when verifying object identity and when initializing newly

+allocated objects. Acquire fence in refcount_{add|inc}_not_zero_acquire()

+ensures that identity checks happen *after* reference count is taken.

+refcount_set_release() should be called after a newly allocated object is

+fully initialized and release fence ensures that new values are visible

+*before* refcount can be successfully taken by other users. Once

+refcount_set_release() is called, the object should be considered visible

+by other tasks.

+ echo foo > /sys/block/zram0/comp_algorithm

+2) Select compression algorithm

+3) Set compression algorithm parameters: Optional

+4) Set Disksize

+5) Set memory limit: Optional

+6) Activate

+7) Add/remove zram devices

+8) Stats

+9) Deactivate

+10) Reset

+ Note that some kernel configurations might account complete larger

+ allocations (e.g., THP) towards 'rss' and 'mapped_file', even if

+ only some, but not all that memory is mapped.

+

+ brk(), sbrk(), and mmap(MAP_ANONYMOUS). Note that

+ some kernel configurations might account complete larger

+ allocations (e.g., THP) if only some, but not all the

+ memory of such an allocation is mapped anymore.

+ Amount of cached filesystem data mapped with mmap(). Note

+ that some kernel configurations might account complete

+ larger allocations (e.g., THP) if only some, but not

+ not all the memory of such an allocation is mapped.

+ pswpin (npn)

+ Number of pages swapped into memory

+

+ pswpout (npn)

+ Number of pages swapped out of memory

+

+ pgscan_proactive (npn)

+ Amount of scanned pages proactively (in an inactive LRU list)

+

+ pgsteal_proactive (npn)

+ Amount of reclaimed pages proactively

+

+ pgdemote_proactive

+ Number of pages demoted by proactively.

+

+integrity_key_size:<bytes>

+ Optionally set the integrity key size if it differs from the digest size.

+ It allows the use of wrapped key algorithms where the key size is

+ independent of the cryptographic key size.

+

+ I - inline mode - in this mode, dm-integrity will store integrity

+ data directly in the underlying device sectors.

+ The underlying device must have an integrity profile that

+ allows storing user integrity data and provides enough

+ space for the selected integrity tag.

+restart_on_error

+ Restart the system when an I/O error is detected.

+ This option can be combined with the restart_on_corruption option.

+

+panic_on_error

+ Panic the device when an I/O error is detected. This option is

+ not compatible with the restart_on_error option but can be combined

+ with the panic_on_corruption option.

+

+ If verity hashes are in cache and the IO size does not exceed the limit,

+ verify data blocks in bottom half instead of workqueue. This option can

+ reduce IO latency. The size limits can be configured via

+ /sys/module/dm_verity/parameters/use_bh_bytes. The four parameters

+ correspond to limits for IOPRIO_CLASS_NONE, IOPRIO_CLASS_RT,

+ IOPRIO_CLASS_BE and IOPRIO_CLASS_IDLE in turn.

+ For example:

+ <none>,<rt>,<be>,<idle>

+ 4096,4096,4096,4096

+ rsb

+.. SPDX-License-Identifier: GPL-2.0

+

+=======================

+RSB-related mitigations

+=======================

+

+.. warning::

+ Please keep this document up-to-date, otherwise you will be

+ volunteered to update it and convert it to a very long comment in

+ bugs.c!

+

+Since 2018 there have been many Spectre CVEs related to the Return Stack

+Buffer (RSB) (sometimes referred to as the Return Address Stack (RAS) or

+Return Address Predictor (RAP) on AMD).

+

+Information about these CVEs and how to mitigate them is scattered

+amongst a myriad of microarchitecture-specific documents.

+

+This document attempts to consolidate all the relevant information in

+once place and clarify the reasoning behind the current RSB-related

+mitigations. It's meant to be as concise as possible, focused only on

+the current kernel mitigations: what are the RSB-related attack vectors

+and how are they currently being mitigated?

+

+It's *not* meant to describe how the RSB mechanism operates or how the

+exploits work. More details about those can be found in the references

+below.

+

+Rather, this is basically a glorified comment, but too long to actually

+be one. So when the next CVE comes along, a kernel developer can

+quickly refer to this as a refresher to see what we're actually doing

+and why.

+

+At a high level, there are two classes of RSB attacks: RSB poisoning

+(Intel and AMD) and RSB underflow (Intel only). They must each be

+considered individually for each attack vector (and microarchitecture

+where applicable).

+

+----

+

+RSB poisoning (Intel and AMD)

+=============================

+

+SpectreRSB

+~~~~~~~~~~

+

+RSB poisoning is a technique used by SpectreRSB [#spectre-rsb]_ where

+an attacker poisons an RSB entry to cause a victim's return instruction

+to speculate to an attacker-controlled address. This can happen when

+there are unbalanced CALLs/RETs after a context switch or VMEXIT.

+

+* All attack vectors can potentially be mitigated by flushing out any

+ poisoned RSB entries using an RSB filling sequence

+ [#intel-rsb-filling]_ [#amd-rsb-filling]_ when transitioning between

+ untrusted and trusted domains. But this has a performance impact and

+ should be avoided whenever possible.

+

+ .. DANGER::

+ **FIXME**: Currently we're flushing 32 entries. However, some CPU

+ models have more than 32 entries. The loop count needs to be

+ increased for those. More detailed information is needed about RSB

+ sizes.

+

+* On context switch, the user->user mitigation requires ensuring the

+ RSB gets filled or cleared whenever IBPB gets written [#cond-ibpb]_

+ during a context switch:

+

+ * AMD:

+ On Zen 4+, IBPB (or SBPB [#amd-sbpb]_ if used) clears the RSB.

+ This is indicated by IBPB_RET in CPUID [#amd-ibpb-rsb]_.

+

+ On Zen < 4, the RSB filling sequence [#amd-rsb-filling]_ must be

+ always be done in addition to IBPB [#amd-ibpb-no-rsb]_. This is

+ indicated by X86_BUG_IBPB_NO_RET.

+

+ * Intel:

+ IBPB always clears the RSB:

+

+ "Software that executed before the IBPB command cannot control

+ the predicted targets of indirect branches executed after the

+ command on the same logical processor. The term indirect branch

+ in this context includes near return instructions, so these

+ predicted targets may come from the RSB." [#intel-ibpb-rsb]_

+

+* On context switch, user->kernel attacks are prevented by SMEP. User

+ space can only insert user space addresses into the RSB. Even

+ non-canonical addresses can't be inserted due to the page gap at the

+ end of the user canonical address space reserved by TASK_SIZE_MAX.

+ A SMEP #PF at instruction fetch prevents the kernel from speculatively

+ executing user space.

+

+ * AMD:

+ "Finally, branches that are predicted as 'ret' instructions get

+ their predicted targets from the Return Address Predictor (RAP).

+ AMD recommends software use a RAP stuffing sequence (mitigation

+ V2-3 in [2]) and/or Supervisor Mode Execution Protection (SMEP)

+ to ensure that the addresses in the RAP are safe for

+ speculation. Collectively, we refer to these mitigations as "RAP

+ Protection"." [#amd-smep-rsb]_

+

+ * Intel:

+ "On processors with enhanced IBRS, an RSB overwrite sequence may

+ not suffice to prevent the predicted target of a near return

+ from using an RSB entry created in a less privileged predictor

+ mode. Software can prevent this by enabling SMEP (for

+ transitions from user mode to supervisor mode) and by having

+ IA32_SPEC_CTRL.IBRS set during VM exits." [#intel-smep-rsb]_

+

+* On VMEXIT, guest->host attacks are mitigated by eIBRS (and PBRSB

+ mitigation if needed):

+

+ * AMD:

+ "When Automatic IBRS is enabled, the internal return address

+ stack used for return address predictions is cleared on VMEXIT."

+ [#amd-eibrs-vmexit]_

+

+ * Intel:

+ "On processors with enhanced IBRS, an RSB overwrite sequence may

+ not suffice to prevent the predicted target of a near return

+ from using an RSB entry created in a less privileged predictor

+ mode. Software can prevent this by enabling SMEP (for

+ transitions from user mode to supervisor mode) and by having

+ IA32_SPEC_CTRL.IBRS set during VM exits. Processors with

+ enhanced IBRS still support the usage model where IBRS is set

+ only in the OS/VMM for OSes that enable SMEP. To do this, such

+ processors will ensure that guest behavior cannot control the

+ RSB after a VM exit once IBRS is set, even if IBRS was not set

+ at the time of the VM exit." [#intel-eibrs-vmexit]_

+

+ Note that some Intel CPUs are susceptible to Post-barrier Return

+ Stack Buffer Predictions (PBRSB) [#intel-pbrsb]_, where the last

+ CALL from the guest can be used to predict the first unbalanced RET.

+ In this case the PBRSB mitigation is needed in addition to eIBRS.

+

+AMD RETBleed / SRSO / Branch Type Confusion

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+

+On AMD, poisoned RSB entries can also be created by the AMD RETBleed

+variant [#retbleed-paper]_ [#amd-btc]_ or by Speculative Return Stack

+Overflow [#amd-srso]_ (Inception [#inception-paper]_). The kernel

+protects itself by replacing every RET in the kernel with a branch to a

+single safe RET.

+

+----

+

+RSB underflow (Intel only)

+==========================

+

+RSB Alternate (RSBA) ("Intel Retbleed")

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+

+Some Intel Skylake-generation CPUs are susceptible to the Intel variant

+of RETBleed [#retbleed-paper]_ (Return Stack Buffer Underflow

+[#intel-rsbu]_). If a RET is executed when the RSB buffer is empty due

+to mismatched CALLs/RETs or returning from a deep call stack, the branch

+predictor can fall back to using the Branch Target Buffer (BTB). If a

+user forces a BTB collision then the RET can speculatively branch to a

+user-controlled address.

+

+* Note that RSB filling doesn't fully mitigate this issue. If there

+ are enough unbalanced RETs, the RSB may still underflow and fall back

+ to using a poisoned BTB entry.

+

+* On context switch, user->user underflow attacks are mitigated by the

+ conditional IBPB [#cond-ibpb]_ on context switch which effectively

+ clears the BTB:

+

+ * "The indirect branch predictor barrier (IBPB) is an indirect branch

+ control mechanism that establishes a barrier, preventing software

+ that executed before the barrier from controlling the predicted

+ targets of indirect branches executed after the barrier on the same

+ logical processor." [#intel-ibpb-btb]_

+

+* On context switch and VMEXIT, user->kernel and guest->host RSB

+ underflows are mitigated by IBRS or eIBRS:

+

+ * "Enabling IBRS (including enhanced IBRS) will mitigate the "RSBU"

+ attack demonstrated by the researchers. As previously documented,

+ Intel recommends the use of enhanced IBRS, where supported. This

+ includes any processor that enumerates RRSBA but not RRSBA_DIS_S."

+ [#intel-rsbu]_

+

+ However, note that eIBRS and IBRS do not mitigate intra-mode attacks.

+ Like RRSBA below, this is mitigated by clearing the BHB on kernel

+ entry.

+

+ As an alternative to classic IBRS, call depth tracking (combined with

+ retpolines) can be used to track kernel returns and fill the RSB when

+ it gets close to being empty.

+

+Restricted RSB Alternate (RRSBA)

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+

+Some newer Intel CPUs have Restricted RSB Alternate (RRSBA) behavior,

+which, similar to RSBA described above, also falls back to using the BTB

+on RSB underflow. The only difference is that the predicted targets are

+restricted to the current domain when eIBRS is enabled:

+

+* "Restricted RSB Alternate (RRSBA) behavior allows alternate branch

+ predictors to be used by near RET instructions when the RSB is

+ empty. When eIBRS is enabled, the predicted targets of these

+ alternate predictors are restricted to those belonging to the

+ indirect branch predictor entries of the current prediction domain.

+ [#intel-eibrs-rrsba]_

+

+When a CPU with RRSBA is vulnerable to Branch History Injection

+[#bhi-paper]_ [#intel-bhi]_, an RSB underflow could be used for an

+intra-mode BTI attack. This is mitigated by clearing the BHB on

+kernel entry.

+

+However if the kernel uses retpolines instead of eIBRS, it needs to

+disable RRSBA:

+

+* "Where software is using retpoline as a mitigation for BHI or

+ intra-mode BTI, and the processor both enumerates RRSBA and

+ enumerates RRSBA_DIS controls, it should disable this behavior."

+ [#intel-retpoline-rrsba]_

+

+----

+

+References

+==========

+

+.. [#spectre-rsb] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <https://arxiv.org/pdf/1807.07940.pdf>`_

+

+.. [#intel-rsb-filling] "Empty RSB Mitigation on Skylake-generation" in `Retpoline: A Branch Target Injection Mitigation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/retpoline-branch-target-injection-mitigation.html#inpage-nav-5-1>`_

+

+.. [#amd-rsb-filling] "Mitigation V2-3" in `Software Techniques for Managing Speculation <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/software-techniques-for-managing-speculation.pdf>`_

+

+.. [#cond-ibpb] Whether IBPB is written depends on whether the prev and/or next task is protected from Spectre attacks. It typically requires opting in per task or system-wide. For more details see the documentation for the ``spectre_v2_user`` cmdline option in Documentation/admin-guide/kernel-parameters.txt.

+

+.. [#amd-sbpb] IBPB without flushing of branch type predictions. Only exists for AMD.

+

+.. [#amd-ibpb-rsb] "Function 8000_0008h -- Processor Capacity Parameters and Extended Feature Identification" in `AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.pdf>`_. SBPB behaves the same way according to `this email <https://lore.kernel.org/5175b163a3736ca5fd01cedf406735636c99a>`_.

+

+.. [#amd-ibpb-no-rsb] `Spectre Attacks: Exploiting Speculative Execution <https://comsec.ethz.ch/wp-content/files/ibpb_sp25.pdf>`_

+

+.. [#intel-ibpb-rsb] "Introduction" in `Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html>`_

+

+.. [#amd-smep-rsb] "Existing Mitigations" in `Technical Guidance for Mitigating Branch Type Confusion <https://www.amd.com/content/dam/amd/en/documents/resources/technical-guidance-for-mitigating-branch-type-confusion.pdf>`_

+

+.. [#intel-smep-rsb] "Enhanced IBRS" in `Indirect Branch Restricted Speculation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-restricted-speculation.html>`_

+

+.. [#amd-eibrs-vmexit] "Extended Feature Enable Register (EFER)" in `AMD64 Architecture Programmer's Manual Volume 2: System Programming <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf>`_

+

+.. [#intel-eibrs-vmexit] "Enhanced IBRS" in `Indirect Branch Restricted Speculation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-restricted-speculation.html>`_

+

+.. [#intel-pbrsb] `Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html>`_

+

+.. [#retbleed-paper] `RETBleed: Arbitrary Speculative Code Execution with Return Instruction <https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf>`_

+

+.. [#amd-btc] `Technical Guidance for Mitigating Branch Type Confusion <https://www.amd.com/content/dam/amd/en/documents/resources/technical-guidance-for-mitigating-branch-type-confusion.pdf>`_

+

+.. [#amd-srso] `Technical Update Regarding Speculative Return Stack Overflow <https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf>`_

+

+.. [#inception-paper] `Inception: Exposing New Attack Surfaces with Training in Transient Execution <https://comsec.ethz.ch/wp-content/files/inception_sec23.pdf>`_

+

+.. [#intel-rsbu] `Return Stack Buffer Underflow / Return Stack Buffer Underflow / CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html>`_

+

+.. [#intel-ibpb-btb] `Indirect Branch Predictor Barrier' <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-predictor-barrier.html>`_

+

+.. [#intel-eibrs-rrsba] "Guidance for RSBU" in `Return Stack Buffer Underflow / Return Stack Buffer Underflow / CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html>`_

+

+.. [#bhi-paper] `Branch History Injection: On the Effectiveness of Hardware Mitigations Against Cross-Privilege Spectre-v2 Attacks <http://download.vusec.net/papers/bhi-spectre-bhb_sec22.pdf>`_

+

+.. [#intel-bhi] `Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html>`_

+

+.. [#intel-retpoline-rrsba] "Retpoline" in `Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html>`_

+ earlyprintk=mmio32,membase[,{nocfg|baudrate}]

+ hugepages= [HW,EARLY] Number of HugeTLB pages to allocate at boot.

+ [HW,EARLY] The size of the HugeTLB pages. This is

+ used in conjunction with hugepages (above) to

+ allocate huge pages of a specific size at boot. The

+ pair hugepagesz=X hugepages=Y can be specified once

+ for each supported huge page size. Huge page sizes

+ are architecture dependent. See also

+ hugepage_alloc_threads=

+ [HW] The number of threads that should be used to

+ allocate hugepages during boot. This option can be

+ used to improve system bootup time when allocating

+ a large amount of huge pages.

+ The default value is 25% of the available hardware threads.

+

+ Note that this parameter only applies to non-gigantic huge pages.

+

+ hugetlb_cma_only=

+ [HW,CMA,EARLY] When allocating new HugeTLB pages, only

+ try to allocate from the CMA areas.

+

+ This option does nothing if hugetlb_cma= is not also

+ specified.

+

+ hw_protection= [HW]

+ Format: reboot | shutdown

+

+ Hardware protection action taken on critical events like

+ overtemperature or imminent voltage loss.

+

+ nosmt [KNL,MIPS,PPC,EARLY] Disable symmetric multithreading (SMT).

+ [KNL,X86,PPC,S390] Disable symmetric multithreading (SMT).

+ NB: Both the mapped address and size must be page aligned for the architecture.

+

+ unaligned_scalar_speed=

+ [RISCV]

+ Format: {slow | fast | unsupported}

+ Allow skipping scalar unaligned access speed tests. This

+ is useful for testing alternative code paths and to skip

+ the tests in environments where they run too slowly. All

+ CPUs must have the same scalar unaligned access speed.

+

+ unaligned_vector_speed=

+ [RISCV]

+ Format: {slow | fast | unsupported}

+ Allow skipping vector unaligned access speed tests. This

+ is useful for testing alternative code paths and to skip

+ the tests in environments where they run too slowly. All

+ CPUs must have the same vector unaligned access speed.

+

+ - [RO] base_pfn: The base PFN (Page Frame Number) of the CMA area.

+ This is the same as ranges/0/base_pfn.

+ - [RO] bitmap: The bitmap of allocated pages in the area.

+ This is the same as ranges/0/base_pfn.

+ - [RO] ranges/N/base_pfn: The base PFN of contiguous range N

+ in the CMA area.

+ - [RO] ranges/N/bitmap: The bit map of allocated pages in

+ range N in the CMA area.

+ │ │ │ │ │ │ │ intervals_goal/access_bp,aggrs,min_sample_us,max_sample_us

+ │ │ │ │ │ │ │ :ref:`{core_,ops_,}filters <sysfs_filters>`/nr_filters

+ │ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,target_idx,min,max

+- ``update_tuned_intervals``: Update the contents of ``sample_us`` and

+ ``aggr_us`` files of the kdamond with the auto-tuning applied ``sampling

+ interval`` and ``aggregation interval`` for the files. Please refer to

+ :ref:`intervals_goal section <damon_usage_sysfs_monitoring_intervals_goal>`

+ for more details.

+.. _damon_usage_sysfs_monitoring_intervals_goal:

+

+contexts/<N>/monitoring_attrs/intervals/intervals_goal/

+-------------------------------------------------------

+

+Under the ``intervals`` directory, one directory for automated tuning of

+``sample_us`` and ``aggr_us``, namely ``intervals_goal`` directory also exists.

+Under the directory, four files for the auto-tuning control, namely

+``access_bp``, ``aggrs``, ``min_sample_us`` and ``max_sample_us`` exist.

+Please refer to the :ref:`design document of the feature

+<damon_design_monitoring_intervals_autotuning>` for the internal of the tuning

+mechanism. Reading and writing the four files under ``intervals_goal``

+directory shows and updates the tuning parameters that described in the

+:ref:design doc <damon_design_monitoring_intervals_autotuning>` with the same

+names. The tuning starts with the user-set ``sample_us`` and ``aggr_us``. The

+tuning-applied current values of the two intervals can be read from the

+``sample_us`` and ``aggr_us`` files after writing ``update_tuned_intervals`` to

+the ``state`` file.

+

+In each scheme directory, seven directories (``access_pattern``, ``quotas``,

+``watermarks``, ``core_filters``, ``ops_filters``, ``filters``, ``stats``, and

+``tried_regions``) and three files (``action``, ``target_nid`` and

+``apply_interval``) exist.

+schemes/<N>/{core\_,ops\_,}filters/

+-----------------------------------

+Directories for :ref:`filters <damon_design_damos_filters>` of the given

+``core_filters`` and ``ops_filters`` directories are for the filters handled by

+the DAMON core layer and operations set layer, respectively. ``filters``

+directory can be used for installing filters regardless of their handled

+layers. Filters that requested by ``core_filters`` and ``ops_filters`` will be

+installed before those of ``filters``. All three directories have same files.

+

+Use of ``filters`` directory can make expecting evaluation orders of given

+filters with the files under directory bit confusing. Users are hence

+recommended to use ``core_filters`` and ``ops_filters`` directories. The

+``filters`` directory could be deprecated in future.

+

+In the beginning, the directory has only one file, ``nr_filters``. Writing a

+Each filter directory contains nine files, namely ``type``, ``matching``,

+``allow``, ``memcg_path``, ``addr_start``, ``addr_end``, ``min``, ``max``

+and ``target_idx``. To ``type`` file, you can write the type of the filter.

+Refer to :ref:`the design doc <damon_design_damos_filters>` for available type

+names, their meaning and on what layer those are handled.

+

+For ``memcg`` type, you can specify the memory cgroup of the interest by

+writing the path of the memory cgroup from the cgroups mount point to

+``memcg_path`` file. For ``addr`` type, you can specify the start and end

+address of the range (open-ended interval) to ``addr_start`` and ``addr_end``

+files, respectively. For ``hugepage_size`` type, you can specify the minimum

+and maximum size of the range (closed interval) to ``min`` and ``max`` files,

+respectively. For ``target`` type, you can specify the index of the target

+between the list of the DAMON context's monitoring targets list to

+``target_idx`` file.

+ # cd ops_filters/0/

+hugepage_alloc_threads

+ Specify the number of threads that should be used to allocate hugepages

+ during boot. This parameter can be used to improve system bootup time

+ when allocating a large amount of huge pages.

+ The default value is 25% of the available hardware threads.

+ Example to use 8 allocation threads::

+

+ hugepage_alloc_threads=8

+

+ Note that this parameter only applies to non-gigantic huge pages.

+ * Bit 58 pte is a guard region (since 6.15) (see madvise (2) man page)

+ * Bits 59-60 zero

+ Traditionally, bit 56 indicates that a page is mapped exactly once and bit

+ 56 is clear when a page is mapped multiple times, even when mapped in the

+ same process multiple times. In some kernel configurations, the semantics

+ for pages part of a larger allocation (e.g., THP) can differ: bit 56 is set

+ if all pages part of the corresponding large allocation are *certainly*

+ mapped in the same process, even if the page is mapped multiple times in that

+ process. Bit 56 is clear when any page page of the larger allocation

+ is *maybe* mapped in a different process. In some cases, a large allocation

+ might be treated as "maybe mapped by multiple processes" even though this

+ is no longer the case.

+

+ times each page is mapped, indexed by PFN. Some kernel configurations do

+ not track the precise number of times a page part of a larger allocation

+ (e.g., THP) is mapped. In these configurations, the average number of

+ mappings per page in this larger allocation is returned instead. However,

+ if any page of the large allocation is mapped, the returned value will

+ be at least 1.

+e.g. ``zswap.zpool=zsmalloc``. It can also be changed at runtime using the sysfs

+ echo zsmalloc > /sys/module/zswap/parameters/zpool

+The zsmalloc type zpool has a complex compressed page storage method, and it

+can achieve great storage densities.

+

+``/proc/sys/fs/fuse/default_request_timeout`` is a read/write file for

+setting/getting the default timeout (in seconds) for a fuse server to

+reply to a kernel-issued request in the event where the server did not

+specify a timeout at mount. If the server set a timeout,

+then default_request_timeout will be ignored. The default

+"default_request_timeout" is set to 0. 0 indicates no default timeout.

+The maximum value that can be set is 65535.

+

+``/proc/sys/fs/fuse/max_request_timeout`` is a read/write file for

+setting/getting the maximum timeout (in seconds) for a fuse server to

+reply to a kernel-issued request. A value greater than 0 automatically opts

+the server into a timeout that will be set to at most "max_request_timeout",

+even if the server did not specify a timeout and default_request_timeout is

+set to 0. If max_request_timeout is greater than 0 and the server set a timeout

+greater than max_request_timeout or default_request_timeout is set to a value

+greater than max_request_timeout, the system will use max_request_timeout as the

+timeout. 0 indicates no max request timeout. The maximum value that can be set

+is 65535.

+

+For timeouts, if the server does not respond to the request by the time

+the set timeout elapses, then the connection to the fuse server will be aborted.

+Please note that the timeouts are not 100% precise (eg you may set 60 seconds but

+the timeout may kick in after 70 seconds). The upper margin of error for the

+timeout is roughly FUSE_TIMEOUT_TIMER_FREQ seconds.

+- defrag_mode

+defrag_mode

+===========

+

+When set to 1, the page allocator tries harder to avoid fragmentation

+and maintain the ability to produce huge pages / higher-order pages.

+

+It is recommended to enable this right after boot, as fragmentation,

+once it occurred, can be long-lasting or even permanent.

+ * :c:macro:`RISCV_HWPROBE_EXT_ZICNTR`: The Zicntr extension version 2.0

+ is supported as defined in the RISC-V ISA manual.

+

+ * :c:macro:`RISCV_HWPROBE_EXT_ZIHPM`: The Zihpm extension version 2.0

+ is supported as defined in the RISC-V ISA manual.

+

+ * :c:macro:`RISCV_HWPROBE_EXT_ZAAMO`: The Zaamo extension is supported as

+ defined in the in the RISC-V ISA manual starting from commit e87412e621f1

+ ("integrate Zaamo and Zalrsc text (#1304)").

+

+ * :c:macro:`RISCV_HWPROBE_EXT_ZALRSC`: The Zalrsc extension is supported as

+ defined in the in the RISC-V ISA manual starting from commit e87412e621f1

+ ("integrate Zaamo and Zalrsc text (#1304)").

+

+ * :c:macro:`RISCV_HWPROBE_EXT_ZFBFMIN`: The Zfbfmin extension is supported as

+ defined in the RISC-V ISA manual starting from commit 4dc23d6229de

+ ("Added Chapter title to BF16").

+

+ * :c:macro:`RISCV_HWPROBE_EXT_ZVFBFMIN`: The Zvfbfmin extension is supported as

+ defined in the RISC-V ISA manual starting from commit 4dc23d6229de

+ ("Added Chapter title to BF16").

+

+ * :c:macro:`RISCV_HWPROBE_EXT_ZVFBFWMA`: The Zvfbfwma extension is supported as

+ defined in the RISC-V ISA manual starting from commit 4dc23d6229de

+ ("Added Chapter title to BF16").

+

+ * :c:macro:`RISCV_HWPROBE_EXT_ZICBOM`: The Zicbom extension is supported, as

+ ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.

+

+

+* :c:macro:`RISCV_HWPROBE_KEY_ZICBOM_BLOCK_SIZE`: An unsigned int which

+ represents the size of the Zicbom block in bytes.

+Feature flags can be derived from the contents of CPUID leaves

+--------------------------------------------------------------

+

+Flags can be from scattered CPUID-based features

+------------------------------------------------

+

+Flags can be created synthetically under certain conditions for hardware features

+---------------------------------------------------------------------------------

+

+Flags can represent purely software features

+--------------------------------------------

+Flags do not appear by default in /proc/cpuinfo

+-----------------------------------------------

+

+Feature flags are omitted by default from /proc/cpuinfo as it does not make

+sense for the feature to be exposed to userspace in most cases. For example,

+X86_FEATURE_ALWAYS is defined in cpufeatures.h but that flag is an internal

+kernel feature used in the alternative runtime patching functionality. So the

+flag does not appear in /proc/cpuinfo.

+

+Specify a flag name if absolutely needed

+----------------------------------------

+The hardware does not enumerate support for it

+----------------------------------------------

+

+The kernel does not know about the flag

+---------------------------------------

+

+The kernel disabled support for it at compile-time

+--------------------------------------------------

+

+The feature is disabled at boot-time

+------------------------------------

+The feature was known to be non-functional

+------------------------------------------

+

+ublk zero copy relies on io_uring's fixed kernel buffer, which provides

+two APIs: `io_buffer_register_bvec()` and `io_buffer_unregister_bvec`.

+

+ublk adds IO command of `UBLK_IO_REGISTER_IO_BUF` to call

+`io_buffer_register_bvec()` for ublk server to register client request

+buffer into io_uring buffer table, then ublk server can submit io_uring

+IOs with the registered buffer index. IO command of `UBLK_IO_UNREGISTER_IO_BUF`

+calls `io_buffer_unregister_bvec()` to unregister the buffer, which is

+guaranteed to be live between calling `io_buffer_register_bvec()` and

+`io_buffer_unregister_bvec()`. Any io_uring operation which supports this

+kind of kernel buffer will grab one reference of the buffer until the

+operation is completed.

+

+ublk server implementing zero copy or user copy has to be CAP_SYS_ADMIN and

+be trusted, because it is ublk server's responsibility to make sure IO buffer

+filled with data for handling read command, and ublk server has to return

+correct result to ublk driver when handling READ command, and the result

+has to match with how many bytes filled to the IO buffer. Otherwise,

+uninitialized kernel IO buffer will be exposed to client application.

+

+ublk server needs to align the parameter of `struct ublk_param_dma_align`

+with backend for zero copy to work correctly.

+

+For reaching best IO performance, ublk server should align its segment

+parameter of `struct ublk_param_segment` with backend for avoiding

+unnecessary IO split, which usually hurts io_uring performance.

+case 2) - non-"Read/Modify/Write" (RMW) ops with release ordering

+-----------------------------------------------------------------

+

+Function changes:

+

+ * atomic_set_release() --> refcount_set_release()

+

+Memory ordering guarantee changes:

+

+ * none (both provide RELEASE ordering)

+

+

+case 3) - increment-based ops that return no value

+case 4) - decrement-based RMW ops that return no value

+case 5) - increment-based RMW ops that return a value

+case 6) - increment-based RMW ops with acquire ordering that return a value

+---------------------------------------------------------------------------

+

+Function changes:

+

+ * atomic_inc_not_zero() --> refcount_inc_not_zero_acquire()

+ * no atomic counterpart --> refcount_add_not_zero_acquire()

+

+Memory ordering guarantees changes:

+

+ * fully ordered --> ACQUIRE ordering on success

+

+

+case 7) - generic dec/sub decrement-based RMW ops that return a value

+case 8) other decrement-based RMW ops that return a value

+case 9) - lock-based RMW

+and calling xas_split() or calling xas_try_split() with xa_lock. The

+difference between xas_split_alloc()+xas_split() and xas_try_alloc() is

+that xas_split_alloc() + xas_split() split the entry from the original

+order to the new order in one shot uniformly, whereas xas_try_split()

+iteratively splits the entry containing the index non-uniformly.

+For example, to split an order-9 entry, which takes 2^(9-6)=8 slots,

+assuming ``XA_CHUNK_SHIFT`` is 6, xas_split_alloc() + xas_split() need

+8 xa_node. xas_try_split() splits the order-9 entry into

+2 order-8 entries, then split one order-8 entry, based on the given index,

+to 2 order-7 entries, ..., and split one order-1 entry to 2 order-0 entries.

+When splitting the order-6 entry and a new xa_node is needed, xas_try_split()

+will try to allocate one if possible. As a result, xas_try_split() would only

+need 1 xa_node instead of 8.

+ memory-region:

+ items:

+ - description: Reserved trace buffer memory for ETR and ETF sinks.

+ For ETR, this reserved memory region is used for trace data capture.

+ Same region is used for trace data retention as well after a panic

+ or watchdog reset.

+ This reserved memory region is used as trace buffer or used for trace

+ data retention only if specifically selected by the user in sysfs

+ interface.

+ The default memory usage models for ETR in sysfs/perf modes are

+ otherwise unaltered.

+

+ For ETF, this reserved memory region is used by default for

+ retention of trace data synced from internal SRAM after a panic

+ or watchdog reset.

+ - description: Reserved meta data memory. Used for ETR and ETF sinks

+ for storing metadata.

+

+ memory-region-names:

+ items:

+ - const: tracedata

+ - const: metadata

+

+ memory-region = <&etr_trace_mem_reserved>,

+ <&etr_mdata_mem_reserved>;

+ memory-region-names = "tracedata", "metadata";

+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/arm/qcom,coresight-ctcu.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: CoreSight TMC Control Unit

+

+maintainers:

+ - Yuanfang Zhang <quic_yuanfang@quicinc.com>

+ - Mao Jinlong <quic_jinlmao@quicinc.com>

+ - Jie Gan <quic_jiegan@quicinc.com>

+

+description: |

+ The Trace Memory Controller(TMC) is used for Embedded Trace Buffer(ETB),

+ Embedded Trace FIFO(ETF) and Embedded Trace Router(ETR) configurations.

+ The configuration mode (ETB, ETF, ETR) is discovered at boot time when

+ the device is probed.

+

+ The Coresight TMC Control unit controls various Coresight behaviors.

+ It works as a helper device when connected to TMC ETR device.

+ It is responsible for controlling the data filter function based on

+ the source device's Trace ID for TMC ETR device. The trace data with

+ that Trace id can get into ETR's buffer while other trace data gets

+ ignored.

+

+properties:

+ compatible:

+ enum:

+ - qcom,sa8775p-ctcu

+

+ reg:

+ maxItems: 1

+

+ clocks:

+ maxItems: 1

+

+ clock-names:

+ items:

+ - const: apb

+

+ in-ports:

+ $ref: /schemas/graph.yaml#/properties/ports

+

+ patternProperties:

+ '^port(@[0-1])?$':

+ description: Input connections from CoreSight Trace bus

+ $ref: /schemas/graph.yaml#/properties/port

+

+required:

+ - compatible

+ - reg

+ - in-ports

+

+additionalProperties: false

+

+examples:

+ - |

+ ctcu@1001000 {

+ compatible = "qcom,sa8775p-ctcu";

+ reg = <0x1001000 0x1000>;

+

+ clocks = <&aoss_qmp>;

+ clock-names = "apb";

+

+ in-ports {

+ #address-cells = <1>;

+ #size-cells = <0>;

+

+ port@0 {

+ reg = <0>;

+ ctcu_in_port0: endpoint {

+ remote-endpoint = <&etr0_out_port>;

+ };

+ };

+

+ port@1 {

+ reg = <1>;

+ ctcu_in_port1: endpoint {

+ remote-endpoint = <&etr1_out_port>;

+ };

+ };

+ };

+ };

+ maxItems: 1

+ maxItems: 1

+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/dma/atmel,at91sam9g45-dma.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Atmel Direct Memory Access Controller (DMA)

+

+maintainers:

+ - Ludovic Desroches <ludovic.desroches@microchip.com>

+

+description:

+ The Atmel Direct Memory Access Controller (DMAC) transfers data from a source

+ peripheral to a destination peripheral over one or more AMBA buses. One channel

+ is required for each source/destination pair. In the most basic configuration,

+ the DMAC has one master interface and one channel. The master interface reads

+ the data from a source and writes it to a destination. Two AMBA transfers are

+ required for each DMAC data transfer. This is also known as a dual-access transfer.

+ The DMAC is programmed via the APB interface.

+

+properties:

+ compatible:

+ enum:

+ - atmel,at91sam9g45-dma

+ - atmel,at91sam9rl-dma

+

+ reg:

+ maxItems: 1

+

+ interrupts:

+ maxItems: 1

+

+ "#dma-cells":

+ description:

+ Must be <2>, used to represent the number of integer cells in the dma

+ property of client devices. The two cells in order are

+ 1. The first cell represents the channel number.

+ 2. The second cell is 0 for RX and 1 for TX transfers.

+ const: 2

+

+ clocks:

+ maxItems: 1

+

+ clock-names:

+ const: dma_clk

+

+required:

+ - compatible

+ - reg

+ - interrupts

+ - "#dma-cells"

+ - clocks

+ - clock-names

+

+additionalProperties: false

+

+examples:

+ - |

+ dma-controller@ffffec00 {

+ compatible = "atmel,at91sam9g45-dma";

+ reg = <0xffffec00 0x200>;

+ interrupts = <21>;

+ #dma-cells = <2>;

+ clocks = <&pmc 2 20>;

+ clock-names = "dma_clk";

+ };

+

+...

+ - items:

+ - const: microchip,sama7d65-dma

+ - const: microchip,sama7g5-dma

+ - enum:

+ - fsl,imx94-edma3

+ - const: fsl,imx93-edma3

+ - items:

+ - enum:

+ - fsl,imx94-edma5

+ - const: fsl,imx95-edma5

+ - items:

+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/dma/fsl,elo-dma.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Freescale Elo DMA Controller

+

+maintainers:

+ - J. Neuschäfer <j.ne@posteo.net>

+

+description:

+ This is a little-endian 4-channel DMA controller, used in Freescale mpc83xx

+ series chips such as mpc8315, mpc8349, mpc8379 etc.

+

+properties:

+ compatible:

+ items:

+ - enum:

+ - fsl,mpc8313-dma

+ - fsl,mpc8315-dma

+ - fsl,mpc8323-dma

+ - fsl,mpc8347-dma

+ - fsl,mpc8349-dma

+ - fsl,mpc8360-dma

+ - fsl,mpc8377-dma

+ - fsl,mpc8378-dma

+ - fsl,mpc8379-dma

+ - const: fsl,elo-dma

+

+ reg:

+ items:

+ - description:

+ DMA General Status Register, i.e. DGSR which contains status for

+ all the 4 DMA channels.

+

+ cell-index:

+ $ref: /schemas/types.yaml#/definitions/uint32

+ description: Controller index. 0 for controller @ 0x8100.

+

+ ranges: true

+

+ "#address-cells":

+ const: 1

+

+ "#size-cells":

+ const: 1

+

+ interrupts:

+ maxItems: 1

+ description: Controller interrupt.

+

+required:

+ - compatible

+ - reg

+

+patternProperties:

+ "^dma-channel@[0-9a-f]+$":

+ type: object

+ additionalProperties: false

+

+ properties:

+ compatible:

+ oneOf:

+ # native DMA channel

+ - items:

+ - enum:

+ - fsl,mpc8315-dma-channel

+ - fsl,mpc8323-dma-channel

+ - fsl,mpc8347-dma-channel

+ - fsl,mpc8349-dma-channel

+ - fsl,mpc8360-dma-channel

+ - fsl,mpc8377-dma-channel

+ - fsl,mpc8378-dma-channel

+ - fsl,mpc8379-dma-channel

+ - const: fsl,elo-dma-channel

+

+ # audio DMA channel, see fsl,ssi.yaml

+ - const: fsl,ssi-dma-channel

+

+ reg:

+ maxItems: 1

+

+ cell-index:

+ description: DMA channel index starts at 0.

+

+ interrupts:

+ maxItems: 1

+ description:

+ Per-channel interrupt. Only necessary if no controller interrupt has

+ been provided.

+

+additionalProperties: false

+

+examples:

+ - |

+ #include <dt-bindings/interrupt-controller/irq.h>

+

+ dma@82a8 {

+ compatible = "fsl,mpc8349-dma", "fsl,elo-dma";

+ reg = <0x82a8 4>;

+ #address-cells = <1>;

+ #size-cells = <1>;

+ ranges = <0 0x8100 0x1a4>;

+ interrupts = <71 IRQ_TYPE_LEVEL_LOW>;

+ cell-index = <0>;

+

+ dma-channel@0 {

+ compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";

+ reg = <0 0x80>;

+ cell-index = <0>;

+ interrupts = <71 IRQ_TYPE_LEVEL_LOW>;

+ };

+

+ dma-channel@80 {

+ compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";

+ reg = <0x80 0x80>;

+ cell-index = <1>;

+ interrupts = <71 IRQ_TYPE_LEVEL_LOW>;

+ };

+

+ dma-channel@100 {

+ compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";

+ reg = <0x100 0x80>;

+ cell-index = <2>;

+ interrupts = <71 IRQ_TYPE_LEVEL_LOW>;

+ };

+

+ dma-channel@180 {

+ compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";

+ reg = <0x180 0x80>;

+ cell-index = <3>;

+ interrupts = <71 IRQ_TYPE_LEVEL_LOW>;

+ };

+ };

+

+...

+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/dma/fsl,elo3-dma.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Freescale Elo3 DMA Controller

+

+maintainers:

+ - J. Neuschäfer <j.ne@posteo.net>

+

+description:

+ DMA controller which has same function as EloPlus except that Elo3 has 8

+ channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx

+ series chips, such as t1040, t4240, b4860.

+

+properties:

+ compatible:

+ const: fsl,elo3-dma

+

+ reg:

+ items:

+ - description:

+ DMA General Status Registers starting from DGSR0, for channel 1~4

+ - description:

+ DMA General Status Registers starting from DGSR1, for channel 5~8

+

+ ranges: true

+

+ "#address-cells":

+ const: 1

+

+ "#size-cells":

+ const: 1

+

+ interrupts:

+ maxItems: 1

+

+patternProperties:

+ "^dma-channel@[0-9a-f]+$":

+ type: object

+ additionalProperties: false

+

+ properties:

+ compatible:

+ enum:

+ # native DMA channel

+ - fsl,eloplus-dma-channel

+

+ # audio DMA channel, see fsl,ssi.yaml

+ - fsl,ssi-dma-channel

+

+ reg:

+ maxItems: 1

+

+ interrupts:

+ maxItems: 1

+ description:

+ Per-channel interrupt. Only necessary if no controller interrupt has

+ been provided.

+

+additionalProperties: false

+

+examples:

+ - |

+ #include <dt-bindings/interrupt-controller/irq.h>

+

+ dma@100300 {

+ compatible = "fsl,elo3-dma";

+ reg = <0x100300 0x4>,

+ <0x100600 0x4>;

+ #address-cells = <1>;

+ #size-cells = <1>;

+ ranges = <0x0 0x100100 0x500>;

+

+ dma-channel@0 {

+ compatible = "fsl,eloplus-dma-channel";

+ reg = <0x0 0x80>;

+ interrupts = <28 IRQ_TYPE_EDGE_FALLING 0 0>;

+ };

+

+ dma-channel@80 {

+ compatible = "fsl,eloplus-dma-channel";

+ reg = <0x80 0x80>;

+ interrupts = <29 IRQ_TYPE_EDGE_FALLING 0 0>;

+ };

+

+ dma-channel@100 {

+ compatible = "fsl,eloplus-dma-channel";

+ reg = <0x100 0x80>;

+ interrupts = <30 IRQ_TYPE_EDGE_FALLING 0 0>;

+ };

+

+ dma-channel@180 {

+ compatible = "fsl,eloplus-dma-channel";

+ reg = <0x180 0x80>;

+ interrupts = <31 IRQ_TYPE_EDGE_FALLING 0 0>;

+ };

+

+ dma-channel@300 {

+ compatible = "fsl,eloplus-dma-channel";

+ reg = <0x300 0x80>;

+ interrupts = <76 IRQ_TYPE_EDGE_FALLING 0 0>;

+ };

+

+ dma-channel@380 {

+ compatible = "fsl,eloplus-dma-channel";

+ reg = <0x380 0x80>;

+ interrupts = <77 IRQ_TYPE_EDGE_FALLING 0 0>;

+ };

+

+ dma-channel@400 {

+ compatible = "fsl,eloplus-dma-channel";

+ reg = <0x400 0x80>;

+ interrupts = <78 IRQ_TYPE_EDGE_FALLING 0 0>;

+ };

+

+ dma-channel@480 {

+ compatible = "fsl,eloplus-dma-channel";

+ reg = <0x480 0x80>;

+ interrupts = <79 IRQ_TYPE_EDGE_FALLING 0 0>;

+ };

+ };

+

+...

+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/dma/fsl,eloplus-dma.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Freescale EloPlus DMA Controller

+

+maintainers:

+ - J. Neuschäfer <j.ne@posteo.net>

+

+description:

+ This is a 4-channel DMA controller with extended addresses and chaining,

+ mainly used in Freescale mpc85xx/86xx, Pxxx and BSC series chips, such as

+ mpc8540, mpc8641 p4080, bsc9131 etc.

+

+properties:

+ compatible:

+ oneOf:

+ - items:

+ - enum:

+ - fsl,mpc8540-dma

+ - fsl,mpc8541-dma

+ - fsl,mpc8548-dma

+ - fsl,mpc8555-dma

+ - fsl,mpc8560-dma

+ - fsl,mpc8572-dma

+ - fsl,mpc8641-dma

+ - const: fsl,eloplus-dma

+ - const: fsl,eloplus-dma

+

+ reg:

+ items:

+ - description:

+ DMA General Status Register, i.e. DGSR which contains

+ status for all the 4 DMA channels

+

+ cell-index:

+ $ref: /schemas/types.yaml#/definitions/uint32

+ description:

+ controller index. 0 for controller @ 0x21000, 1 for controller @ 0xc000

+

+ ranges: true

+

+ "#address-cells":

+ const: 1

+

+ "#size-cells":

+ const: 1

+

+ interrupts:

+ maxItems: 1

+ description: Controller interrupt.

+

+patternProperties:

+ "^dma-channel@[0-9a-f]+$":

+ type: object

+ additionalProperties: false

+

+ properties:

+ compatible:

+ oneOf:

+ # native DMA channel

+ - items:

+ - enum:

+ - fsl,mpc8540-dma-channel

+ - fsl,mpc8541-dma-channel

+ - fsl,mpc8548-dma-channel

+ - fsl,mpc8555-dma-channel

+ - fsl,mpc8560-dma-channel

+ - fsl,mpc8572-dma-channel

+ - const: fsl,eloplus-dma-channel

+

+ # audio DMA channel, see fsl,ssi.yaml

+ - const: fsl,ssi-dma-channel

+

+ reg:

+ maxItems: 1

+

+ cell-index:

+ description: DMA channel index starts at 0.

+

+ interrupts:

+ maxItems: 1

+ description:

+ Per-channel interrupt. Only necessary if no controller interrupt has

+ been provided.

+

+additionalProperties: false

+

+examples:

+ - |

+ #include <dt-bindings/interrupt-controller/irq.h>

+

+ dma@21300 {

+ compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";

+ reg = <0x21300 4>;

+ #address-cells = <1>;

+ #size-cells = <1>;

+ ranges = <0 0x21100 0x200>;

+ cell-index = <0>;

+

+ dma-channel@0 {

+ compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";

+ reg = <0 0x80>;

+ cell-index = <0>;

+ interrupts = <20 IRQ_TYPE_EDGE_FALLING>;

+ };

+

+ dma-channel@80 {

+ compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";

+ reg = <0x80 0x80>;

+ cell-index = <1>;

+ interrupts = <21 IRQ_TYPE_EDGE_FALLING>;

+ };

+

+ dma-channel@100 {

+ compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";

+ reg = <0x100 0x80>;

+ cell-index = <2>;

+ interrupts = <22 IRQ_TYPE_EDGE_FALLING>;

+ };

+

+ dma-channel@180 {

+ compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";

+ reg = <0x180 0x80>;

+ cell-index = <3>;

+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;

+ };

+ };

+

+...

+ - fsl,imx8dxl-dma-apbh

+ - fsl,imx8mm-dma-apbh

+ - fsl,imx8mn-dma-apbh

+ - fsl,imx8mp-dma-apbh

+ - fsl,imx8mq-dma-apbh

+ - fsl,imx8qm-dma-apbh

+ dma-noncoherent: true

+

+ - enum:

+ - onnn,n24s64b

+ - puya,p24c64f

+ - giantec,gt24p128e

+ - samsung,exynos7870-hsi2c

+ - fsl,imx94-lpi2c

+ - rockchip,rk3562-i2c

+ interconnects:

+ maxItems: 1

+

+ power-domains:

+ maxItems: 1

+

+ required-opps:

+ maxItems: 1

+

+ #include <dt-bindings/interconnect/qcom,msm8996.h>

+ #include <dt-bindings/power/qcom-rpmpd.h>

+ power-domains = <&rpmpd MSM8909_VDDCX>;

+ required-opps = <&rpmpd_opp_svs_krait>;

+ interconnects = <&pnoc MASTER_BLSP_1 &bimc SLAVE_EBI_CH0>;

+ - samsung,exynos7870-i2c

+ - description: Renesas RZ/N1D I2C controller

+ items:

+ - const: renesas,r9a06g032-i2c # RZ/N1D

+ - const: renesas,rzn1-i2c # RZ/N1

+ - const: snps,designware-i2c

+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/i2c/spacemit,k1-i2c.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: I2C controller embedded in SpacemiT's K1 SoC

+

+maintainers:

+ - Troy Mitchell <troymitchell988@gmail.com>

+

+properties:

+ compatible:

+ const: spacemit,k1-i2c

+

+ reg:

+ maxItems: 1

+

+ interrupts:

+ maxItems: 1

+

+ clocks:

+ items:

+ - description: I2C Functional Clock

+ - description: APB Bus Clock

+

+ clock-names:

+ items:

+ - const: func

+ - const: bus

+

+ clock-frequency:

+ description: |

+ K1 support three different modes which running different frequencies

+ standard speed mode: up to 100000 (100Hz)

+ fast speed mode : up to 400000 (400Hz)

+ high speed mode : up to 3300000 (3.3Mhz)

+ default: 400000

+ maximum: 3300000

+

+required:

+ - compatible

+ - reg

+ - interrupts

+ - clocks

+

+unevaluatedProperties: false

+

+examples:

+ - |

+ i2c@d4010800 {

+ compatible = "spacemit,k1-i2c";

+ reg = <0xd4010800 0x38>;

+ interrupt-parent = <&plic>;

+ interrupts = <36>;

+ clocks =<&ccu 32>, <&ccu 84>;

+ clock-names = "func", "bus";

+ clock-frequency = <100000>;

+ };

+

+...

+ mux-states:

+ description:

+ mux controller node to route the I2C signals from SoC to clients.

+ maxItems: 1

+

+ mux-states = <&i2c_mux 1>;

+ enum:

+ - nuvoton,npcm845-i3c

+ - silvaco,i3c-master-v1

+ power-domains:

+ maxItems: 1

+

+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

+# Copyright 2024 Analog Devices Inc.

+# Copyright 2024 BayLibre, SAS.

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/iio/adc/adi,ad4030.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Analog Devices AD4030 and AD4630 ADC families

+

+maintainers:

+ - Michael Hennerich <michael.hennerich@analog.com>

+ - Nuno Sa <nuno.sa@analog.com>

+

+description: |

+ Analog Devices AD4030 single channel and AD4630/AD4632 dual channel precision

+ SAR ADC families

+

+ * https://www.analog.com/media/en/technical-documentation/data-sheets/ad4030-24-4032-24.pdf

+ * https://www.analog.com/media/en/technical-documentation/data-sheets/ad4630-24_ad4632-24.pdf

+ * https://www.analog.com/media/en/technical-documentation/data-sheets/ad4630-16-4632-16.pdf

+

+properties:

+ compatible:

+ enum:

+ - adi,ad4030-24

+ - adi,ad4032-24

+ - adi,ad4630-16

+ - adi,ad4630-24

+ - adi,ad4632-16

+ - adi,ad4632-24

+

+ reg:

+ maxItems: 1

+

+ spi-max-frequency:

+ maximum: 102040816

+

+ spi-rx-bus-width:

+ enum: [1, 2, 4]

+

+ vdd-5v-supply: true

+ vdd-1v8-supply: true

+ vio-supply: true

+

+ ref-supply:

+ description:

+ Optional External unbuffered reference. Used when refin-supply is not

+ connected.

+

+ refin-supply:

+ description:

+ Internal buffered Reference. Used when ref-supply is not connected.

+

+ cnv-gpios:

+ description:

+ The Convert Input (CNV). It initiates the sampling conversions.

+ maxItems: 1

+

+ reset-gpios:

+ description:

+ The Reset Input (/RST). Used for asynchronous device reset.

+ maxItems: 1

+

+ interrupts:

+ description:

+ The BUSY pin is used to signal that the conversions results are available

+ to be transferred when in SPI Clocking Mode. This nodes should be

+ connected to an interrupt that is triggered when the BUSY line goes low.

+ maxItems: 1

+

+ interrupt-names:

+ const: busy

+

+required:

+ - compatible

+ - reg

+ - vdd-5v-supply

+ - vdd-1v8-supply

+ - vio-supply

+ - cnv-gpios

+

+oneOf:

+ - required:

+ - ref-supply

+ - required:

+ - refin-supply

+

+unevaluatedProperties: false

+

+examples:

+ - |

+ #include <dt-bindings/gpio/gpio.h>

+

+ spi {

+ #address-cells = <1>;

+ #size-cells = <0>;

+

+ adc@0 {

+ compatible = "adi,ad4030-24";

+ reg = <0>;

+ spi-max-frequency = <80000000>;

+ vdd-5v-supply = <&supply_5V>;

+ vdd-1v8-supply = <&supply_1_8V>;

+ vio-supply = <&supply_1_8V>;

+ ref-supply = <&supply_5V>;

+ cnv-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;

+ reset-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;

+ };

+ };

+ pwms:

+ description: PWM signal connected to the CNV pin.

+ maxItems: 1

+

+ '#trigger-source-cells':

+ description: |

+ First cell indicates the output signal: 0 = BUSY, 1 = ALERT.

+ Second cell indicates which GPn pin is used: 0, 2 or 3.

+

+ For convenience, macros for these values are available in

+ dt-bindings/iio/adc/adi,ad4695.h.

+ const: 2

+

+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

+# Copyright 2024 Analog Devices Inc.

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/iio/adc/adi,ad4851.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Analog Devices AD485X family

+

+maintainers:

+ - Sergiu Cuciurean <sergiu.cuciurean@analog.com>

+ - Dragos Bogdan <dragos.bogdan@analog.com>

+ - Antoniu Miclaus <antoniu.miclaus@analog.com>

+

+description: |

+ Analog Devices AD485X fully buffered, 8-channel simultaneous sampling,

+ 16/20-bit, 1 MSPS data acquisition system (DAS) with differential, wide

+ common-mode range inputs.

+

+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4855.pdf

+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4856.pdf

+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4857.pdf

+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad4858.pdf

+

+$ref: /schemas/spi/spi-peripheral-props.yaml#

+

+properties:

+ compatible:

+ enum:

+ - adi,ad4851

+ - adi,ad4852

+ - adi,ad4853

+ - adi,ad4854

+ - adi,ad4855

+ - adi,ad4856

+ - adi,ad4857

+ - adi,ad4858

+ - adi,ad4858i

+

+ reg:

+ maxItems: 1

+

+ vcc-supply: true

+

+ vee-supply: true

+

+ vdd-supply: true

+

+ vddh-supply: true

+

+ vddl-supply: true

+

+ vio-supply: true

+

+ vrefbuf-supply: true

+

+ vrefio-supply: true

+

+ pwms:

+ description: PWM connected to the CNV pin.

+ maxItems: 1

+

+ io-backends:

+ maxItems: 1

+

+ pd-gpios:

+ maxItems: 1

+

+ spi-max-frequency:

+ maximum: 25000000

+

+ '#address-cells':

+ const: 1

+

+ '#size-cells':

+ const: 0

+

+patternProperties:

+ "^channel(@[0-7])?$":

+ $ref: adc.yaml

+ type: object

+ description: Represents the channels which are connected to the ADC.

+

+ properties:

+ reg:

+ description:

+ The channel number, as specified in the datasheet (from 0 to 7).

+ minimum: 0

+ maximum: 7

+

+ diff-channels:

+ description:

+ Each channel can be configured as a bipolar differential channel.

+ The ADC uses the same positive and negative inputs for this.

+ This property must be specified as 'reg' (or the channel number) for

+ both positive and negative inputs (i.e. diff-channels = <reg reg>).

+ Since the configuration is bipolar differential, the 'bipolar'

+ property is required.

+ items:

+ minimum: 0

+ maximum: 7

+

+ bipolar: true

+

+ required:

+ - reg

+

+ additionalProperties: false

+

+required:

+ - compatible

+ - reg

+ - vcc-supply

+ - vee-supply

+ - vdd-supply

+ - vio-supply

+ - pwms

+

+unevaluatedProperties: false

+

+examples:

+ - |

+ spi {

+ #address-cells = <1>;

+ #size-cells = <0>;

+

+ adc@0{

+ #address-cells = <1>;

+ #size-cells = <0>;

+ compatible = "adi,ad4858";

+ reg = <0>;

+ spi-max-frequency = <10000000>;

+ vcc-supply = <&vcc>;

+ vdd-supply = <&vdd>;

+ vee-supply = <&vee>;

+ vddh-supply = <&vddh>;

+ vddl-supply = <&vddl>;

+ vio-supply = <&vio>;

+ pwms = <&pwm_gen 0 0>;

+ io-backends = <&iio_backend>;

+

+ channel@0 {

+ reg = <0>;

+ diff-channels = <0 0>;

+ bipolar;

+ };

+

+ channel@1 {

+ reg = <1>;

+ };

+ };

+ };

+...

+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)

+# Copyright 2025 Analog Devices Inc.

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/iio/adc/adi,ad7191.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Analog Devices AD7191 ADC

+

+maintainers:

+ - Alisa-Dariana Roman <alisa.roman@analog.com>

+

+description: |

+ Bindings for the Analog Devices AD7191 ADC device. Datasheet can be

+ found here:

+ https://www.analog.com/media/en/technical-documentation/data-sheets/AD7191.pdf

+ The device's PDOWN pin must be connected to the SPI controller's chip select

+ pin.

+

+properties:

+ compatible:

+ enum:

+ - adi,ad7191

+

+ reg:

+ maxItems: 1

+

+ spi-cpol: true

+

+ spi-cpha: true

+

+ clocks:

+ maxItems: 1

+ description:

+ Must be present when CLKSEL pin is tied HIGH to select external clock

+ source (either a crystal between MCLK1 and MCLK2 pins, or a

+ CMOS-compatible clock driving MCLK2 pin). Must be absent when CLKSEL pin

+ is tied LOW to use the internal 4.92MHz clock.

+

+ interrupts:

+ maxItems: 1

+

+ avdd-supply:

+ description: AVdd voltage supply

+

+ dvdd-supply:

+ description: DVdd voltage supply

+

+ vref-supply:

+ description: Vref voltage supply

+

+ odr-gpios:

+ description:

+ ODR1 and ODR2 pins for output data rate selection. Should be defined if

+ adi,odr-value is absent.

+ minItems: 2

+ maxItems: 2

+

+ adi,odr-value:

+ $ref: /schemas/types.yaml#/definitions/uint32

+ description: |

+ Should be present if ODR pins are pin-strapped. Possible values:

+ 120 Hz (ODR1=0, ODR2=0)

+ 60 Hz (ODR1=0, ODR2=1)

+ 50 Hz (ODR1=1, ODR2=0)

+ 10 Hz (ODR1=1, ODR2=1)

+ If defined, odr-gpios must be absent.

+ enum: [120, 60, 50, 10]

+

+ pga-gpios:

+ description:

+ PGA1 and PGA2 pins for gain selection. Should be defined if adi,pga-value

+ is absent.

+ minItems: 2

+ maxItems: 2

+

+ adi,pga-value:

+ $ref: /schemas/types.yaml#/definitions/uint32

+ description: |

+ Should be present if PGA pins are pin-strapped. Possible values:

+ Gain 1 (PGA1=0, PGA2=0)

+ Gain 8 (PGA1=0, PGA2=1)

+ Gain 64 (PGA1=1, PGA2=0)

+ Gain 128 (PGA1=1, PGA2=1)

+ If defined, pga-gpios must be absent.

+ enum: [1, 8, 64, 128]

+

+ temp-gpios:

+ description: TEMP pin for temperature sensor enable.

+ maxItems: 1

+

+ chan-gpios:

+ description: CHAN pin for input channel selection.

+ maxItems: 1

+

+required:

+ - compatible

+ - reg

+ - interrupts

+ - avdd-supply

+ - dvdd-supply

+ - vref-supply

+ - spi-cpol

+ - spi-cpha

+ - temp-gpios

+ - chan-gpios

+

+allOf:

+ - $ref: /schemas/spi/spi-peripheral-props.yaml#

+ - oneOf:

+ - required:

+ - adi,odr-value

+ - required:

+ - odr-gpios

+ - oneOf:

+ - required:

+ - adi,pga-value

+ - required:

+ - pga-gpios

+

+unevaluatedProperties: false

+

+examples:

+ - |

+ #include <dt-bindings/gpio/gpio.h>

+ #include <dt-bindings/interrupt-controller/irq.h>

+

+ spi {

+ #address-cells = <1>;

+ #size-cells = <0>;

+

+ adc@0 {

+ compatible = "adi,ad7191";

+ reg = <0>;

+ spi-max-frequency = <1000000>;

+ spi-cpol;

+ spi-cpha;

+ clocks = <&ad7191_mclk>;

+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;

+ interrupt-parent = <&gpio>;

+ avdd-supply = <&avdd>;

+ dvdd-supply = <&dvdd>;

+ vref-supply = <&vref>;

+ adi,pga-value = <1>;

+ odr-gpios = <&gpio 23 GPIO_ACTIVE_HIGH>, <&gpio 24 GPIO_ACTIVE_HIGH>;

+ temp-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;

+ chan-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;

+ };

+ };

+ * https://www.analog.com/en/products/adaq4381-4.html

+ - adi,adaq4381-4

+ - adi,adaq4381-4

+ - adi,adaq4381-4

+ In some cases, the AXI ADC interface is used to perform specialized

+ operation to a particular ADC, e.g access the physical bus through

+ specific registers to write ADC registers.

+ In this case, we use a different compatible which indicates the target

+ IP core's name.

+ The following IP is currently supported:

+ - AXI AD7606x: specialized version of the IP core for all the chips from

+ the ad7606 family.

+ https://analogdevicesinc.github.io/hdl/library/axi_ad485x/index.html

+ http://analogdevicesinc.github.io/hdl/library/axi_ad7606x/index.html

+ - adi,axi-ad7606x

+ - adi,axi-ad485x

+ '#address-cells':

+ const: 1

+

+ '#size-cells':

+ const: 0

+

+patternProperties:

+ "^adc@[0-9a-f]+$":

+ type: object

+ properties:

+ reg:

+ maxItems: 1

+ additionalProperties: true

+ required:

+ - compatible

+ - reg

+

+allOf:

+ - if:

+ properties:

+ compatible:

+ not:

+ contains:

+ const: adi,axi-ad7606x

+ then:

+ properties:

+ '#address-cells': false

+ '#size-cells': false

+ patternProperties:

+ "^adc@[0-9a-f]+$": false

+

+ adc@44a00000 {

+ - |

+ #include <dt-bindings/gpio/gpio.h>

+ parallel_bus_controller@44a00000 {

+ compatible = "adi,axi-ad7606x";

+ reg = <0x44a00000 0x10000>;

+ dmas = <&rx_dma 0>;

+ dma-names = "rx";

+ clocks = <&ext_clk>;

+ #address-cells = <1>;

+ #size-cells = <0>;

+

+ adc@0 {

+ compatible = "adi,ad7606b";

+ reg = <0>;

+ pwms = <&axi_pwm_gen 0 0>;

+ pwm-names = "convst1";

+ avcc-supply = <&adc_vref>;

+ vdrive-supply = <&vdd_supply>;

+ reset-gpios = <&gpio0 91 GPIO_ACTIVE_HIGH>;

+ standby-gpios = <&gpio0 90 GPIO_ACTIVE_LOW>;

+ adi,range-gpios = <&gpio0 89 GPIO_ACTIVE_HIGH>;

+ adi,oversampling-ratio-gpios = <&gpio0 88 GPIO_ACTIVE_HIGH

+ &gpio0 87 GPIO_ACTIVE_HIGH

+ &gpio0 86 GPIO_ACTIVE_HIGH>;

+ io-backends = <&parallel_bus_controller>;

+ };

+ };

+ oneOf:

+ - enum:

+ - nxp,imx93-adc

+ - items:

+ - enum:

+ - nxp,imx94-adc

+ - nxp,imx95-adc

+ - const: nxp,imx93-adc

+ - const: rockchip,rk3528-saradc

+ - const: rockchip,rk3562-saradc

+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/iio/adc/ti,ads7138.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Texas Instruments ADS7128/ADS7138 analog-to-digital converter (ADC)

+

+maintainers:

+ - Tobias Sperling <tobias.sperling@softing.com>

+

+description: |

+ The ADS7128 and ADS7138 chips are 12-bit, 8 channel analog-to-digital

+ converters (ADC) with build-in digital window comparator (DWC), using the

+ I2C interface.

+ ADS7128 differs in the addition of further hardware features, like a

+ root-mean-square (RMS) and a zero-crossing-detect (ZCD) module.

+

+ Datasheets:

+ https://www.ti.com/product/ADS7128

+ https://www.ti.com/product/ADS7138

+

+properties:

+ compatible:

+ enum:

+ - ti,ads7128

+ - ti,ads7138

+

+ reg:

+ maxItems: 1

+

+ avdd-supply:

+ description:

+ The regulator used as analog supply voltage as well as reference voltage.

+

+ interrupts:

+ description:

+ Interrupt on ALERT pin, triggers on low level.

+ maxItems: 1

+

+required:

+ - compatible

+ - reg

+ - avdd-supply

+

+additionalProperties: false

+

+examples:

+ - |

+ #include <dt-bindings/interrupt-controller/irq.h>

+ i2c {

+ #address-cells = <1>;

+ #size-cells = <0>;

+

+ adc@10 {

+ compatible = "ti,ads7138";

+ reg = <0x10>;

+ avdd-supply = <&reg_stb_3v3>;

+ interrupt-parent = <&gpio2>;

+ interrupts = <12 IRQ_TYPE_LEVEL_LOW>;

+ };

+ };

+...

+ reg = <0>;

+ compatible = "adi,ad5390-5";

+ vref-supply = <&dacvref>;

+ #address-cells = <1>;

+ #size-cells = <0>;

+ dac@42 {

+ reg = <0x42>;

+ compatible = "adi,ad5380-3";

+ };

+ Must be "clkin" if the input reference is single ended or "clkin-diff"

+ if the input reference is differential.

+ enum: [clkin, clkin-diff]

+ #address-cells = <1>;

+ #size-cells = <0>;

+ temperature-sensor@43 {

+ compatible = "sciosense,ens210";

+ reg = <0x43>;

+ };

+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/iio/imu/adi,adis16550.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Analog Devices ADIS16550 and similar IMUs

+

+maintainers:

+ - Nuno Sa <nuno.sa@analog.com>

+ - Ramona Gradinariu <ramona.gradinariu@analog.com>

+ - Antoniu Miclaus <antoniu.miclaus@analog.com>

+ - Robert Budai <robert.budai@analog.com>

+

+properties:

+ compatible:

+ enum:

+ - adi,adis16550

+

+ reg:

+ maxItems: 1

+

+ spi-cpha: true

+

+ spi-cpol: true

+

+ spi-max-frequency:

+ maximum: 15000000

+

+ vdd-supply: true

+

+ interrupts:

+ maxItems: 1

+

+ reset-gpios:

+ description:

+ Active low RESET pin.

+ maxItems: 1

+

+ clocks:

+ description: If not provided, then the internal clock is used.

+ maxItems: 1

+

+required:

+ - compatible

+ - reg

+ - interrupts

+ - spi-cpha

+ - spi-cpol

+ - spi-max-frequency

+ - vdd-supply

+

+allOf:

+ - $ref: /schemas/spi/spi-peripheral-props.yaml#

+

+additionalProperties: false

+

+examples:

+ - |

+ #include <dt-bindings/interrupt-controller/irq.h>

+ spi {

+ #address-cells = <1>;

+ #size-cells = <0>;

+ imu@0 {

+ compatible = "adi,adis16550";

+ reg = <0>;

+ spi-max-frequency = <15000000>;

+ spi-cpol;

+ spi-cpha;

+ vdd-supply = <&vdd>;

+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;

+ interrupt-parent = <&gpio>;

+ };

+ };

+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/iio/light/brcm,apds9160.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Broadcom Combined Proximity & Ambient light sensor

+

+maintainers:

+ - Mikael Gonella-Bolduc <m.gonella.bolduc@gmail.com>

+

+description: |

+ Datasheet: https://docs.broadcom.com/docs/APDS-9160-003-DS

+

+properties:

+ compatible:

+ enum:

+ - brcm,apds9160

+

+ reg:

+ maxItems: 1

+

+ interrupts:

+ maxItems: 1

+

+ vdd-supply: true

+

+ ps-cancellation-duration:

+ $ref: /schemas/types.yaml#/definitions/uint32

+ description:

+ Proximity sensor cancellation pulse duration in half clock cycles.

+ This parameter determines a cancellation pulse duration.

+ The cancellation is applied in the integration phase to cancel out

+ unwanted reflected light from very near objects such as tempered glass

+ in front of the sensor.

+ default: 0

+ maximum: 63

+

+ ps-cancellation-current-picoamp:

+ description:

+ Proximity sensor crosstalk cancellation current in picoampere.

+ This parameter adjusts the current in steps of 2400 pA up to 276000 pA.

+ The provided value must be a multiple of 2400 and in one of these ranges

+ [60000 - 96000]

+ [120000 - 156000]

+ [180000 - 216000]

+ [240000 - 276000]

+ This parameter is used in conjunction with the cancellation duration.

+ minimum: 60000

+ maximum: 276000

+ multipleOf: 2400

+

+required:

+ - compatible

+ - reg

+ - vdd-supply

+

+additionalProperties: false

+

+examples:

+ - |

+ #include <dt-bindings/interrupt-controller/irq.h>

+

+ i2c {

+ #address-cells = <1>;

+ #size-cells = <0>;

+

+ light-sensor@53 {

+ compatible = "brcm,apds9160";

+ reg = <0x53>;

+ vdd-supply = <&vdd_reg>;

+ interrupts = <29 IRQ_TYPE_EDGE_FALLING>;

+ interrupt-parent = <&pinctrl>;

+ ps-cancellation-duration = <10>;

+ ps-cancellation-current-picoamp = <62400>;

+ };

+ };

+...

+title: Dyna-Image AL3000a/AL3010 sensor

+ enum:

+ - dynaimage,al3000a

+ - dynaimage,al3010

+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/iio/magnetometer/silabs,si7210.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Si7210 magnetic position and temperature sensor

+

+maintainers:

+ - Antoni Pokusinski <apokusinski01@gmail.com>

+

+description: |

+ Silabs Si7210 I2C Hall effect magnetic position and temperature sensor.

+ https://www.silabs.com/documents/public/data-sheets/si7210-datasheet.pdf

+

+properties:

+ compatible:

+ const: silabs,si7210

+

+ reg:

+ maxItems: 1

+

+ interrupts:

+ maxItems: 1

+

+ vdd-supply:

+ description: Regulator that provides power to the sensor

+

+required:

+ - compatible

+ - reg

+

+additionalProperties: false

+

+examples:

+ - |

+ #include <dt-bindings/interrupt-controller/irq.h>

+ i2c {

+ #address-cells = <1>;

+ #size-cells = <0>;

+ magnetometer@30 {

+ compatible = "silabs,si7210";

+ reg = <0x30>;

+ interrupt-parent = <&gpio1>;

+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;

+ vdd-supply = <&vdd_3v3_reg>;

+ };

+ };

+ #address-cells = <1>;

+ #size-cells = <0>;

+

+ temperature-sensor@0 {

+ compatible = "maxim,max31865";

+ reg = <0>;

+ spi-max-frequency = <400000>;

+ spi-cpha;

+ maxim,3-wire;

+ };

+ compatible = "ti,tmp117";

+ reg = <0x48>;

+ vcc-supply = <&pmic_reg_3v3>;

+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

+%YAML 1.2

+---

+

+$id: http://devicetree.org/schemas/input/gpio-matrix-keypad.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: GPIO matrix keypad

+

+maintainers:

+ - Marek Vasut <marek.vasut@gmail.com>

+

+description:

+ GPIO driven matrix keypad is used to interface a SoC with a matrix keypad.

+ The matrix keypad supports multiple row and column lines, a key can be

+ placed at each intersection of a unique row and a unique column. The matrix

+ keypad can sense a key-press and key-release by means of GPIO lines and

+ report the event using GPIO interrupts to the cpu.

+

+allOf:

+ - $ref: /schemas/input/matrix-keymap.yaml#

+

+properties:

+ compatible:

+ const: gpio-matrix-keypad

+

+ row-gpios:

+ description:

+ List of GPIOs used as row lines. The gpio specifier for this property

+ depends on the gpio controller to which these row lines are connected.

+

+ col-gpios:

+ description:

+ List of GPIOs used as column lines. The gpio specifier for this property

+ depends on the gpio controller to which these column lines are connected.

+

+ linux,keymap: true

+

+ linux,no-autorepeat:

+ type: boolean

+ description: Do not enable autorepeat feature.

+

+ gpio-activelow:

+ type: boolean

+ description:

+ Force GPIO polarity to active low.

+ In the absence of this property GPIOs are treated as active high.

+

+ debounce-delay-ms:

+ description: Debounce interval in milliseconds.

+ default: 0

+

+ col-scan-delay-us:

+ description:

+ Delay, measured in microseconds, that is needed

+ before we can scan keypad after activating column gpio.

+ default: 0

+

+ all-cols-on-delay-us:

+ description:

+ Delay, measured in microseconds, that is needed

+ after activating all column gpios.

+ default: 0

+

+ drive-inactive-cols:

+ type: boolean

+ description:

+ Drive inactive columns during scan,

+ default is to turn inactive columns into inputs.

+

+ wakeup-source: true

+

+required:

+ - compatible

+ - row-gpios

+ - col-gpios

+ - linux,keymap

+

+additionalProperties: false

+

+examples:

+ - |

+ matrix-keypad {

+ compatible = "gpio-matrix-keypad";

+ debounce-delay-ms = <5>;

+ col-scan-delay-us = <2>;

+

+ row-gpios = <&gpio2 25 0

+ &gpio2 26 0

+ &gpio2 27 0>;

+

+ col-gpios = <&gpio2 21 0

+ &gpio2 22 0>;

+

+ linux,keymap = <0x0000008B

+ 0x0100009E

+ 0x02000069

+ 0x0001006A

+ 0x0101001C

+ 0x0201006C>;

+

+ wakeup-source;

+ };

+ #include <dt-bindings/input/input.h>

+ #include <dt-bindings/interrupt-controller/irq.h>

+ pmic {

+ #address-cells = <1>;

+ #size-cells = <0>;

+ keypad@148 {

+ compatible = "qcom,pm8921-keypad";

+ reg = <0x148>;

+ interrupt-parent = <&pmicintc>;

+ interrupts = <74 IRQ_TYPE_EDGE_RISING>, <75 IRQ_TYPE_EDGE_RISING>;

+ linux,keymap = <

+ MATRIX_KEY(0, 0, KEY_VOLUMEUP)

+ MATRIX_KEY(0, 1, KEY_VOLUMEDOWN)

+ MATRIX_KEY(0, 2, KEY_CAMERA_FOCUS)

+ MATRIX_KEY(0, 3, KEY_CAMERA)

+ >;

+ keypad,num-rows = <1>;

+ keypad,num-columns = <5>;

+ debounce = <15>;

+ scan-delay = <32>;

+ row-hold = <91500>;

+ };

+ };

+ #include <dt-bindings/interrupt-controller/irq.h>

+ ssbi {

+ #address-cells = <1>;

+ #size-cells = <0>;

+ pmic@0 {

+ reg = <0x0>;

+ #address-cells = <1>;

+ #size-cells = <0>;

+ pwrkey@1c {

+ compatible = "qcom,pm8921-pwrkey";

+ reg = <0x1c>;

+ interrupt-parent = <&pmicint>;

+ interrupts = <50 IRQ_TYPE_EDGE_RISING>, <51 IRQ_TYPE_EDGE_RISING>;

+ debounce = <15625>;

+ pull-up;

+ };

+ };

+ };

+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/input/touchscreen/apple,z2-multitouch.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Apple touchscreens attached using the Z2 protocol

+

+maintainers:

+ - Sasha Finkelstein <fnkl.kernel@gmail.com>

+

+description: A series of touschscreen controllers used in Apple products

+

+allOf:

+ - $ref: touchscreen.yaml#

+ - $ref: /schemas/spi/spi-peripheral-props.yaml#

+

+properties:

+ compatible:

+ enum:

+ - apple,j293-touchbar

+ - apple,j493-touchbar

+

+ interrupts:

+ maxItems: 1

+

+ reset-gpios:

+ maxItems: 1

+

+ firmware-name:

+ maxItems: 1

+

+ apple,z2-cal-blob:

+ $ref: /schemas/types.yaml#/definitions/uint8-array

+ maxItems: 4096

+ description:

+ Calibration blob supplied by the bootloader

+

+required:

+ - compatible

+ - interrupts

+ - reset-gpios

+ - firmware-name

+ - touchscreen-size-x

+ - touchscreen-size-y

+

+unevaluatedProperties: false

+

+examples:

+ - |

+ #include <dt-bindings/gpio/gpio.h>

+ #include <dt-bindings/interrupt-controller/irq.h>

+

+ spi {

+ #address-cells = <1>;

+ #size-cells = <0>;

+

+ touchscreen@0 {

+ compatible = "apple,j293-touchbar";

+ reg = <0>;

+ spi-max-frequency = <11500000>;

+ reset-gpios = <&pinctrl_ap 139 GPIO_ACTIVE_LOW>;

+ interrupts-extended = <&pinctrl_ap 194 IRQ_TYPE_EDGE_FALLING>;

+ firmware-name = "apple/dfrmtfw-j293.bin";

+ touchscreen-size-x = <23045>;

+ touchscreen-size-y = <640>;

+ };

+ };

+

+...

+ - goodix,gt9897

+ compatible = "ti,tsc2046";

+ reg = <0>; /* CS0 */

+ interrupt-parent = <&gpio1>;

+ interrupts = <8 0>; /* BOOT6 / GPIO 8 */

+ pendown-gpio = <&gpio1 8 0>;

+ spi-max-frequency = <1000000>;

+ vcc-supply = <&reg_vcc3>;

+ wakeup-source;

+

+ ti,pressure-max = /bits/ 16 <255>;

+ ti,x-max = /bits/ 16 <8000>;

+ ti,x-min = /bits/ 16 <0>;

+ ti,x-plate-ohms = /bits/ 16 <40>;

+ ti,y-max = /bits/ 16 <4800>;

+ ti,y-min = /bits/ 16 <0>;

+ };

+# # Copyright (c) 2021 Aspeed Technology Inc.

+ - enum:

+ - allwinner,sun50i-a100-usb-phy

+ - allwinner,sun55i-a523-usb-phy

+ - rockchip,rk3562-naneng-combphy

+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/phy/qcom,ipq5332-uniphy-pcie-phy.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Qualcomm UNIPHY PCIe 28LP PHY

+

+maintainers:

+ - Nitheesh Sekar <quic_nsekar@quicinc.com>

+ - Varadarajan Narayanan <quic_varada@quicinc.com>

+

+description:

+ PCIe and USB combo PHY found in Qualcomm IPQ5332 SoC

+

+properties:

+ compatible:

+ enum:

+ - qcom,ipq5332-uniphy-pcie-phy

+

+ reg:

+ maxItems: 1

+

+ clocks:

+ items:

+ - description: pcie pipe clock

+ - description: pcie ahb clock

+

+ resets:

+ items:

+ - description: phy reset

+ - description: ahb reset

+ - description: cfg reset

+

+ "#phy-cells":

+ const: 0

+

+ "#clock-cells":

+ const: 0

+

+ num-lanes:

+ $ref: /schemas/types.yaml#/definitions/uint32

+ enum: [1, 2]

+

+required:

+ - compatible

+ - reg

+ - clocks

+ - resets

+ - "#phy-cells"

+ - "#clock-cells"

+ - num-lanes

+

+additionalProperties: false

+

+examples:

+ - |

+ #include <dt-bindings/clock/qcom,ipq5332-gcc.h>

+

+ pcie0_phy: phy@4b0000 {

+ compatible = "qcom,ipq5332-uniphy-pcie-phy";

+ reg = <0x004b0000 0x800>;

+

+ clocks = <&gcc GCC_PCIE3X1_0_PIPE_CLK>,

+ <&gcc GCC_PCIE3X1_PHY_AHB_CLK>;

+

+ resets = <&gcc GCC_PCIE3X1_0_PHY_BCR>,

+ <&gcc GCC_PCIE3X1_PHY_AHB_CLK_ARES>,

+ <&gcc GCC_PCIE3X1_0_PHY_PHY_BCR>;

+

+ #clock-cells = <0>;

+

+ #phy-cells = <0>;

+

+ num-lanes = <1>;

+ };

+ - qcom,qcs8300-qmp-gen4x2-pcie-phy

+ - qcom,x1p42100-qmp-gen4x4-pcie-phy

+ - qcom,x1p42100-qmp-gen4x4-pcie-phy

+ - qcom,x1p42100-qmp-gen4x4-pcie-phy

+ - qcom,qcs8300-qmp-gen4x2-pcie-phy

+ - qcom,sm8750-qmp-ufs-phy

+ - qcom,sm8750-qmp-ufs-phy

+ oneOf:

+ - enum:

+ - rockchip,rk3588-hdptx-phy

+ - items:

+ - enum:

+ - rockchip,rk3576-hdptx-phy

+ - const: rockchip,rk3588-hdptx-phy

+ minItems: 4

+ maxItems: 7

+ minItems: 4

+ maxItems: 7

+allOf:

+ - if:

+ properties:

+ compatible:

+ contains:

+ enum:

+ - rockchip,rk3576-hdptx-phy

+ then:

+ properties:

+ resets:

+ minItems: 4

+ maxItems: 4

+ reset-names:

+ items:

+ - const: apb

+ - const: init

+ - const: cmn

+ - const: lane

+ else:

+ properties:

+ resets:

+ minItems: 7

+ maxItems: 7

+ reset-names:

+ items:

+ - const: phy

+ - const: apb

+ - const: init

+ - const: cmn

+ - const: lane

+ - const: ropll

+ - const: lcpll

+

+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

+%YAML 1.2

+---

+$id: http://devicetree.org/schemas/phy/rockchip,rk3588-mipi-dcphy.yaml#

+$schema: http://devicetree.org/meta-schemas/core.yaml#

+

+title: Rockchip MIPI D-/C-PHY with Samsung IP block

+

+maintainers:

+ - Guochun Huang <hero.huang@rock-chips.com>

+ - Heiko Stuebner <heiko@sntech.de>

+

+properties: