diff options
Diffstat (limited to 'Documentation')
356 files changed, 13257 insertions, 2614 deletions
diff --git a/Documentation/ABI/stable/sysfs-devices-node b/Documentation/ABI/stable/sysfs-devices-node index 402af4b2b905..a02707cb7cbc 100644 --- a/Documentation/ABI/stable/sysfs-devices-node +++ b/Documentation/ABI/stable/sysfs-devices-node @@ -177,6 +177,12 @@ Description: The cache write policy: 0 for write-back, 1 for write-through, other or unknown. +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/devices/system/node/nodeX/x86/sgx_total_bytes Date: November 2021 Contact: Jarkko Sakkinen <jarkko@kernel.org> diff --git a/Documentation/ABI/testing/debugfs-dwc-pcie b/Documentation/ABI/testing/debugfs-dwc-pcie new file mode 100644 index 000000000000..92b76f52a408 --- /dev/null +++ b/Documentation/ABI/testing/debugfs-dwc-pcie @@ -0,0 +1,157 @@ +What: /sys/kernel/debug/dwc_pcie_<dev>/rasdes_debug/lane_detect +Date: February 2025 +Contact: Shradha Todi <shradha.t@samsung.com> +Description: (RW) Write the lane number to be checked for detection. Read + will return whether PHY indicates receiver detection on the + selected lane. The default selected lane is Lane0. + +What: /sys/kernel/debug/dwc_pcie_<dev>/rasdes_debug/rx_valid +Date: February 2025 +Contact: Shradha Todi <shradha.t@samsung.com> +Description: (RW) Write the lane number to be checked as valid or invalid. + Read will return the status of PIPE RXVALID signal of the + selected lane. The default selected lane is Lane0. + +What: /sys/kernel/debug/dwc_pcie_<dev>/rasdes_err_inj/<error> +Date: February 2025 +Contact: Shradha Todi <shradha.t@samsung.com> +Description: The "rasdes_err_inj" is a directory which can be used to inject + errors into the system. The possible errors that can be injected + are: + + 1) tx_lcrc - TLP LCRC error injection TX Path + 2) b16_crc_dllp - 16b CRC error injection of ACK/NAK DLLP + 3) b16_crc_upd_fc - 16b CRC error injection of Update-FC DLLP + 4) tx_ecrc - TLP ECRC error injection TX Path + 5) fcrc_tlp - TLP's FCRC error injection TX Path + 6) parity_tsos - Parity error of TSOS + 7) parity_skpos - Parity error on SKPOS + 8) rx_lcrc - LCRC error injection RX Path + 9) rx_ecrc - ECRC error injection RX Path + 10) tlp_err_seq - TLPs SEQ# error + 11) ack_nak_dllp_seq - DLLPS ACK/NAK SEQ# error + 12) ack_nak_dllp - ACK/NAK DLLPs transmission block + 13) upd_fc_dllp - UpdateFC DLLPs transmission block + 14) nak_dllp - Always transmission for NAK DLLP + 15) inv_sync_hdr_sym - Invert SYNC header + 16) com_pad_ts1 - COM/PAD TS1 order set + 17) com_pad_ts2 - COM/PAD TS2 order set + 18) com_fts - COM/FTS FTS order set + 19) com_idl - COM/IDL E-idle order set + 20) end_edb - END/EDB symbol + 21) stp_sdp - STP/SDP symbol + 22) com_skp - COM/SKP SKP order set + 23) posted_tlp_hdr - Posted TLP Header credit value control + 24) non_post_tlp_hdr - Non-Posted TLP Header credit value control + 25) cmpl_tlp_hdr - Completion TLP Header credit value control + 26) posted_tlp_data - Posted TLP Data credit value control + 27) non_post_tlp_data - Non-Posted TLP Data credit value control + 28) cmpl_tlp_data - Completion TLP Data credit value control + 29) duplicate_tlp - Generates duplicate TLPs + 30) nullified_tlp - Generates Nullified TLPs + + (WO) Write to the attribute will prepare controller to inject + the respective error in the next transmission of data. + + Parameter required to write will change in the following ways: + + - Errors 9 and 10 are sequence errors. The write command: + + echo <count> <diff> > /sys/kernel/debug/dwc_pcie_<dev>/rasdes_err_inj/<error> + + <count> + Number of errors to be injected + <diff> + The difference to add or subtract from natural + sequence number to generate sequence error. + Allowed range from -4095 to 4095 + + - Errors 23 to 28 are credit value error insertions. The write + command: + + echo <count> <diff> <vc> > /sys/kernel/debug/dwc_pcie_<dev>/rasdes_err_inj/<error> + + <count> + Number of errors to be injected + <diff> + The difference to add or subtract from UpdateFC + credit value. Allowed range from -4095 to 4095 + <vc> + Target VC number + + - All other errors. The write command: + + echo <count> > /sys/kernel/debug/dwc_pcie_<dev>/rasdes_err_inj/<error> + + <count> + Number of errors to be injected + +What: /sys/kernel/debug/dwc_pcie_<dev>/rasdes_event_counters/<event>/counter_enable +Date: February 2025 +Contact: Shradha Todi <shradha.t@samsung.com> +Description: The "rasdes_event_counters" is the directory which can be used + to collect statistical data about the number of times a certain + event has occurred in the controller. The list of possible + events are: + + 1) EBUF Overflow + 2) EBUF Underrun + 3) Decode Error + 4) Running Disparity Error + 5) SKP OS Parity Error + 6) SYNC Header Error + 7) Rx Valid De-assertion + 8) CTL SKP OS Parity Error + 9) 1st Retimer Parity Error + 10) 2nd Retimer Parity Error + 11) Margin CRC and Parity Error + 12) Detect EI Infer + 13) Receiver Error + 14) RX Recovery Req + 15) N_FTS Timeout + 16) Framing Error + 17) Deskew Error + 18) Framing Error In L0 + 19) Deskew Uncompleted Error + 20) Bad TLP + 21) LCRC Error + 22) Bad DLLP + 23) Replay Number Rollover + 24) Replay Timeout + 25) Rx Nak DLLP + 26) Tx Nak DLLP + 27) Retry TLP + 28) FC Timeout + 29) Poisoned TLP + 30) ECRC Error + 31) Unsupported Request + 32) Completer Abort + 33) Completion Timeout + 34) EBUF SKP Add + 35) EBUF SKP Del + + (RW) Write 1 to enable the event counter and write 0 to disable + the event counter. Read will return whether the counter is + currently enabled or disabled. Counter is disabled by default. + +What: /sys/kernel/debug/dwc_pcie_<dev>/rasdes_event_counters/<event>/counter_value +Date: February 2025 +Contact: Shradha Todi <shradha.t@samsung.com> +Description: (RO) Read will return the current value of the event counter. + To reset the counter, counter should be disabled first and then + enabled back using the "counter_enable" attribute. + +What: /sys/kernel/debug/dwc_pcie_<dev>/rasdes_event_counters/<event>/lane_select +Date: February 2025 +Contact: Shradha Todi <shradha.t@samsung.com> +Description: (RW) Some lanes in the event list are lane specific events. + These include events from 1 to 11, as well as, 34 and 35. Write + the lane number for which you wish the counter to be enabled, + disabled, or value dumped. Read will return the current + selected lane number. Lane0 is selected by default. + +What: /sys/kernel/debug/dwc_pcie_<dev>/ltssm_status +Date: February 2025 +Contact: Hans Zhang <18255117159@163.com> +Description: (RO) Read will return the current PCIe LTSSM state in both + string and raw value. diff --git a/Documentation/ABI/testing/sysfs-block-zram b/Documentation/ABI/testing/sysfs-block-zram index 1ef69e0271f9..36c57de0a10a 100644 --- a/Documentation/ABI/testing/sysfs-block-zram +++ b/Documentation/ABI/testing/sysfs-block-zram @@ -22,14 +22,6 @@ Description: device. The reset operation frees all the memory associated with this device. -What: /sys/block/zram<id>/max_comp_streams -Date: February 2014 -Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> -Description: - The max_comp_streams file is read-write and specifies the - number of backend's zcomp_strm compression streams (number of - concurrent compress operations). - What: /sys/block/zram<id>/comp_algorithm Date: February 2014 Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm index 53cb454b60d0..a341b08ae70b 100644 --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm @@ -257,3 +257,18 @@ Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_t Description: (RW) Set/Get the MSR(mux select register) for the CMB subunit TPDM. + +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. diff --git a/Documentation/ABI/testing/sysfs-bus-counter b/Documentation/ABI/testing/sysfs-bus-counter index 73ac84c0bca7..3e8259e56d38 100644 --- a/Documentation/ABI/testing/sysfs-bus-counter +++ b/Documentation/ABI/testing/sysfs-bus-counter @@ -34,6 +34,14 @@ Contact: linux-iio@vger.kernel.org Description: Count data of Count Y represented as a string. +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/capture KernelVersion: 6.1 Contact: linux-iio@vger.kernel.org @@ -301,6 +309,7 @@ Description: What: /sys/bus/counter/devices/counterX/cascade_counts_enable_component_id What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select_component_id +What: /sys/bus/counter/devices/counterX/countY/compare_component_id What: /sys/bus/counter/devices/counterX/countY/capture_component_id What: /sys/bus/counter/devices/counterX/countY/ceiling_component_id What: /sys/bus/counter/devices/counterX/countY/floor_component_id diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 3f5627a1210a..99bb3faf7a0e 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -1,5 +1,5 @@ What: /sys/bus/cxl/flush -Date: Januarry, 2022 +Date: January, 2022 KernelVersion: v5.18 Contact: linux-cxl@vger.kernel.org Description: @@ -18,6 +18,24 @@ Description: specification. +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). + + What: /sys/bus/cxl/devices/memX/ram/size Date: December, 2020 KernelVersion: v5.12 @@ -33,7 +51,7 @@ Date: May, 2023 KernelVersion: v6.8 Contact: linux-cxl@vger.kernel.org Description: - (RO) For CXL host platforms that support "QoS Telemmetry" + (RO) For CXL host platforms that support "QoS Telemetry" this attribute conveys a comma delimited list of platform specific cookies that identifies a QoS performance class for the volatile partition of the CXL mem device. These @@ -60,7 +78,7 @@ Date: May, 2023 KernelVersion: v6.8 Contact: linux-cxl@vger.kernel.org Description: - (RO) For CXL host platforms that support "QoS Telemmetry" + (RO) For CXL host platforms that support "QoS Telemetry" this attribute conveys a comma delimited list of platform specific cookies that identifies a QoS performance class for the persistent partition of the CXL mem device. These @@ -321,14 +339,13 @@ KernelVersion: v6.0 Contact: linux-cxl@vger.kernel.org Description: (RW) When a CXL decoder is of devtype "cxl_decoder_endpoint" it - 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', - 'mixed', or 'none'. The 'mixed' indication is for error cases - when a decoder straddles the volatile/persistent partition - boundary, and 'none' indicates the decoder is not actively - decoding, or no DPA allocation policy has been set. + 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. 'mode' can be written, when the decoder is in the 'disabled' state, with either 'ram' or 'pmem' to set the boundaries for the @@ -423,7 +440,7 @@ Date: May, 2023 KernelVersion: v6.5 Contact: linux-cxl@vger.kernel.org Description: - (RO) For CXL host platforms that support "QoS Telemmetry" this + (RO) For CXL host platforms that support "QoS Telemetry" this root-decoder-only attribute conveys a platform specific cookie that identifies a QoS performance class for the CXL Window. This class-id can be compared against a similar "qos_class" @@ -586,3 +603,15 @@ Description: See Documentation/ABI/stable/sysfs-devices-node. access0 provides the number to the closest initiator and access1 provides the number to the closest CPU. + + +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. diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 25d366d452a5..722aa989baac 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -2268,7 +2268,7 @@ Description: representing the sensor unique ID number. What: /sys/bus/iio/devices/iio:deviceX/filter_type_available -What: /sys/bus/iio/devices/iio:deviceX/in_voltage-voltage_filter_mode_available +What: /sys/bus/iio/devices/iio:deviceX/in_voltage-voltage_filter_type_available KernelVersion: 6.1 Contact: linux-iio@vger.kernel.org Description: @@ -2290,6 +2290,16 @@ Description: * "sinc3+pf2" - Sinc3 + device specific Post Filter 2. * "sinc3+pf3" - Sinc3 + device specific Post Filter 3. * "sinc3+pf4" - Sinc3 + device specific Post Filter 4. + * "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/.../events/in_proximity_thresh_either_runningperiod KernelVersion: 6.6 diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad4130 b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad4130 new file mode 100644 index 000000000000..d3fad27421d6 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad4130 @@ -0,0 +1,20 @@ +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. diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index 5da6a14dc326..69f952fffec7 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -583,3 +583,32 @@ Description: enclosure-specific indications "specific0" to "specific7", hence the corresponding led class devices are unavailable if the DSM interface is used. + +What: /sys/bus/pci/devices/.../doe_features +Date: March 2025 +Contact: Linux PCI developers <linux-pci@vger.kernel.org> +Description: + This directory contains a list of the supported Data Object + Exchange (DOE) features. The features are the file name. + The contents of each file is the raw Vendor ID and data + object feature values. + + The value comes from the device and specifies the vendor and + data object type supported. The lower (RHS of the colon) is + the data object type in hex. The upper (LHS of the colon) + is the vendor ID. + + As all DOE devices must support the DOE discovery feature, + if DOE is supported you will at least see the doe_discovery + file, with this contents: + + # cat doe_features/doe_discovery + 0001:00 + + If the device supports other features you will see other + files as well. For example if CMA/SPDM and secure CMA/SPDM + are supported the doe_features directory will look like + this: + + # ls doe_features + 0001:01 0001:02 doe_discovery diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc index c12316dfd973..a6e400364932 100644 --- a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc +++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc @@ -17,7 +17,7 @@ Description: Read only. Returns the firmware version of Intel MAX10 What: /sys/bus/.../drivers/intel-m10-bmc/.../mac_address Date: January 2021 KernelVersion: 5.12 -Contact: Peter Colberg <peter.colberg@intel.com> +Contact: Peter Colberg <peter.colberg@altera.com> Description: Read only. Returns the first MAC address in a block of sequential MAC addresses assigned to the board that is managed by the Intel MAX10 BMC. It is stored in @@ -28,7 +28,7 @@ Description: Read only. Returns the first MAC address in a block What: /sys/bus/.../drivers/intel-m10-bmc/.../mac_count Date: January 2021 KernelVersion: 5.12 -Contact: Peter Colberg <peter.colberg@intel.com> +Contact: Peter Colberg <peter.colberg@altera.com> Description: Read only. Returns the number of sequential MAC addresses assigned to the board managed by the Intel MAX10 BMC. This value is stored in FLASH and is mirrored diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update index 9051695d2211..c69fd3894eb4 100644 --- a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update +++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update @@ -1,7 +1,7 @@ What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/sr_root_entry_hash Date: Sep 2022 KernelVersion: 5.20 -Contact: Peter Colberg <peter.colberg@intel.com> +Contact: Peter Colberg <peter.colberg@altera.com> Description: Read only. Returns the root entry hash for the static region if one is programmed, else it returns the string: "hash not programmed". This file is only @@ -11,7 +11,7 @@ Description: Read only. Returns the root entry hash for the static What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/pr_root_entry_hash Date: Sep 2022 KernelVersion: 5.20 -Contact: Peter Colberg <peter.colberg@intel.com> +Contact: Peter Colberg <peter.colberg@altera.com> Description: Read only. Returns the root entry hash for the partial reconfiguration region if one is programmed, else it returns the string: "hash not programmed". This file @@ -21,7 +21,7 @@ Description: Read only. Returns the root entry hash for the partial What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/bmc_root_entry_hash Date: Sep 2022 KernelVersion: 5.20 -Contact: Peter Colberg <peter.colberg@intel.com> +Contact: Peter Colberg <peter.colberg@altera.com> Description: Read only. Returns the root entry hash for the BMC image if one is programmed, else it returns the string: "hash not programmed". This file is only visible if the @@ -31,7 +31,7 @@ Description: Read only. Returns the root entry hash for the BMC image What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/sr_canceled_csks Date: Sep 2022 KernelVersion: 5.20 -Contact: Peter Colberg <peter.colberg@intel.com> +Contact: Peter Colberg <peter.colberg@altera.com> Description: Read only. Returns a list of indices for canceled code signing keys for the static region. The standard bitmap list format is used (e.g. "1,2-6,9"). @@ -39,7 +39,7 @@ Description: Read only. Returns a list of indices for canceled code What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/pr_canceled_csks Date: Sep 2022 KernelVersion: 5.20 -Contact: Peter Colberg <peter.colberg@intel.com> +Contact: Peter Colberg <peter.colberg@altera.com> Description: Read only. Returns a list of indices for canceled code signing keys for the partial reconfiguration region. The standard bitmap list format is used (e.g. "1,2-6,9"). @@ -47,7 +47,7 @@ Description: Read only. Returns a list of indices for canceled code What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/bmc_canceled_csks Date: Sep 2022 KernelVersion: 5.20 -Contact: Peter Colberg <peter.colberg@intel.com> +Contact: Peter Colberg <peter.colberg@altera.com> Description: Read only. Returns a list of indices for canceled code signing keys for the BMC. The standard bitmap list format is used (e.g. "1,2-6,9"). @@ -55,7 +55,7 @@ Description: Read only. Returns a list of indices for canceled code What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/flash_count Date: Sep 2022 KernelVersion: 5.20 -Contact: Peter Colberg <peter.colberg@intel.com> +Contact: Peter Colberg <peter.colberg@altera.com> Description: Read only. Returns number of times the secure update staging area has been flashed. Format: "%u". diff --git a/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon index d792a56f59ac..9bce281314df 100644 --- a/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon +++ b/Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon @@ -108,3 +108,19 @@ Contact: intel-xe@lists.freedesktop.org Description: RO. Package current voltage in millivolt. Only supported for particular Intel Xe graphics platforms. + +What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/temp2_input +Date: March 2025 +KernelVersion: 6.14 +Contact: intel-xe@lists.freedesktop.org +Description: RO. Package temperature in millidegree Celsius. + + Only supported for particular Intel Xe graphics platforms. + +What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/temp3_input +Date: March 2025 +KernelVersion: 6.14 +Contact: intel-xe@lists.freedesktop.org +Description: RO. VRAM temperature in millidegree Celsius. + + Only supported for particular Intel Xe graphics platforms. diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-cma b/Documentation/ABI/testing/sysfs-kernel-mm-cma index dfd755201142..aaf2a5d8b13b 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-cma +++ b/Documentation/ABI/testing/sysfs-kernel-mm-cma @@ -29,3 +29,16 @@ Date: Feb 2024 Contact: Anshuman Khandual <anshuman.khandual@arm.com> Description: the number of pages CMA API succeeded to release + +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. diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon index b057eddefbfc..293197f180ad 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-damon +++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon @@ -91,6 +91,36 @@ Description: Writing a value to this file sets the update interval of the DAMON context in microseconds as the value. Reading this file returns the value. +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>/monitoring_attrs/nr_regions/min WDate: Mar 2022 @@ -345,6 +375,20 @@ Description: If 'addr' is written to the 'type' file, writing to or reading from this file sets or gets the end address of the address range for the filter. +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>/filters/<F>/target_idx Date: Dec 2022 Contact: SeongJae Park <sj@kernel.org> @@ -365,6 +409,22 @@ Description: Writing 'Y' or 'N' to this file sets whether to allow or reject applying the scheme's action to the memory that satisfies the 'type' and the 'matching' of the directory. +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/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/nr_tried Date: Mar 2022 Contact: SeongJae Park <sj@kernel.org> diff --git a/Documentation/ABI/testing/sysfs-kernel-reboot b/Documentation/ABI/testing/sysfs-kernel-reboot index 837330fb2511..e117aba46be0 100644 --- a/Documentation/ABI/testing/sysfs-kernel-reboot +++ b/Documentation/ABI/testing/sysfs-kernel-reboot @@ -30,3 +30,11 @@ KernelVersion: 5.11 Contact: Matteo Croce <mcroce@microsoft.com> Description: Don't wait for any other CPUs on reboot and avoid anything that could hang. + +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 diff --git a/Documentation/ABI/testing/sysfs-pps-gen-tio b/Documentation/ABI/testing/sysfs-pps-gen-tio new file mode 100644 index 000000000000..3c34ff17a335 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-pps-gen-tio @@ -0,0 +1,6 @@ +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. diff --git a/Documentation/PCI/endpoint/pci-endpoint.rst b/Documentation/PCI/endpoint/pci-endpoint.rst index 35f82f2d45f5..599763aa01ca 100644 --- a/Documentation/PCI/endpoint/pci-endpoint.rst +++ b/Documentation/PCI/endpoint/pci-endpoint.rst @@ -57,11 +57,10 @@ by the PCI controller driver. The PCI controller driver can then create a new EPC device by invoking devm_pci_epc_create()/pci_epc_create(). -* devm_pci_epc_destroy()/pci_epc_destroy() +* pci_epc_destroy() - The PCI controller driver can destroy the EPC device created by either - devm_pci_epc_create() or pci_epc_create() using devm_pci_epc_destroy() or - pci_epc_destroy(). + The PCI controller driver can destroy the EPC device created by + pci_epc_create() using pci_epc_destroy(). * pci_epc_linkup() diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst index 1ef5784c1b84..53faeed7c190 100644 --- a/Documentation/RCU/whatisRCU.rst +++ b/Documentation/RCU/whatisRCU.rst @@ -971,6 +971,16 @@ unfortunately any spinlock in a ``SLAB_TYPESAFE_BY_RCU`` object must be initialized after each and every call to kmem_cache_alloc(), which renders reference-free spinlock acquisition completely unsafe. Therefore, when using ``SLAB_TYPESAFE_BY_RCU``, make proper use of a reference counter. +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. (Those willing to initialize their locks in a kmem_cache constructor may also use locking, including cache-friendly sequence locking.) diff --git a/Documentation/admin-guide/LSM/index.rst b/Documentation/admin-guide/LSM/index.rst index ce63be6d64ad..b44ef68f6e4d 100644 --- a/Documentation/admin-guide/LSM/index.rst +++ b/Documentation/admin-guide/LSM/index.rst @@ -48,3 +48,4 @@ subdirectories. Yama SafeSetID ipe + landlock diff --git a/Documentation/admin-guide/LSM/landlock.rst b/Documentation/admin-guide/LSM/landlock.rst new file mode 100644 index 000000000000..9e61607def08 --- /dev/null +++ b/Documentation/admin-guide/LSM/landlock.rst @@ -0,0 +1,158 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. Copyright © 2025 Microsoft Corporation + +================================ +Landlock: system-wide management +================================ + +:Author: Mickaël Salaün +:Date: March 2025 + +Landlock can leverage the audit framework to log events. + +User space documentation can be found here: +Documentation/userspace-api/landlock.rst. + +Audit +===== + +Denied access requests are logged by default for a sandboxed program if `audit` +is enabled. This default behavior can be changed with the +sys_landlock_restrict_self() flags (cf. +Documentation/userspace-api/landlock.rst). Landlock logs can also be masked +thanks to audit rules. Landlock can generate 2 audit record types. + +Record types +------------ + +AUDIT_LANDLOCK_ACCESS + This record type identifies a denied access request to a kernel resource. + The ``domain`` field indicates the ID of the domain that blocked the + request. The ``blockers`` field indicates the cause(s) of this denial + (separated by a comma), and the following fields identify the kernel object + (similar to SELinux). There may be more than one of this record type per + audit event. + + Example with a file link request generating two records in the same event:: + + domain=195ba459b blockers=fs.refer path="/usr/bin" dev="vda2" ino=351 + domain=195ba459b blockers=fs.make_reg,fs.refer path="/usr/local" dev="vda2" ino=365 + +AUDIT_LANDLOCK_DOMAIN + This record type describes the status of a Landlock domain. The ``status`` + field can be either ``allocated`` or ``deallocated``. + + The ``allocated`` status is part of the same audit event and follows + the first logged ``AUDIT_LANDLOCK_ACCESS`` record of a domain. It identifies + Landlock domain information at the time of the sys_landlock_restrict_self() + call with the following fields: + + - the ``domain`` ID + - the enforcement ``mode`` + - the domain creator's ``pid`` + - the domain creator's ``uid`` + - the domain creator's executable path (``exe``) + - the domain creator's command line (``comm``) + + Example:: + + domain=195ba459b status=allocated mode=enforcing pid=300 uid=0 exe="/root/sandboxer" comm="sandboxer" + + The ``deallocated`` status is an event on its own and it identifies a + Landlock domain release. After such event, it is guarantee that the + related domain ID will never be reused during the lifetime of the system. + The ``domain`` field indicates the ID of the domain which is released, and + the ``denials`` field indicates the total number of denied access request, + which might not have been logged according to the audit rules and + sys_landlock_restrict_self()'s flags. + + Example:: + + domain=195ba459b status=deallocated denials=3 + + +Event samples +-------------- + +Here are two examples of log events (see serial numbers). + +In this example a sandboxed program (``kill``) tries to send a signal to the +init process, which is denied because of the signal scoping restriction +(``LL_SCOPED=s``):: + + $ LL_FS_RO=/ LL_FS_RW=/ LL_SCOPED=s LL_FORCE_LOG=1 ./sandboxer kill 1 + +This command generates two events, each identified with a unique serial +number following a timestamp (``msg=audit(1729738800.268:30)``). The first +event (serial ``30``) contains 4 records. The first record +(``type=LANDLOCK_ACCESS``) shows an access denied by the domain `1a6fdc66f`. +The cause of this denial is signal scopping restriction +(``blockers=scope.signal``). The process that would have receive this signal +is the init process (``opid=1 ocomm="systemd"``). + +The second record (``type=LANDLOCK_DOMAIN``) describes (``status=allocated``) +domain `1a6fdc66f`. This domain was created by process ``286`` executing the +``/root/sandboxer`` program launched by the root user. + +The third record (``type=SYSCALL``) describes the syscall, its provided +arguments, its result (``success=no exit=-1``), and the process that called it. + +The fourth record (``type=PROCTITLE``) shows the command's name as an +hexadecimal value. This can be translated with ``python -c +'print(bytes.fromhex("6B696C6C0031"))'``. + +Finally, the last record (``type=LANDLOCK_DOMAIN``) is also the only one from +the second event (serial ``31``). It is not tied to a direct user space action +but an asynchronous one to free resources tied to a Landlock domain +(``status=deallocated``). This can be useful to know that the following logs +will not concern the domain ``1a6fdc66f`` anymore. This record also summarize +the number of requests this domain denied (``denials=1``), whether they were +logged or not. + +.. code-block:: + + type=LANDLOCK_ACCESS msg=audit(1729738800.268:30): domain=1a6fdc66f blockers=scope.signal opid=1 ocomm="systemd" + type=LANDLOCK_DOMAIN msg=audit(1729738800.268:30): domain=1a6fdc66f status=allocated mode=enforcing pid=286 uid=0 exe="/root/sandboxer" comm="sandboxer" + type=SYSCALL msg=audit(1729738800.268:30): arch=c000003e syscall=62 success=no exit=-1 [..] ppid=272 pid=286 auid=0 uid=0 gid=0 [...] comm="kill" [...] + type=PROCTITLE msg=audit(1729738800.268:30): proctitle=6B696C6C0031 + type=LANDLOCK_DOMAIN msg=audit(1729738800.324:31): domain=1a6fdc66f status=deallocated denials=1 + +Here is another example showcasing filesystem access control:: + + $ LL_FS_RO=/ LL_FS_RW=/tmp LL_FORCE_LOG=1 ./sandboxer sh -c "echo > /etc/passwd" + +The related audit logs contains 8 records from 3 different events (serials 33, +34 and 35) created by the same domain `1a6fdc679`:: + + type=LANDLOCK_ACCESS msg=audit(1729738800.221:33): domain=1a6fdc679 blockers=fs.write_file path="/dev/tty" dev="devtmpfs" ino=9 + type=LANDLOCK_DOMAIN msg=audit(1729738800.221:33): domain=1a6fdc679 status=allocated mode=enforcing pid=289 uid=0 exe="/root/sandboxer" comm="sandboxer" + type=SYSCALL msg=audit(1729738800.221:33): arch=c000003e syscall=257 success=no exit=-13 [...] ppid=272 pid=289 auid=0 uid=0 gid=0 [...] comm="sh" [...] + type=PROCTITLE msg=audit(1729738800.221:33): proctitle=7368002D63006563686F203E202F6574632F706173737764 + type=LANDLOCK_ACCESS msg=audit(1729738800.221:34): domain=1a6fdc679 blockers=fs.write_file path="/etc/passwd" dev="vda2" ino=143821 + type=SYSCALL msg=audit(1729738800.221:34): arch=c000003e syscall=257 success=no exit=-13 [...] ppid=272 pid=289 auid=0 uid=0 gid=0 [...] comm="sh" [...] + type=PROCTITLE msg=audit(1729738800.221:34): proctitle=7368002D63006563686F203E202F6574632F706173737764 + type=LANDLOCK_DOMAIN msg=audit(1729738800.261:35): domain=1a6fdc679 status=deallocated denials=2 + + +Event filtering +--------------- + +If you get spammed with audit logs related to Landlock, this is either an +attack attempt or a bug in the security policy. We can put in place some +filters to limit noise with two complementary ways: + +- with sys_landlock_restrict_self()'s flags if we can fix the sandboxed + programs, +- or with audit rules (see :manpage:`auditctl(8)`). + +Additional documentation +======================== + +* `Linux Audit Documentation`_ +* Documentation/userspace-api/landlock.rst +* Documentation/security/landlock.rst +* https://landlock.io + +.. Links +.. _Linux Audit Documentation: + https://github.com/linux-audit/audit-documentation/wiki diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst index 1576fb93f06c..9bdb30901a93 100644 --- a/Documentation/admin-guide/blockdev/zram.rst +++ b/Documentation/admin-guide/blockdev/zram.rst @@ -54,7 +54,7 @@ The list of possible return codes: If you use 'echo', the returned value is set by the 'echo' utility, and, in general case, something like:: - echo 3 > /sys/block/zram0/max_comp_streams + echo foo > /sys/block/zram0/comp_algorithm if [ $? -ne 0 ]; then handle_error fi @@ -73,21 +73,7 @@ This creates 4 devices: /dev/zram{0,1,2,3} num_devices parameter is optional and tells zram how many devices should be pre-created. Default: 1. -2) Set max number of compression streams -======================================== - -Regardless of the value passed to this attribute, ZRAM will always -allocate multiple compression streams - one per online CPU - thus -allowing several concurrent compression operations. The number of -allocated compression streams goes down when some of the CPUs -become offline. There is no single-compression-stream mode anymore, -unless you are running a UP system or have only 1 CPU online. - -To find out how many streams are currently available:: - - cat /sys/block/zram0/max_comp_streams - -3) Select compression algorithm +2) Select compression algorithm =============================== Using comp_algorithm device attribute one can see available and @@ -107,7 +93,7 @@ Examples:: For the time being, the `comp_algorithm` content shows only compression algorithms that are supported by zram. -4) Set compression algorithm parameters: Optional +3) Set compression algorithm parameters: Optional ================================================= Compression algorithms may support specific parameters which can be @@ -138,7 +124,7 @@ better the compression ratio, it even can take negatives values for some algorithms), for other algorithms `level` is acceleration level (the higher the value the lower the compression ratio). -5) Set Disksize +4) Set Disksize =============== Set disk size by writing the value to sysfs node 'disksize'. @@ -158,7 +144,7 @@ There is little point creating a zram of greater than twice the size of memory since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of the size of the disk when not in use so a huge zram is wasteful. -6) Set memory limit: Optional +5) Set memory limit: Optional ============================= Set memory limit by writing the value to sysfs node 'mem_limit'. @@ -177,7 +163,7 @@ Examples:: # To disable memory limit echo 0 > /sys/block/zram0/mem_limit -7) Activate +6) Activate =========== :: @@ -188,7 +174,7 @@ Examples:: mkfs.ext4 /dev/zram1 mount /dev/zram1 /tmp -8) Add/remove zram devices +7) Add/remove zram devices ========================== zram provides a control interface, which enables dynamic (on-demand) device @@ -208,7 +194,7 @@ execute:: echo X > /sys/class/zram-control/hot_remove -9) Stats +8) Stats ======== Per-device statistics are exported as various nodes under /sys/block/zram<id>/ @@ -228,8 +214,6 @@ mem_limit WO specifies the maximum amount of memory ZRAM can writeback_limit WO specifies the maximum amount of write IO zram can write out to backing device as 4KB unit writeback_limit_enable RW show and set writeback_limit feature -max_comp_streams RW the number of possible concurrent compress - operations comp_algorithm RW show and change the compression algorithm algorithm_params WO setup compression algorithm parameters compact WO trigger memory compaction @@ -310,7 +294,7 @@ a single line of text and contains the following stats separated by whitespace: Unit: 4K bytes ============== ============================================================= -10) Deactivate +9) Deactivate ============== :: @@ -318,7 +302,7 @@ a single line of text and contains the following stats separated by whitespace: swapoff /dev/zram0 umount /dev/zram1 -11) Reset +10) Reset ========= Write any positive value to 'reset' sysfs node:: diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index 02b8206a3594..d6b1db8cc7eb 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst @@ -610,6 +610,10 @@ memory.stat file includes following statistics: 'rss + mapped_file" will give you resident set size of cgroup. + 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. + (Note: file and shmem may be shared among other cgroups. In that case, mapped_file is accounted only when the memory cgroup is owner of page cache.) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index f293a13b42ed..1a16ce68a4d7 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1445,7 +1445,10 @@ The following nested keys are defined. anon Amount of memory used in anonymous mappings such as - brk(), sbrk(), and mmap(MAP_ANONYMOUS) + 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. file Amount of memory used to cache filesystem data, @@ -1488,7 +1491,10 @@ The following nested keys are defined. Amount of application memory swapped out to zswap. file_mapped - Amount of cached filesystem data mapped with mmap() + 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. file_dirty Amount of cached filesystem data that was modified but @@ -1560,6 +1566,12 @@ The following nested keys are defined. workingset_nodereclaim Number of times a shadow node has been reclaimed + pswpin (npn) + Number of pages swapped into memory + + pswpout (npn) + Number of pages swapped out of memory + pgscan (npn) Amount of scanned pages (in an inactive LRU list) @@ -1575,6 +1587,9 @@ The following nested keys are defined. pgscan_khugepaged (npn) Amount of scanned pages by khugepaged (in an inactive LRU list) + pgscan_proactive (npn) + Amount of scanned pages proactively (in an inactive LRU list) + pgsteal_kswapd (npn) Amount of reclaimed pages by kswapd @@ -1584,6 +1599,9 @@ The following nested keys are defined. pgsteal_khugepaged (npn) Amount of reclaimed pages by khugepaged + pgsteal_proactive (npn) + Amount of reclaimed pages proactively + pgfault (npn) Total number of page faults incurred @@ -1661,6 +1679,9 @@ The following nested keys are defined. pgdemote_khugepaged Number of pages demoted by khugepaged. + pgdemote_proactive + Number of pages demoted by proactively. + hugetlb Amount of memory used by hugetlb pages. This metric only shows up if hugetlb usage is accounted for in memory.current (i.e. diff --git a/Documentation/admin-guide/device-mapper/dm-crypt.rst b/Documentation/admin-guide/device-mapper/dm-crypt.rst index 9f8139ff97d6..4467f6d4b632 100644 --- a/Documentation/admin-guide/device-mapper/dm-crypt.rst +++ b/Documentation/admin-guide/device-mapper/dm-crypt.rst @@ -146,6 +146,11 @@ integrity:<bytes>:<type> integrity for the encrypted device. The additional space is then used for storing authentication tag (and persistent IV if needed). +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. + sector_size:<bytes> Use <bytes> as the encryption unit instead of 512 bytes sectors. This option can be in range 512 - 4096 bytes and must be power of two. diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst b/Documentation/admin-guide/device-mapper/dm-integrity.rst index d8a5f14d0e3c..c2e18ecc065c 100644 --- a/Documentation/admin-guide/device-mapper/dm-integrity.rst +++ b/Documentation/admin-guide/device-mapper/dm-integrity.rst @@ -92,6 +92,11 @@ Target arguments: allowed. This mode is useful for data recovery if the device cannot be activated in any of the other standard modes. + 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. 5. the number of additional arguments diff --git a/Documentation/admin-guide/device-mapper/verity.rst b/Documentation/admin-guide/device-mapper/verity.rst index a65c1602cb23..8c3f1f967a3c 100644 --- a/Documentation/admin-guide/device-mapper/verity.rst +++ b/Documentation/admin-guide/device-mapper/verity.rst @@ -87,6 +87,15 @@ panic_on_corruption Panic the device when a corrupted block is discovered. This option is not compatible with ignore_corruption and restart_on_corruption. +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. + ignore_zero_blocks Do not verify blocks that are expected to contain zeroes and always return zeroes instead. This may be useful if the partition contains unused blocks @@ -142,8 +151,15 @@ root_hash_sig_key_desc <key_description> already in the secondary trusted keyring. try_verify_in_tasklet - If verity hashes are in cache, verify data blocks in kernel tasklet instead - of workqueue. This option can reduce IO latency. + 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 Theory of operation =================== diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index ff0b440ef2dc..451874b8135d 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst @@ -22,3 +22,4 @@ are configurable at compile, boot or run time. srso gather_data_sampling reg-file-data-sampling + rsb diff --git a/Documentation/admin-guide/hw-vuln/rsb.rst b/Documentation/admin-guide/hw-vuln/rsb.rst new file mode 100644 index 000000000000..21dbf9cf25f8 --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/rsb.rst @@ -0,0 +1,268 @@ +.. 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>`_ diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 5e351ac52cca..d9fd26b95b34 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1407,7 +1407,8 @@ earlyprintk=serial[,0x...[,baudrate]] earlyprintk=ttySn[,baudrate] earlyprintk=dbgp[debugController#] - earlyprintk=pciserial[,force],bus:device.function[,baudrate] + earlyprintk=mmio32,membase[,{nocfg|baudrate}] + earlyprintk=pciserial[,force],bus:device.function[,{nocfg|baudrate}] earlyprintk=xdbc[xhciController#] earlyprintk=bios @@ -1415,6 +1416,9 @@ the normal console is initialized. It is not enabled by default because it has some cosmetic problems. + Use "nocfg" to skip UART configuration, assume + BIOS/firmware has configured UART correctly. + Append ",keep" to not disable it when the real console takes over. @@ -1859,7 +1863,7 @@ hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET registers. Default set by CONFIG_HPET_MMAP_DEFAULT. - hugepages= [HW] Number of HugeTLB pages to allocate at boot. + hugepages= [HW,EARLY] Number of HugeTLB pages to allocate at boot. If this follows hugepagesz (below), it specifies the number of pages of hugepagesz to be allocated. If this is the first HugeTLB parameter on the command @@ -1871,15 +1875,24 @@ <node>:<integer>[,<node>:<integer>] hugepagesz= - [HW] 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 + [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 Documentation/admin-guide/mm/hugetlbpage.rst. Format: size[KMG] + 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= [HW,CMA,EARLY] The size of a CMA area used for allocation of gigantic hugepages. Or using node format, the size of a CMA area per node can be specified. @@ -1890,6 +1903,13 @@ hugepages using the CMA allocator. If enabled, the boot-time allocation of gigantic hugepages is skipped. + 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. + hugetlb_free_vmemmap= [KNL] Requires CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP enabled. @@ -1931,6 +1951,12 @@ which allow the hypervisor to 'idle' the guest on lock contention. + hw_protection= [HW] + Format: reboot | shutdown + + Hardware protection action taken on critical events like + overtemperature or imminent voltage loss. + i2c_bus= [HW] Override the default board specific I2C bus speed or register an additional I2C bus that is not registered from board initialization code. @@ -4236,10 +4262,10 @@ nosmp [SMP,EARLY] Tells an SMP kernel to act as a UP kernel, and disable the IO APIC. legacy for "maxcpus=0". - nosmt [KNL,MIPS,PPC,S390,EARLY] Disable symmetric multithreading (SMT). + nosmt [KNL,MIPS,PPC,EARLY] Disable symmetric multithreading (SMT). Equivalent to smt=1. - [KNL,X86,PPC] Disable symmetric multithreading (SMT). + [KNL,X86,PPC,S390] Disable symmetric multithreading (SMT). nosmt=force: Force disable SMT, cannot be undone via the sysfs control file. @@ -7259,6 +7285,8 @@ This is just one of many ways that can clear memory. Make sure your system keeps the content of memory across reboots before relying on this option. + NB: Both the mapped address and size must be page aligned for the architecture. + See also Documentation/trace/debugging.rst @@ -7504,6 +7532,22 @@ Note that genuine overcurrent events won't be reported either. + 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. + unknown_nmi_panic [X86] Cause panic on unknown NMI. diff --git a/Documentation/admin-guide/mm/cma_debugfs.rst b/Documentation/admin-guide/mm/cma_debugfs.rst index 7367e6294ef6..4120e9cb0cd5 100644 --- a/Documentation/admin-guide/mm/cma_debugfs.rst +++ b/Documentation/admin-guide/mm/cma_debugfs.rst @@ -12,10 +12,16 @@ its CMA name like below: The structure of the files created under that directory is as follows: - - [RO] base_pfn: The base PFN (Page Frame Number) of the zone. + - [RO] base_pfn: The base PFN (Page Frame Number) of the CMA area. + This is the same as ranges/0/base_pfn. - [RO] count: Amount of memory in the CMA area. - [RO] order_per_bit: Order of pages represented by one bit. - - [RO] bitmap: The bitmap of page states in the zone. + - [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. - [WO] alloc: Allocate N pages from that CMA area. For example:: echo 5 > <debugfs>/cma/<cma_name>/alloc diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index 47a44bd348ab..ced2013db3df 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -64,6 +64,7 @@ comma (","). │ │ │ │ :ref:`0 <sysfs_context>`/avail_operations,operations │ │ │ │ │ :ref:`monitoring_attrs <sysfs_monitoring_attrs>`/ │ │ │ │ │ │ intervals/sample_us,aggr_us,update_us + │ │ │ │ │ │ │ intervals_goal/access_bp,aggrs,min_sample_us,max_sample_us │ │ │ │ │ │ nr_regions/min,max │ │ │ │ │ :ref:`targets <sysfs_targets>`/nr_targets │ │ │ │ │ │ :ref:`0 <sysfs_target>`/pid_target @@ -82,8 +83,8 @@ comma (","). │ │ │ │ │ │ │ │ :ref:`goals <sysfs_schemes_quota_goals>`/nr_goals │ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value │ │ │ │ │ │ │ :ref:`watermarks <sysfs_watermarks>`/metric,interval_us,high,mid,low - │ │ │ │ │ │ │ :ref:`filters <sysfs_filters>`/nr_filters - │ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,target_idx + │ │ │ │ │ │ │ :ref:`{core_,ops_,}filters <sysfs_filters>`/nr_filters + │ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,target_idx,min,max │ │ │ │ │ │ │ :ref:`stats <sysfs_schemes_stats>`/nr_tried,sz_tried,nr_applied,sz_applied,sz_ops_filter_passed,qt_exceeds │ │ │ │ │ │ │ :ref:`tried_regions <sysfs_schemes_tried_regions>`/total_bytes │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age,sz_filter_passed @@ -132,6 +133,11 @@ Users can write below commands for the kdamond to the ``state`` file. - ``off``: Stop running. - ``commit``: Read the user inputs in the sysfs files except ``state`` file again. +- ``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. - ``commit_schemes_quota_goals``: Read the DAMON-based operation schemes' :ref:`quota goals <sysfs_schemes_quota_goals>`. - ``update_schemes_stats``: Update the contents of stats files for each @@ -213,6 +219,25 @@ writing to and rading from the files. For more details about the intervals and monitoring regions range, please refer to the Design document (:doc:`/mm/damon/design`). +.. _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. + .. _sysfs_targets: contexts/<N>/targets/ @@ -282,9 +307,10 @@ to ``N-1``. Each directory represents each DAMON-based operation scheme. schemes/<N>/ ------------ -In each scheme directory, five directories (``access_pattern``, ``quotas``, -``watermarks``, ``filters``, ``stats``, and ``tried_regions``) and three files -(``action``, ``target_nid`` and ``apply_interval``) exist. +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. The ``action`` file is for setting and getting the scheme's :ref:`action <damon_design_damos_action>`. The keywords that can be written to and read @@ -395,33 +421,43 @@ The ``interval`` should written in microseconds unit. .. _sysfs_filters: -schemes/<N>/filters/ --------------------- +schemes/<N>/{core\_,ops\_,}filters/ +----------------------------------- -The directory for the :ref:`filters <damon_design_damos_filters>` of the given +Directories for :ref:`filters <damon_design_damos_filters>` of the given DAMON-based operation scheme. -In the beginning, this directory has only one file, ``nr_filters``. Writing a +``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 number (``N``) to the file creates the number of child directories named ``0`` to ``N-1``. Each directory represents each filter. The filters are evaluated in the numeric order. -Each filter directory contains seven files, namely ``type``, ``matching``, -``allow``, ``memcg_path``, ``addr_start``, ``addr_end``, and ``target_idx``. -To ``type`` file, you can write one of five special keywords: ``anon`` for -anonymous pages, ``memcg`` for specific memory cgroup, ``young`` for young -pages, ``addr`` for specific address range (an open-ended interval), or -``target`` for specific DAMON monitoring target filtering. Meaning of the -types are same to the description on the :ref:`design doc -<damon_design_damos_filters>`. - -In case of the memory cgroup filtering, 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. In case of the address range filtering, you can -specify the start and end address of the range to ``addr_start`` and -``addr_end`` files, respectively. For the DAMON monitoring target filtering, -you can specify the index of the target between the list of the DAMON context's -monitoring targets list to ``target_idx`` file. +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. You can write ``Y`` or ``N`` to ``matching`` file to specify whether the filter is for memory that matches the ``type``. You can write ``Y`` or ``N`` to @@ -431,6 +467,7 @@ the ``type`` and ``matching`` should be allowed or not. For example, below restricts a DAMOS action to be applied to only non-anonymous pages of all memory cgroups except ``/having_care_already``.:: + # cd ops_filters/0/ # echo 2 > nr_filters # # disallow anonymous pages echo anon > 0/type diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst index f34a0d798d5b..67a941903fd2 100644 --- a/Documentation/admin-guide/mm/hugetlbpage.rst +++ b/Documentation/admin-guide/mm/hugetlbpage.rst @@ -145,7 +145,17 @@ hugepages It will allocate 1 2M hugepage on node0 and 2 2M hugepages on node1. If the node number is invalid, the parameter will be ignored. +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. default_hugepagesz Specify the default huge page size. This parameter can only be specified once on the command line. default_hugepagesz can diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst index caba0f52dd36..afce291649dd 100644 --- a/Documentation/admin-guide/mm/pagemap.rst +++ b/Documentation/admin-guide/mm/pagemap.rst @@ -21,7 +21,8 @@ There are four components to pagemap: * Bit 56 page exclusively mapped (since 4.2) * Bit 57 pte is uffd-wp write-protected (since 5.13) (see Documentation/admin-guide/mm/userfaultfd.rst) - * Bits 58-60 zero + * Bit 58 pte is a guard region (since 6.15) (see madvise (2) man page) + * Bits 59-60 zero * Bit 61 page is file-page or shared-anon (since 3.5) * Bit 62 page swapped * Bit 63 page present @@ -37,12 +38,28 @@ There are four components to pagemap: precisely which pages are mapped (or in swap) and comparing mapped pages between processes. + 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. + Efficient users of this interface will use ``/proc/pid/maps`` to determine which areas of memory are actually mapped and llseek to skip over unmapped regions. * ``/proc/kpagecount``. This file contains a 64-bit count of the number of - times each page is mapped, indexed by PFN. + 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. The page-types tool in the tools/mm directory can be used to query the number of times a page is mapped. diff --git a/Documentation/admin-guide/mm/zswap.rst b/Documentation/admin-guide/mm/zswap.rst index 3598dcd7dbe7..fd3370aa43fe 100644 --- a/Documentation/admin-guide/mm/zswap.rst +++ b/Documentation/admin-guide/mm/zswap.rst @@ -60,15 +60,13 @@ accessed. The compressed memory pool grows on demand and shrinks as compressed pages are freed. The pool is not preallocated. By default, a zpool of type selected in ``CONFIG_ZSWAP_ZPOOL_DEFAULT`` Kconfig option is created, but it can be overridden at boot time by setting the ``zpool`` attribute, -e.g. ``zswap.zpool=zbud``. It can also be changed at runtime using the sysfs +e.g. ``zswap.zpool=zsmalloc``. It can also be changed at runtime using the sysfs ``zpool`` attribute, e.g.:: - echo zbud > /sys/module/zswap/parameters/zpool + echo zsmalloc > /sys/module/zswap/parameters/zpool -The zbud type zpool allocates exactly 1 page to store 2 compressed pages, which -means the compression ratio will always be 2:1 or worse (because of half-full -zbud pages). The zsmalloc type zpool has a more complex compressed page -storage method, and it can achieve greater storage densities. +The zsmalloc type zpool has a complex compressed page storage method, and it +can achieve great storage densities. When a swap page is passed from swapout to zswap, zswap maintains a mapping of the swap entry, a combination of the swap type and swap offset, to the zpool diff --git a/Documentation/admin-guide/sysctl/fs.rst b/Documentation/admin-guide/sysctl/fs.rst index 08e89e031714..6c54718c9d04 100644 --- a/Documentation/admin-guide/sysctl/fs.rst +++ b/Documentation/admin-guide/sysctl/fs.rst @@ -347,3 +347,28 @@ filesystems: ``/proc/sys/fs/fuse/max_pages_limit`` is a read/write file for setting/getting the maximum number of pages that can be used for servicing requests in FUSE. + +``/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. diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index f48eaa98d22d..8290177b4f75 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -28,6 +28,7 @@ Currently, these files are in /proc/sys/vm: - compact_memory - compaction_proactiveness - compact_unevictable_allowed +- defrag_mode - dirty_background_bytes - dirty_background_ratio - dirty_bytes @@ -145,6 +146,14 @@ On CONFIG_PREEMPT_RT the default value is 0 in order to avoid a page fault, due to compaction, which would block the task from becoming active until the fault is resolved. +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. dirty_background_bytes ====================== diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst index 700aa72eecb1..a0cc017e4424 100644 --- a/Documentation/admin-guide/tainted-kernels.rst +++ b/Documentation/admin-guide/tainted-kernels.rst @@ -101,6 +101,7 @@ Bit Log Number Reason that got the kernel tainted 16 _/X 65536 auxiliary taint, defined for and used by distros 17 _/T 131072 kernel was built with the struct randomization plugin 18 _/N 262144 an in-kernel test has been run + 19 _/J 524288 userspace used a mutating debug operation in fwctl === === ====== ======================================================== Note: The character ``_`` is representing a blank in this table to make reading @@ -184,3 +185,7 @@ More detailed explanation for tainting build time. 18) ``N`` if an in-kernel test, such as a KUnit test, has been run. + + 19) ``J`` if userpace opened /dev/fwctl/* and performed a FWTCL_RPC_DEBUG_WRITE + to use the devices debugging features. Device debugging features could + cause the device to malfunction in undefined ways. diff --git a/Documentation/arch/arm64/ptdump.rst b/Documentation/arch/arm64/ptdump.rst index 5dcfc5d7cddf..51eb902ba41a 100644 --- a/Documentation/arch/arm64/ptdump.rst +++ b/Documentation/arch/arm64/ptdump.rst @@ -22,8 +22,6 @@ offlining of memory being accessed by the ptdump code. In order to dump the kernel page tables, enable the following configurations and mount debugfs:: - CONFIG_GENERIC_PTDUMP=y - CONFIG_PTDUMP_CORE=y CONFIG_PTDUMP_DEBUGFS=y mount -t debugfs nodev /sys/kernel/debug diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst index f273ea15a8e8..53607d962653 100644 --- a/Documentation/arch/riscv/hwprobe.rst +++ b/Documentation/arch/riscv/hwprobe.rst @@ -183,6 +183,9 @@ The following keys are defined: defined in the Atomic Compare-and-Swap (CAS) instructions manual starting from commit 5059e0ca641c ("update to ratified"). + * :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_ZICOND`: The Zicond extension is supported as defined in the RISC-V Integer Conditional (Zicond) operations extension manual starting from commit 95cf1f9 ("Add changes requested by Ved @@ -192,6 +195,9 @@ The following keys are defined: supported as defined in the RISC-V ISA manual starting from commit d8ab5c78c207 ("Zihintpause is ratified"). + * :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_ZVE32X`: The Vector sub-extension Zve32x is supported, as defined by version 1.0 of the RISC-V Vector extension manual. @@ -239,9 +245,32 @@ The following keys are defined: ratified in commit 98918c844281 ("Merge pull request #1217 from riscv/zawrs") of riscv-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_SUPM`: The Supm extension is supported as defined in version 1.0 of the RISC-V Pointer Masking extensions. + * :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_CPUPERF_0`: Deprecated. Returns similar values to :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was mistakenly classified as a bitmask rather than a value. @@ -303,3 +332,6 @@ The following keys are defined: * :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XTHEADVECTOR`: The xtheadvector vendor extension is supported in the T-Head ISA extensions spec starting from commit a18c801634 ("Add T-Head VECTOR vendor extension. "). + +* :c:macro:`RISCV_HWPROBE_KEY_ZICBOM_BLOCK_SIZE`: An unsigned int which + represents the size of the Zicbom block in bytes. diff --git a/Documentation/arch/x86/cpuinfo.rst b/Documentation/arch/x86/cpuinfo.rst index 6ef426a52cdc..f80e2a558d2a 100644 --- a/Documentation/arch/x86/cpuinfo.rst +++ b/Documentation/arch/x86/cpuinfo.rst @@ -79,8 +79,9 @@ feature flags. How are feature flags created? ============================== -a: Feature flags can be derived from the contents of CPUID leaves. ------------------------------------------------------------------- +Feature flags can be derived from the contents of CPUID leaves +-------------------------------------------------------------- + These feature definitions are organized mirroring the layout of CPUID leaves and grouped in words with offsets as mapped in enum cpuid_leafs in cpufeatures.h (see arch/x86/include/asm/cpufeatures.h for details). @@ -89,8 +90,9 @@ cpufeatures.h, and if it is detected at run time, the flags will be displayed accordingly in /proc/cpuinfo. For example, the flag "avx2" comes from X86_FEATURE_AVX2 in cpufeatures.h. -b: Flags can be from scattered CPUID-based features. ----------------------------------------------------- +Flags can be from scattered CPUID-based features +------------------------------------------------ + Hardware features enumerated in sparsely populated CPUID leaves get software-defined values. Still, CPUID needs to be queried to determine if a given feature is present. This is done in init_scattered_cpuid_features(). @@ -104,8 +106,9 @@ has only one feature and would waste 31 bits of space in the x86_capability[] array. Since there is a struct cpuinfo_x86 for each possible CPU, the wasted memory is not trivial. -c: Flags can be created synthetically under certain conditions for hardware features. -------------------------------------------------------------------------------------- +Flags can be created synthetically under certain conditions for hardware features +--------------------------------------------------------------------------------- + Examples of conditions include whether certain features are present in MSR_IA32_CORE_CAPS or specific CPU models are identified. If the needed conditions are met, the features are enabled by the set_cpu_cap or @@ -114,8 +117,8 @@ the feature X86_FEATURE_SPLIT_LOCK_DETECT will be enabled and "split_lock_detect" will be displayed. The flag "ring3mwait" will be displayed only when running on INTEL_XEON_PHI_[KNL|KNM] processors. -d: Flags can represent purely software features. ------------------------------------------------- +Flags can represent purely software features +-------------------------------------------- These flags do not represent hardware features. Instead, they represent a software feature implemented in the kernel. For example, Kernel Page Table Isolation is purely software feature and its feature flag X86_FEATURE_PTI is @@ -130,14 +133,18 @@ x86_cap/bug_flags[] arrays in kernel/cpu/capflags.c. The names in the resulting x86_cap/bug_flags[] are used to populate /proc/cpuinfo. The naming of flags in the x86_cap/bug_flags[] are as follows: -a: The name of the flag is from the string in X86_FEATURE_<name> by default. ----------------------------------------------------------------------------- -By default, the flag <name> in /proc/cpuinfo is extracted from the respective -X86_FEATURE_<name> in cpufeatures.h. For example, the flag "avx2" is from -X86_FEATURE_AVX2. +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 +---------------------------------------- -b: The naming can be overridden. --------------------------------- If the comment on the line for the #define X86_FEATURE_* starts with a double-quote character (""), the string inside the double-quote characters will be the name of the flags. For example, the flag "sse4_1" comes from @@ -148,36 +155,31 @@ needed. For instance, /proc/cpuinfo is a userspace interface and must remain constant. If, for some reason, the naming of X86_FEATURE_<name> changes, one shall override the new naming with the name already used in /proc/cpuinfo. -c: The naming override can be "", which means it will not appear in /proc/cpuinfo. ----------------------------------------------------------------------------------- -The feature shall be omitted from /proc/cpuinfo if it does not make sense for -the feature to be exposed to userspace. 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, its name is overridden -with "". Its flag will not appear in /proc/cpuinfo. - Flags are missing when one or more of these happen ================================================== -a: The hardware does not enumerate support for it. --------------------------------------------------- +The hardware does not enumerate support for it +---------------------------------------------- + For example, when a new kernel is running on old hardware or the feature is not enabled by boot firmware. Even if the hardware is new, there might be a problem enabling the feature at run time, the flag will not be displayed. -b: The kernel does not know about the flag. -------------------------------------------- +The kernel does not know about the flag +--------------------------------------- + For example, when an old kernel is running on new hardware. -c: The kernel disabled support for it at compile-time. ------------------------------------------------------- +The kernel disabled support for it at compile-time +-------------------------------------------------- + For example, if 5-level-paging is not enabled when building (i.e., CONFIG_X86_5LEVEL is not selected) the flag "la57" will not show up [#f1]_. Even though the feature will still be detected via CPUID, the kernel disables it by clearing via setup_clear_cpu_cap(X86_FEATURE_LA57). -d: The feature is disabled at boot-time. ----------------------------------------- +The feature is disabled at boot-time +------------------------------------ A feature can be disabled either using a command-line parameter or because it failed to be enabled. The command-line parameter clearcpuid= can be used to disable features using the feature number as defined in @@ -190,8 +192,9 @@ disable specific features. The list of parameters includes, but is not limited to, nofsgsbase, nosgx, noxsave, etc. 5-level paging can also be disabled using "no5lvl". -e: The feature was known to be non-functional. ----------------------------------------------- +The feature was known to be non-functional +------------------------------------------ + The feature was known to be non-functional because a dependency was missing at runtime. For example, AVX flags will not show up if XSAVE feature is disabled since they depend on XSAVE feature. Another example would be broken diff --git a/Documentation/block/ublk.rst b/Documentation/block/ublk.rst index 1e0e7358e14a..854f823b46c2 100644 --- a/Documentation/block/ublk.rst +++ b/Documentation/block/ublk.rst @@ -309,18 +309,35 @@ with specified IO tag in the command data: ``UBLK_IO_COMMIT_AND_FETCH_REQ`` to the server, ublkdrv needs to copy the server buffer (pages) read to the IO request pages. -Future development -================== - Zero copy --------- -Zero copy is a generic requirement for nbd, fuse or similar drivers. A -problem [#xiaoguang]_ Xiaoguang mentioned is that pages mapped to userspace -can't be remapped any more in kernel with existing mm interfaces. This can -occurs when destining direct IO to ``/dev/ublkb*``. Also, he reported that -big requests (IO size >= 256 KB) may benefit a lot from zero copy. - +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. References ========== @@ -332,5 +349,3 @@ References .. [#userspace_nbdublk] https://gitlab.com/rwmjones/libnbd/-/tree/nbdublk .. [#userspace_readme] https://github.com/ming1/ubdsrv/blob/master/README - -.. [#xiaoguang] https://lore.kernel.org/linux-block/YoOr6jBfgVm8GvWg@stefanha-x1.localdomain/ diff --git a/Documentation/bpf/bpf_iterators.rst b/Documentation/bpf/bpf_iterators.rst index 07433915aa41..7f514cb6b052 100644 --- a/Documentation/bpf/bpf_iterators.rst +++ b/Documentation/bpf/bpf_iterators.rst @@ -86,7 +86,7 @@ following steps: The following are a few examples of selftest BPF iterator programs: * `bpf_iter_tcp4.c <https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/progs/bpf_iter_tcp4.c>`_ -* `bpf_iter_task_vma.c <https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/progs/bpf_iter_task_vma.c>`_ +* `bpf_iter_task_vmas.c <https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/progs/bpf_iter_task_vmas.c>`_ * `bpf_iter_task_file.c <https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/progs/bpf_iter_task_file.c>`_ Let us look at ``bpf_iter_task_file.c``, which runs in kernel space: diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst index 2478cef758f8..3b60583f5db2 100644 --- a/Documentation/bpf/btf.rst +++ b/Documentation/bpf/btf.rst @@ -102,7 +102,8 @@ Each type contains the following common data:: * bits 24-28: kind (e.g. int, ptr, array...etc) * bits 29-30: unused * bit 31: kind_flag, currently used by - * struct, union, fwd, enum and enum64. + * struct, union, enum, fwd, enum64, + * decl_tag and type_tag */ __u32 info; /* "size" is used by INT, ENUM, STRUCT, UNION and ENUM64. @@ -478,7 +479,7 @@ No additional type data follow ``btf_type``. ``struct btf_type`` encoding requirement: * ``name_off``: offset to a non-empty string - * ``info.kind_flag``: 0 + * ``info.kind_flag``: 0 or 1 * ``info.kind``: BTF_KIND_DECL_TAG * ``info.vlen``: 0 * ``type``: ``struct``, ``union``, ``func``, ``var`` or ``typedef`` @@ -489,7 +490,6 @@ No additional type data follow ``btf_type``. __u32 component_idx; }; -The ``name_off`` encodes btf_decl_tag attribute string. The ``type`` should be ``struct``, ``union``, ``func``, ``var`` or ``typedef``. For ``var`` or ``typedef`` type, ``btf_decl_tag.component_idx`` must be ``-1``. For the other three types, if the btf_decl_tag attribute is @@ -499,12 +499,21 @@ the attribute is applied to a ``struct``/``union`` member or a ``func`` argument, and ``btf_decl_tag.component_idx`` should be a valid index (starting from 0) pointing to a member or an argument. +If ``info.kind_flag`` is 0, then this is a normal decl tag, and the +``name_off`` encodes btf_decl_tag attribute string. + +If ``info.kind_flag`` is 1, then the decl tag represents an arbitrary +__attribute__. In this case, ``name_off`` encodes a string +representing the attribute-list of the attribute specifier. For +example, for an ``__attribute__((aligned(4)))`` the string's contents +is ``aligned(4)``. + 2.2.18 BTF_KIND_TYPE_TAG ~~~~~~~~~~~~~~~~~~~~~~~~ ``struct btf_type`` encoding requirement: * ``name_off``: offset to a non-empty string - * ``info.kind_flag``: 0 + * ``info.kind_flag``: 0 or 1 * ``info.kind``: BTF_KIND_TYPE_TAG * ``info.vlen``: 0 * ``type``: the type with ``btf_type_tag`` attribute @@ -522,6 +531,14 @@ type_tag, then zero or more const/volatile/restrict/typedef and finally the base type. The base type is one of int, ptr, array, struct, union, enum, func_proto and float types. +Similarly to decl tags, if the ``info.kind_flag`` is 0, then this is a +normal type tag, and the ``name_off`` encodes btf_type_tag attribute +string. + +If ``info.kind_flag`` is 1, then the type tag represents an arbitrary +__attribute__, and the ``name_off`` encodes a string representing the +attribute-list of the attribute specifier. + 2.2.19 BTF_KIND_ENUM64 ~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst index ab820d565052..fbe975585236 100644 --- a/Documentation/bpf/standardization/instruction-set.rst +++ b/Documentation/bpf/standardization/instruction-set.rst @@ -324,34 +324,42 @@ register. .. table:: Arithmetic instructions - ===== ===== ======= ========================================================== + ===== ===== ======= =================================================================================== name code offset description - ===== ===== ======= ========================================================== + ===== ===== ======= =================================================================================== ADD 0x0 0 dst += src SUB 0x1 0 dst -= src MUL 0x2 0 dst \*= src DIV 0x3 0 dst = (src != 0) ? (dst / src) : 0 - SDIV 0x3 1 dst = (src != 0) ? (dst s/ src) : 0 + SDIV 0x3 1 dst = (src == 0) ? 0 : ((src == -1 && dst == LLONG_MIN) ? LLONG_MIN : (dst s/ src)) OR 0x4 0 dst \|= src AND 0x5 0 dst &= src LSH 0x6 0 dst <<= (src & mask) RSH 0x7 0 dst >>= (src & mask) NEG 0x8 0 dst = -dst MOD 0x9 0 dst = (src != 0) ? (dst % src) : dst - SMOD 0x9 1 dst = (src != 0) ? (dst s% src) : dst + SMOD 0x9 1 dst = (src == 0) ? dst : ((src == -1 && dst == LLONG_MIN) ? 0: (dst s% src)) XOR 0xa 0 dst ^= src MOV 0xb 0 dst = src MOVSX 0xb 8/16/32 dst = (s8,s16,s32)src ARSH 0xc 0 :term:`sign extending<Sign Extend>` dst >>= (src & mask) END 0xd 0 byte swap operations (see `Byte swap instructions`_ below) - ===== ===== ======= ========================================================== + ===== ===== ======= =================================================================================== Underflow and overflow are allowed during arithmetic operations, meaning the 64-bit or 32-bit value will wrap. If BPF program execution would result in division by zero, the destination register is instead set to zero. +Otherwise, for ``ALU64``, if execution would result in ``LLONG_MIN`` +dividing -1, the desination register is instead set to ``LLONG_MIN``. For +``ALU``, if execution would result in ``INT_MIN`` dividing -1, the +desination register is instead set to ``INT_MIN``. + If execution would result in modulo by zero, for ``ALU64`` the value of the destination register is unchanged whereas for ``ALU`` the upper -32 bits of the destination register are zeroed. +32 bits of the destination register are zeroed. Otherwise, for ``ALU64``, +if execution would resuslt in ``LLONG_MIN`` modulo -1, the destination +register is instead set to 0. For ``ALU``, if execution would result in +``INT_MIN`` modulo -1, the destination register is instead set to 0. ``{ADD, X, ALU}``, where 'code' = ``ADD``, 'source' = ``X``, and 'class' = ``ALU``, means:: diff --git a/Documentation/core-api/refcount-vs-atomic.rst b/Documentation/core-api/refcount-vs-atomic.rst index 79a009ce11df..94e628c1eb49 100644 --- a/Documentation/core-api/refcount-vs-atomic.rst +++ b/Documentation/core-api/refcount-vs-atomic.rst @@ -86,7 +86,19 @@ Memory ordering guarantee changes: * none (both fully unordered) -case 2) - increment-based ops that return no value +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 -------------------------------------------------- Function changes: @@ -98,7 +110,7 @@ Memory ordering guarantee changes: * none (both fully unordered) -case 3) - decrement-based RMW ops that return no value +case 4) - decrement-based RMW ops that return no value ------------------------------------------------------ Function changes: @@ -110,7 +122,7 @@ Memory ordering guarantee changes: * fully unordered --> RELEASE ordering -case 4) - increment-based RMW ops that return a value +case 5) - increment-based RMW ops that return a value ----------------------------------------------------- Function changes: @@ -126,7 +138,20 @@ Memory ordering guarantees changes: result of obtaining pointer to the object! -case 5) - generic dec/sub decrement-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 --------------------------------------------------------------------- Function changes: @@ -139,7 +164,7 @@ Memory ordering guarantees changes: * fully ordered --> RELEASE ordering + ACQUIRE ordering on success -case 6) other decrement-based RMW ops that return a value +case 8) other decrement-based RMW ops that return a value --------------------------------------------------------- Function changes: @@ -154,7 +179,7 @@ Memory ordering guarantees changes: .. note:: atomic_add_unless() only provides full order on success. -case 7) - lock-based RMW +case 9) - lock-based RMW ------------------------ Function changes: diff --git a/Documentation/core-api/xarray.rst b/Documentation/core-api/xarray.rst index f6a3eef4fe7f..c6c91cbd0c3c 100644 --- a/Documentation/core-api/xarray.rst +++ b/Documentation/core-api/xarray.rst @@ -489,7 +489,19 @@ Storing ``NULL`` into any index of a multi-index entry will set the entry at every index to ``NULL`` and dissolve the tie. A multi-index entry can be split into entries occupying smaller ranges by calling xas_split_alloc() without the xa_lock held, followed by taking the lock -and calling xas_split(). +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. Functions and structures ======================== diff --git a/Documentation/crypto/architecture.rst b/Documentation/crypto/architecture.rst index 15dcd62fd22f..249b54d0849f 100644 --- a/Documentation/crypto/architecture.rst +++ b/Documentation/crypto/architecture.rst @@ -196,8 +196,6 @@ the aforementioned cipher types: - CRYPTO_ALG_TYPE_CIPHER Single block cipher -- CRYPTO_ALG_TYPE_COMPRESS Compression - - CRYPTO_ALG_TYPE_AEAD Authenticated Encryption with Associated Data (MAC) diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst index 92eec78b5713..100b47d049c0 100644 --- a/Documentation/crypto/index.rst +++ b/Documentation/crypto/index.rst @@ -26,3 +26,4 @@ for cryptographic use cases, as well as programming examples. api-samples descore-readme device_drivers/index + krb5 diff --git a/Documentation/crypto/krb5.rst b/Documentation/crypto/krb5.rst new file mode 100644 index 000000000000..beffa0133446 --- /dev/null +++ b/Documentation/crypto/krb5.rst @@ -0,0 +1,262 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================== +Kerberos V Cryptography API +=========================== + +.. Contents: + + - Overview. + - Small Buffer. + - Encoding Type. + - Key Derivation. + - PRF+ Calculation. + - Kc, Ke And Ki Derivation. + - Crypto Functions. + - Preparation Functions. + - Encryption Mode. + - Checksum Mode. + - The krb5enc AEAD algorithm + +Overview +======== + +This API provides Kerberos 5-style cryptography for key derivation, encryption +and checksumming for use in network filesystems and can be used to implement +the low-level crypto that's needed for GSSAPI. + +The following crypto types are supported:: + + KRB5_ENCTYPE_AES128_CTS_HMAC_SHA1_96 + KRB5_ENCTYPE_AES256_CTS_HMAC_SHA1_96 + KRB5_ENCTYPE_AES128_CTS_HMAC_SHA256_128 + KRB5_ENCTYPE_AES256_CTS_HMAC_SHA384_192 + KRB5_ENCTYPE_CAMELLIA128_CTS_CMAC + KRB5_ENCTYPE_CAMELLIA256_CTS_CMAC + + KRB5_CKSUMTYPE_HMAC_SHA1_96_AES128 + KRB5_CKSUMTYPE_HMAC_SHA1_96_AES256 + KRB5_CKSUMTYPE_CMAC_CAMELLIA128 + KRB5_CKSUMTYPE_CMAC_CAMELLIA256 + KRB5_CKSUMTYPE_HMAC_SHA256_128_AES128 + KRB5_CKSUMTYPE_HMAC_SHA384_192_AES256 + +The API can be included by:: + + #include <crypto/krb5.h> + +Small Buffer +------------ + +To pass small pieces of data about, such as keys, a buffer structure is +defined, giving a pointer to the data and the size of that data:: + + struct krb5_buffer { + unsigned int len; + void *data; + }; + +Encoding Type +============= + +The encoding type is defined by the following structure:: + + struct krb5_enctype { + int etype; + int ctype; + const char *name; + u16 key_bytes; + u16 key_len; + u16 Kc_len; + u16 Ke_len; + u16 Ki_len; + u16 prf_len; + u16 block_len; + u16 conf_len; + u16 cksum_len; + ... + }; + +The fields of interest to the user of the API are as follows: + + * ``etype`` and ``ctype`` indicate the protocol number for this encoding + type for encryption and checksumming respectively. They hold + ``KRB5_ENCTYPE_*`` and ``KRB5_CKSUMTYPE_*`` constants. + + * ``name`` is the formal name of the encoding. + + * ``key_len`` and ``key_bytes`` are the input key length and the derived key + length. (I think they only differ for DES, which isn't supported here). + + * ``Kc_len``, ``Ke_len`` and ``Ki_len`` are the sizes of the derived Kc, Ke + and Ki keys. Kc is used for in checksum mode; Ke and Ki are used in + encryption mode. + + * ``prf_len`` is the size of the result from the PRF+ function calculation. + + * ``block_len``, ``conf_len`` and ``cksum_len`` are the encryption block + length, confounder length and checksum length respectively. All three are + used in encryption mode, but only the checksum length is used in checksum + mode. + +The encoding type is looked up by number using the following function:: + + const struct krb5_enctype *crypto_krb5_find_enctype(u32 enctype); + +Key Derivation +============== + +Once the application has selected an encryption type, the keys that will be +used to do the actual crypto can be derived from the transport key. + +PRF+ Calculation +---------------- + +To aid in key derivation, a function to calculate the Kerberos GSSAPI +mechanism's PRF+ is provided:: + + int crypto_krb5_calc_PRFplus(const struct krb5_enctype *krb5, + const struct krb5_buffer *K, + unsigned int L, + const struct krb5_buffer *S, + struct krb5_buffer *result, + gfp_t gfp); + +This can be used to derive the transport key from a source key plus additional +data to limit its use. + +Crypto Functions +================ + +Once the keys have been derived, crypto can be performed on the data. The +caller must leave gaps in the buffer for the storage of the confounder (if +needed) and the checksum when preparing a message for transmission. An enum +and a pair of functions are provided to aid in this:: + + enum krb5_crypto_mode { + KRB5_CHECKSUM_MODE, + KRB5_ENCRYPT_MODE, + }; + + size_t crypto_krb5_how_much_buffer(const struct krb5_enctype *krb5, + enum krb5_crypto_mode mode, + size_t data_size, size_t *_offset); + + size_t crypto_krb5_how_much_data(const struct krb5_enctype *krb5, + enum krb5_crypto_mode mode, + size_t *_buffer_size, size_t *_offset); + +All these functions take the encoding type and an indication the mode of crypto +(checksum-only or full encryption). + +The first function returns how big the buffer will need to be to house a given +amount of data; the second function returns how much data will fit in a buffer +of a particular size, and adjusts down the size of the required buffer +accordingly. In both cases, the offset of the data within the buffer is also +returned. + +When a message has been received, the location and size of the data with the +message can be determined by calling:: + + void crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5, + enum krb5_crypto_mode mode, + size_t *_offset, size_t *_len); + +The caller provides the offset and length of the message to the function, which +then alters those values to indicate the region containing the data (plus any +padding). It is up to the caller to determine how much padding there is. + +Preparation Functions +--------------------- + +Two functions are provided to allocated and prepare a crypto object for use by +the action functions:: + + struct crypto_aead * + crypto_krb5_prepare_encryption(const struct krb5_enctype *krb5, + const struct krb5_buffer *TK, + u32 usage, gfp_t gfp); + struct crypto_shash * + crypto_krb5_prepare_checksum(const struct krb5_enctype *krb5, + const struct krb5_buffer *TK, + u32 usage, gfp_t gfp); + +Both of these functions take the encoding type, the transport key and the usage +value used to derive the appropriate subkey(s). They create an appropriate +crypto object, an AEAD template for encryption and a synchronous hash for +checksumming, set the key(s) on it and configure it. The caller is expected to +pass these handles to the action functions below. + +Encryption Mode +--------------- + +A pair of functions are provided to encrypt and decrypt a message:: + + ssize_t crypto_krb5_encrypt(const struct krb5_enctype *krb5, + struct crypto_aead *aead, + struct scatterlist *sg, unsigned int nr_sg, + size_t sg_len, + size_t data_offset, size_t data_len, + bool preconfounded); + int crypto_krb5_decrypt(const struct krb5_enctype *krb5, + struct crypto_aead *aead, + struct scatterlist *sg, unsigned int nr_sg, + size_t *_offset, size_t *_len); + +In both cases, the input and output buffers are indicated by the same +scatterlist. + +For the encryption function, the output buffer may be larger than is needed +(the amount of output generated is returned) and the location and size of the +data are indicated (which must match the encoding). If no confounder is set, +the function will insert one. + +For the decryption function, the offset and length of the message in buffer are +supplied and these are shrunk to fit the data. The decryption function will +verify any checksums within the message and give an error if they don't match. + +Checksum Mode +------------- + +A pair of function are provided to generate the checksum on a message and to +verify that checksum:: + + ssize_t crypto_krb5_get_mic(const struct krb5_enctype *krb5, + struct crypto_shash *shash, + const struct krb5_buffer *metadata, + struct scatterlist *sg, unsigned int nr_sg, + size_t sg_len, + size_t data_offset, size_t data_len); + int crypto_krb5_verify_mic(const struct krb5_enctype *krb5, + struct crypto_shash *shash, + const struct krb5_buffer *metadata, + struct scatterlist *sg, unsigned int nr_sg, + size_t *_offset, size_t *_len); + +In both cases, the input and output buffers are indicated by the same +scatterlist. Additional metadata can be passed in which will get added to the +hash before the data. + +For the get_mic function, the output buffer may be larger than is needed (the +amount of output generated is returned) and the location and size of the data +are indicated (which must match the encoding). + +For the verification function, the offset and length of the message in buffer +are supplied and these are shrunk to fit the data. An error will be returned +if the checksums don't match. + +The krb5enc AEAD algorithm +========================== + +A template AEAD crypto algorithm, called "krb5enc", is provided that hashes the +plaintext before encrypting it (the reverse of authenc). The handle returned +by ``crypto_krb5_prepare_encryption()`` may be one of these, but there's no +requirement for the user of this API to interact with it directly. + +For reference, its key format begins with a BE32 of the format number. Only +format 1 is provided and that continues with a BE32 of the Ke key length +followed by a BE32 of the Ki key length, followed by the bytes from the Ke key +and then the Ki key. + +Using specifically ordered words means that the static test data doesn't +require byteswapping. diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst index abb3ff682076..76bd0ddb0041 100644 --- a/Documentation/dev-tools/checkpatch.rst +++ b/Documentation/dev-tools/checkpatch.rst @@ -342,24 +342,6 @@ API usage See: https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html#full-list-of-rcu-apis - **DEPRECATED_VARIABLE** - EXTRA_{A,C,CPP,LD}FLAGS are deprecated and should be replaced by the new - flags added via commit f77bf01425b1 ("kbuild: introduce ccflags-y, - asflags-y and ldflags-y"). - - The following conversion scheme maybe used:: - - EXTRA_AFLAGS -> asflags-y - EXTRA_CFLAGS -> ccflags-y - EXTRA_CPPFLAGS -> cppflags-y - EXTRA_LDFLAGS -> ldflags-y - - See: - - 1. https://lore.kernel.org/lkml/20070930191054.GA15876@uranus.ravnborg.org/ - 2. https://lore.kernel.org/lkml/1313384834-24433-12-git-send-email-lacombar@gmail.com/ - 3. https://www.kernel.org/doc/html/latest/kbuild/makefiles.html#compilation-flags - **DEVICE_ATTR_FUNCTIONS** The function names used in DEVICE_ATTR is unusual. Typically, the store and show functions are used with <attr>_store and diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml index cb8dceaca70e..4787d7c6bac2 100644 --- a/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml +++ b/Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml @@ -101,6 +101,29 @@ properties: and ETF configurations. $ref: /schemas/graph.yaml#/properties/port + 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 + required: - compatible - reg @@ -115,6 +138,9 @@ examples: etr@20070000 { compatible = "arm,coresight-tmc", "arm,primecell"; reg = <0x20070000 0x1000>; + memory-region = <&etr_trace_mem_reserved>, + <&etr_mdata_mem_reserved>; + memory-region-names = "tracedata", "metadata"; clocks = <&oscclk6a>; clock-names = "apb_pclk"; diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml new file mode 100644 index 000000000000..843b52eaf872 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml @@ -0,0 +1,84 @@ +# 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>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml index 76163abed655..5ed40f21b8eb 100644 --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml @@ -55,8 +55,7 @@ properties: - const: arm,primecell reg: - minItems: 1 - maxItems: 2 + maxItems: 1 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml index 8eec07d9d454..07d21a3617f5 100644 --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tpdm.yaml @@ -41,8 +41,7 @@ properties: - const: arm,primecell reg: - minItems: 1 - maxItems: 2 + maxItems: 1 qcom,dsb-element-bits: description: diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun55i-a523-ccu.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun55i-a523-ccu.yaml new file mode 100644 index 000000000000..f5f62e9a10a1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/allwinner,sun55i-a523-ccu.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/allwinner,sun55i-a523-ccu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A523 Clock Control Unit + +maintainers: + - Andre Przywara <andre.przywara@arm.com> + +properties: + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + + compatible: + enum: + - allwinner,sun55i-a523-ccu + - allwinner,sun55i-a523-r-ccu + + reg: + maxItems: 1 + + clocks: + minItems: 4 + maxItems: 5 + + clock-names: + minItems: 4 + maxItems: 5 + +required: + - "#clock-cells" + - "#reset-cells" + - compatible + - reg + - clocks + - clock-names + +allOf: + - if: + properties: + compatible: + enum: + - allwinner,sun55i-a523-ccu + + then: + properties: + clocks: + items: + - description: High Frequency Oscillator (usually at 24MHz) + - description: Low Frequency Oscillator (usually at 32kHz) + - description: Internal Oscillator + - description: Low Frequency Oscillator fanout + + clock-names: + items: + - const: hosc + - const: losc + - const: iosc + - const: losc-fanout + + - if: + properties: + compatible: + enum: + - allwinner,sun55i-a523-r-ccu + + then: + properties: + clocks: + items: + - description: High Frequency Oscillator (usually at 24MHz) + - description: Low Frequency Oscillator (usually at 32kHz) + - description: Internal Oscillator + - description: Peripherals PLL + - description: Audio PLL + + clock-names: + items: + - const: hosc + - const: losc + - const: iosc + - const: pll-periph + - const: pll-audio + +additionalProperties: false + +examples: + - | + clock-controller@2001000 { + compatible = "allwinner,sun55i-a523-ccu"; + reg = <0x02001000 0x1000>; + clocks = <&osc24M>, <&osc32k>, <&iosc>, <&r_ccu 1>; + clock-names = "hosc", "losc", "iosc", "losc-fanout"; + #clock-cells = <1>; + #reset-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml b/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml index 885d47dd5724..e803a1fc3681 100644 --- a/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml +++ b/Documentation/devicetree/bindings/clock/atmel,at91rm9200-pmc.yaml @@ -34,6 +34,8 @@ properties: - enum: - atmel,at91rm9200-pmc - atmel,at91sam9260-pmc + - atmel,at91sam9261-pmc + - atmel,at91sam9263-pmc - atmel,at91sam9g45-pmc - atmel,at91sam9n12-pmc - atmel,at91sam9rl-pmc @@ -111,6 +113,8 @@ allOf: enum: - atmel,at91rm9200-pmc - atmel,at91sam9260-pmc + - atmel,at91sam9261-pmc + - atmel,at91sam9263-pmc - atmel,at91sam9g20-pmc then: properties: diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml index c643d4a81478..4fec55832702 100644 --- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml @@ -43,6 +43,13 @@ properties: ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8m-clock.h for the full list of i.MX8M clock IDs. + fsl,operating-mode: + $ref: /schemas/types.yaml#/definitions/string + enum: [nominal, overdrive] + description: + The operating mode of the SoC. This affects the maximum clock rates that + can safely be configured by the clock controller. + required: - compatible - reg @@ -109,6 +116,7 @@ examples: <&clk_ext3>, <&clk_ext4>; clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2", "clk_ext3", "clk_ext4"; + fsl,operating-mode = "nominal"; }; - | diff --git a/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml b/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml index 6588a17a7d9a..0272c9527037 100644 --- a/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml +++ b/Documentation/devicetree/bindings/clock/imx8mp-audiomix.yaml @@ -24,8 +24,8 @@ properties: maxItems: 1 clocks: - minItems: 7 - maxItems: 7 + minItems: 8 + maxItems: 8 clock-names: items: @@ -36,6 +36,7 @@ properties: - const: sai5 - const: sai6 - const: sai7 + - const: axi '#clock-cells': const: 1 @@ -72,10 +73,11 @@ examples: <&clk IMX8MP_CLK_SAI3>, <&clk IMX8MP_CLK_SAI5>, <&clk IMX8MP_CLK_SAI6>, - <&clk IMX8MP_CLK_SAI7>; + <&clk IMX8MP_CLK_SAI7>, + <&clk IMX8MP_CLK_AUDIO_AXI_ROOT>; clock-names = "ahb", "sai1", "sai2", "sai3", - "sai5", "sai6", "sai7"; + "sai5", "sai6", "sai7", "axi"; power-domains = <&pgc_audio>; }; diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml index 860570320545..2985c8c717d7 100644 --- a/Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml +++ b/Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml @@ -57,6 +57,27 @@ required: - reg - '#clock-cells' +allOf: + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt8188-camsys-rawa + - mediatek,mt8188-camsys-rawb + - mediatek,mt8188-camsys-yuva + - mediatek,mt8188-camsys-yuvb + - mediatek,mt8188-imgsys-wpe1 + - mediatek,mt8188-imgsys-wpe2 + - mediatek,mt8188-imgsys-wpe3 + - mediatek,mt8188-imgsys1-dip-nr + - mediatek,mt8188-imgsys1-dip-top + - mediatek,mt8188-ipesys + + then: + required: + - '#reset-cells' + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml b/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml index ba7ffc5b16a0..83c1803ffd16 100644 --- a/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml +++ b/Documentation/devicetree/bindings/clock/mediatek,mtmips-sysc.yaml @@ -18,6 +18,12 @@ description: | These SoCs have an XTAL from where the cpu clock is provided as well as derived clocks for the bus and the peripherals. + Each clock is assigned an identifier and client nodes use this identifier + to specify the clock which they consume. + + All these identifiers could be found in: + [1]: <include/dt-bindings/clock/mediatek,mtmips-sysc.h>. + properties: compatible: items: @@ -38,7 +44,8 @@ properties: '#clock-cells': description: - The first cell indicates the clock number. + The first cell indicates the clock number, see [1] for available + clocks. const: 1 '#reset-cells': @@ -56,6 +63,8 @@ additionalProperties: false examples: - | + #include <dt-bindings/clock/mediatek,mtmips-sysc.h> + syscon@0 { compatible = "ralink,rt5350-sysc", "syscon"; reg = <0x0 0x100>; diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml new file mode 100644 index 000000000000..17252b6ea3be --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-nsscc.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,ipq9574-nsscc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Networking Sub System Clock & Reset Controller on IPQ9574 + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + - Anusha Rao <quic_anusha@quicinc.com> + +description: | + Qualcomm networking sub system clock control module provides the clocks, + resets on IPQ9574 + + See also:: + include/dt-bindings/clock/qcom,ipq9574-nsscc.h + include/dt-bindings/reset/qcom,ipq9574-nsscc.h + +properties: + compatible: + const: qcom,ipq9574-nsscc + + clocks: + items: + - description: Board XO source + - description: CMN_PLL NSS 1200MHz (Bias PLL cc) clock source + - description: CMN_PLL PPE 353MHz (Bias PLL ubi nc) clock source + - description: GCC GPLL0 OUT AUX clock source + - description: Uniphy0 NSS Rx clock source + - description: Uniphy0 NSS Tx clock source + - description: Uniphy1 NSS Rx clock source + - description: Uniphy1 NSS Tx clock source + - description: Uniphy2 NSS Rx clock source + - description: Uniphy2 NSS Tx clock source + - description: GCC NSSCC clock source + + '#interconnect-cells': + const: 1 + + clock-names: + items: + - const: xo + - const: nss_1200 + - const: ppe_353 + - const: gpll0_out + - const: uniphy0_rx + - const: uniphy0_tx + - const: uniphy1_rx + - const: uniphy1_tx + - const: uniphy2_rx + - const: uniphy2_tx + - const: bus + +required: + - compatible + - clocks + - clock-names + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,ipq9574-gcc.h> + #include <dt-bindings/clock/qcom,ipq-cmn-pll.h> + clock-controller@39b00000 { + compatible = "qcom,ipq9574-nsscc"; + reg = <0x39b00000 0x80000>; + clocks = <&xo_board_clk>, + <&cmn_pll NSS_1200MHZ_CLK>, + <&cmn_pll PPE_353MHZ_CLK>, + <&gcc GPLL0_OUT_AUX>, + <&uniphy 0>, + <&uniphy 1>, + <&uniphy 2>, + <&uniphy 3>, + <&uniphy 4>, + <&uniphy 5>, + <&gcc GCC_NSSCC_CLK>; + clock-names = "xo", + "nss_1200", + "ppe_353", + "gpll0_out", + "uniphy0_rx", + "uniphy0_tx", + "uniphy1_rx", + "uniphy1_tx", + "uniphy2_rx", + "uniphy2_tx", + "bus"; + #clock-cells = <1>; + #reset-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml index be3835e2e043..90cd3feab5fa 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml @@ -44,6 +44,7 @@ properties: - qcom,rpmcc-msm8998 - qcom,rpmcc-qcm2290 - qcom,rpmcc-qcs404 + - qcom,rpmcc-sdm429 - qcom,rpmcc-sdm660 - qcom,rpmcc-sm6115 - qcom,rpmcc-sm6125 @@ -123,6 +124,7 @@ allOf: - qcom,rpmcc-msm8998 - qcom,rpmcc-qcm2290 - qcom,rpmcc-qcs404 + - qcom,rpmcc-sdm429 - qcom,rpmcc-sdm660 - qcom,rpmcc-sm6115 - qcom,rpmcc-sm6125 diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml index 488d63959424..99ab9106009f 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml @@ -20,6 +20,7 @@ description: | properties: compatible: enum: + - qcom,qcm6490-lpassaudiocc - qcom,sc7280-lpassaoncc - qcom,sc7280-lpassaudiocc - qcom,sc7280-lpasscorecc @@ -68,7 +69,9 @@ allOf: properties: compatible: contains: - const: qcom,sc7280-lpassaudiocc + enum: + - qcom,qcm6490-lpassaudiocc + - qcom,sc7280-lpassaudiocc then: properties: diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml index b88b6c9b399a..9e79f8fec437 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml @@ -64,7 +64,6 @@ allOf: - qcom,sc8280xp-camcc - qcom,sm8450-camcc - qcom,sm8550-camcc - - qcom,x1e80100-camcc then: required: - required-opps diff --git a/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml index 5bbbaa15a260..938a2f1ff3fc 100644 --- a/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml @@ -40,9 +40,9 @@ properties: - description: A phandle to the MMCX power-domain required-opps: - maxItems: 1 - description: - A phandle to an OPP node describing MMCX performance points. + items: + - description: A phandle to an OPP node describing MXC performance points + - description: A phandle to an OPP node describing MMCX performance points required: - compatible @@ -66,7 +66,8 @@ examples: <&sleep_clk>; power-domains = <&rpmhpd RPMHPD_MXC>, <&rpmhpd RPMHPD_MMCX>; - required-opps = <&rpmhpd_opp_low_svs>; + required-opps = <&rpmhpd_opp_low_svs>, + <&rpmhpd_opp_low_svs>; #clock-cells = <1>; #reset-cells = <1>; #power-domain-cells = <1>; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3562-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3562-cru.yaml new file mode 100644 index 000000000000..36a353f5c42a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3562-cru.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/rockchip,rk3562-cru.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip rk3562 Clock and Reset Control Module + +maintainers: + - Elaine Zhang <zhangqing@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +description: + The RK3562 clock controller generates the clock and also implements a reset + controller for SoC peripherals. For example it provides SCLK_UART2 and + PCLK_UART2, as well as SRST_P_UART2 and SRST_S_UART2 for the second UART + module. + +properties: + compatible: + const: rockchip,rk3562-cru + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: xin24m + - const: xin32k + +required: + - compatible + - reg + - "#clock-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + clock-controller@ff100000 { + compatible = "rockchip,rk3562-cru"; + reg = <0xff100000 0x40000>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos2200-cmu.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos2200-cmu.yaml new file mode 100644 index 000000000000..89433e6d3518 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,exynos2200-cmu.yaml @@ -0,0 +1,247 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/samsung,exynos2200-cmu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos2200 SoC clock controller + +maintainers: + - Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com> + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzk@kernel.org> + +description: | + Exynos2200 clock controller is comprised of several CMU units, generating + clocks for different domains. Those CMU units are modeled as separate device + tree nodes, and might depend on each other. The root clocks in that root tree + are two external clocks: XTCXO (76.8 MHz) and RTCCLK (32768 Hz). XTCXO must be + defined as a fixed-rate clock in dts, whereas RTCCLK originates from PMIC. + + CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and + dividers; all other clocks of function blocks (other CMUs) are usually + derived from CMU_TOP. + + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All clocks available for usage + in clock consumer nodes are defined as preprocessor macros in + 'include/dt-bindings/clock/samsung,exynos2200-cmu.h' header. + +properties: + compatible: + enum: + - samsung,exynos2200-cmu-alive + - samsung,exynos2200-cmu-cmgp + - samsung,exynos2200-cmu-hsi0 + - samsung,exynos2200-cmu-peric0 + - samsung,exynos2200-cmu-peric1 + - samsung,exynos2200-cmu-peric2 + - samsung,exynos2200-cmu-peris + - samsung,exynos2200-cmu-top + - samsung,exynos2200-cmu-ufs + - samsung,exynos2200-cmu-vts + + clocks: + minItems: 1 + maxItems: 6 + + clock-names: + minItems: 1 + maxItems: 6 + + "#clock-cells": + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - reg + - "#clock-cells" + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos2200-cmu-alive + + then: + properties: + clocks: + items: + - description: External reference clock (76.8 MHz) + - description: CMU_ALIVE NOC clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: noc + + - if: + properties: + compatible: + contains: + const: samsung,exynos2200-cmu-cmgp + + then: + properties: + clocks: + items: + - description: External reference clock (76.8 MHz) + - description: CMU_CMGP NOC clock (from CMU_TOP) + - description: CMU_CMGP PERI clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: noc + - const: peri + + - if: + properties: + compatible: + contains: + const: samsung,exynos2200-cmu-hsi0 + + then: + properties: + clocks: + items: + - description: External reference clock (76.8 MHz) + - description: External RTC clock (32768 Hz) + - description: CMU_HSI0 NOC clock (from CMU_TOP) + - description: CMU_HSI0 DPGTC clock (from CMU_TOP) + - description: CMU_HSI0 DPOSC clock (from CMU_TOP) + - description: CMU_HSI0 USB32DRD clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: rtcclk + - const: noc + - const: dpgtc + - const: dposc + - const: usb + + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos2200-cmu-peric0 + - samsung,exynos2200-cmu-peric1 + - samsung,exynos2200-cmu-peric2 + + then: + properties: + clocks: + items: + - description: External reference clock (76.8 MHz) + - description: CMU_PERICn NOC clock (from CMU_TOP) + - description: CMU_PERICn IP0 clock (from CMU_TOP) + - description: CMU_PERICn IP1 clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: noc + - const: ip0 + - const: ip1 + + - if: + properties: + compatible: + contains: + const: samsung,exynos2200-cmu-peris + + then: + properties: + clocks: + items: + - description: External reference clock (25.6 MHz) + - description: CMU_PERIS NOC clock (from CMU_TOP) + - description: CMU_PERIS GIC clock (from CMU_TOP) + + clock-names: + items: + - const: tcxo_div3 + - const: noc + - const: gic + + - if: + properties: + compatible: + contains: + const: samsung,exynos2200-cmu-top + + then: + properties: + clocks: + items: + - description: External reference clock (76.8 MHz) + + clock-names: + items: + - const: oscclk + + - if: + properties: + compatible: + contains: + const: samsung,exynos2200-cmu-ufs + + then: + properties: + clocks: + items: + - description: External reference clock (76.8 MHz) + - description: CMU_UFS NOC clock (from CMU_TOP) + - description: CMU_UFS MMC clock (from CMU_TOP) + - description: CMU_UFS UFS clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: noc + - const: mmc + - const: ufs + + - if: + properties: + compatible: + contains: + const: samsung,exynos2200-cmu-vts + + then: + properties: + clocks: + items: + - description: External reference clock (76.8 MHz) + - description: CMU_VTS DMIC clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: dmic + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/samsung,exynos2200-cmu.h> + + cmu_vts: clock-controller@15300000 { + compatible = "samsung,exynos2200-cmu-vts"; + reg = <0x15300000 0x8000>; + #clock-cells = <1>; + + clocks = <&oscclk>, + <&cmu_top CLK_DOUT_CMU_VTS_DMIC>; + clock-names = "oscclk", "dmic"; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos7870-cmu.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos7870-cmu.yaml new file mode 100644 index 000000000000..3c58712f12b9 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,exynos7870-cmu.yaml @@ -0,0 +1,227 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/samsung,exynos7870-cmu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos7870 SoC clock controller + +maintainers: + - Kaustabh Chakraborty <kauschluss@disroot.org> + +description: | + Exynos7870 clock controller is comprised of several CMU units, generating + clocks for different domains. Those CMU units are modeled as separate device + tree nodes, and might depend on each other. The root clock in that root tree + is an external clock: OSCCLK (26 MHz). This external clock must be defined + as a fixed-rate clock in dts. + + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All clocks available for usage + in clock consumer nodes are defined as preprocessor macros in + include/dt-bindings/clock/samsung,exynos7870-cmu.h header. + +properties: + compatible: + enum: + - samsung,exynos7870-cmu-mif + - samsung,exynos7870-cmu-dispaud + - samsung,exynos7870-cmu-fsys + - samsung,exynos7870-cmu-g3d + - samsung,exynos7870-cmu-isp + - samsung,exynos7870-cmu-mfcmscl + - samsung,exynos7870-cmu-peri + + clocks: + minItems: 1 + maxItems: 10 + + clock-names: + minItems: 1 + maxItems: 10 + + "#clock-cells": + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - "#clock-cells" + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos7870-cmu-mif + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + + clock-names: + items: + - const: oscclk + + - if: + properties: + compatible: + contains: + const: samsung,exynos7870-cmu-dispaud + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: CMU_DISPAUD bus clock (from CMU_MIF) + - description: DECON external clock (from CMU_MIF) + - description: DECON vertical clock (from CMU_MIF) + + clock-names: + items: + - const: oscclk + - const: bus + - const: decon_eclk + - const: decon_vclk + + - if: + properties: + compatible: + contains: + const: samsung,exynos7870-cmu-fsys + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: CMU_FSYS bus clock (from CMU_MIF) + - description: USB20DRD clock (from CMU_MIF) + + clock-names: + items: + - const: oscclk + - const: bus + - const: usb20drd + + - if: + properties: + compatible: + contains: + const: samsung,exynos7870-cmu-g3d + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: G3D switch clock (from CMU_MIF) + + clock-names: + items: + - const: oscclk + - const: switch + + - if: + properties: + compatible: + contains: + const: samsung,exynos7870-cmu-isp + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: ISP camera clock (from CMU_MIF) + - description: ISP clock (from CMU_MIF) + - description: ISP VRA clock (from CMU_MIF) + + clock-names: + items: + - const: oscclk + - const: cam + - const: isp + - const: vra + + - if: + properties: + compatible: + contains: + const: samsung,exynos7870-cmu-mfcmscl + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: MSCL clock (from CMU_MIF) + - description: MFC clock (from CMU_MIF) + + clock-names: + items: + - const: oscclk + - const: mfc + - const: mscl + + - if: + properties: + compatible: + contains: + const: samsung,exynos7870-cmu-peri + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: CMU_PERI bus clock (from CMU_MIF) + - description: SPI0 clock (from CMU_MIF) + - description: SPI1 clock (from CMU_MIF) + - description: SPI2 clock (from CMU_MIF) + - description: SPI3 clock (from CMU_MIF) + - description: SPI4 clock (from CMU_MIF) + - description: UART0 clock (from CMU_MIF) + - description: UART1 clock (from CMU_MIF) + - description: UART2 clock (from CMU_MIF) + + clock-names: + items: + - const: oscclk + - const: bus + - const: spi0 + - const: spi1 + - const: spi2 + - const: spi3 + - const: spi4 + - const: uart0 + - const: uart1 + - const: uart2 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/samsung,exynos7870-cmu.h> + + cmu_peri: clock-controller@101f0000 { + compatible = "samsung,exynos7870-cmu-peri"; + reg = <0x101f0000 0x1000>; + #clock-cells = <1>; + + clock-names = "oscclk", "bus", "spi0", "spi1", "spi2", + "spi3", "spi4", "uart0", "uart1", "uart2"; + clocks = <&oscclk>, + <&cmu_mif CLK_GOUT_MIF_CMU_PERI_BUS>, + <&cmu_mif CLK_GOUT_MIF_CMU_PERI_SPI0>, + <&cmu_mif CLK_GOUT_MIF_CMU_PERI_SPI1>, + <&cmu_mif CLK_GOUT_MIF_CMU_PERI_SPI2>, + <&cmu_mif CLK_GOUT_MIF_CMU_PERI_SPI3>, + <&cmu_mif CLK_GOUT_MIF_CMU_PERI_SPI4>, + <&cmu_mif CLK_GOUT_MIF_CMU_PERI_UART0>, + <&cmu_mif CLK_GOUT_MIF_CMU_PERI_UART1>, + <&cmu_mif CLK_GOUT_MIF_CMU_PERI_UART2>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/ti,clkctrl.yaml b/Documentation/devicetree/bindings/clock/ti,clkctrl.yaml new file mode 100644 index 000000000000..49787550ce45 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti,clkctrl.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/ti,clkctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments clkctrl clock + +maintainers: + - Tony Lindgren <tony@atomide.com> + - Andreas Kemnade <andreas@kemnade.info> + +description: | + Texas Instruments SoCs can have a clkctrl clock controller for each + interconnect target module. The clkctrl clock controller manages functional + and interface clocks for each module. Each clkctrl controller can also + gate one or more optional functional clocks for a module, and can have one + or more clock muxes. There is a clkctrl clock controller typically for each + interconnect target module on omap4 and later variants. + + The clock consumers can specify the index of the clkctrl clock using + the hardware offset from the clkctrl instance register space. The optional + clocks can be specified by clkctrl hardware offset and the index of the + optional clock. + +properties: + compatible: + enum: + - ti,clkctrl + - ti,clkctrl-l4-cfg + - ti,clkctrl-l4-per + - ti,clkctrl-l4-secure + - ti,clkctrl-l4-wkup + + "#clock-cells": + const: 2 + + clock-output-names: + maxItems: 1 + + reg: + minItems: 1 + maxItems: 8 # arbitrary, should be enough + +required: + - compatible + - "#clock-cells" + - clock-output-names + - reg + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <1>; + #size-cells = <1>; + + clock@20 { + compatible = "ti,clkctrl"; + clock-output-names = "l4_per"; + reg = <0x20 0x1b0>; + #clock-cells = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/ti-clkctrl.txt b/Documentation/devicetree/bindings/clock/ti-clkctrl.txt deleted file mode 100644 index d20db7974a38..000000000000 --- a/Documentation/devicetree/bindings/clock/ti-clkctrl.txt +++ /dev/null @@ -1,63 +0,0 @@ -Texas Instruments clkctrl clock binding - -Texas Instruments SoCs can have a clkctrl clock controller for each -interconnect target module. The clkctrl clock controller manages functional -and interface clocks for each module. Each clkctrl controller can also -gate one or more optional functional clocks for a module, and can have one -or more clock muxes. There is a clkctrl clock controller typically for each -interconnect target module on omap4 and later variants. - -The clock consumers can specify the index of the clkctrl clock using -the hardware offset from the clkctrl instance register space. The optional -clocks can be specified by clkctrl hardware offset and the index of the -optional clock. - -For more information, please see the Linux clock framework binding at -Documentation/devicetree/bindings/clock/clock-bindings.txt. - -Required properties : -- compatible : shall be "ti,clkctrl" or a clock domain specific name: - "ti,clkctrl-l4-cfg" - "ti,clkctrl-l4-per" - "ti,clkctrl-l4-secure" - "ti,clkctrl-l4-wkup" -- clock-output-names : from common clock binding -- #clock-cells : shall contain 2 with the first entry being the instance - offset from the clock domain base and the second being the - clock index -- reg : clock registers - -Example: Clock controller node on omap 4430: - -&cm2 { - l4per: cm@1400 { - cm_l4per@0 { - cm_l4per_clkctrl: clock@20 { - compatible = "ti,clkctrl"; - clock-output-names = "l4_per"; - reg = <0x20 0x1b0>; - #clock-cells = <2>; - }; - }; - }; -}; - -Example: Preprocessor helper macros in dt-bindings/clock/ti-clkctrl.h - -#define OMAP4_CLKCTRL_OFFSET 0x20 -#define OMAP4_CLKCTRL_INDEX(offset) ((offset) - OMAP4_CLKCTRL_OFFSET) -#define MODULEMODE_HWCTRL 1 -#define MODULEMODE_SWCTRL 2 - -#define OMAP4_GPTIMER10_CLKTRL OMAP4_CLKCTRL_INDEX(0x28) -#define OMAP4_GPTIMER11_CLKTRL OMAP4_CLKCTRL_INDEX(0x30) -#define OMAP4_GPTIMER2_CLKTRL OMAP4_CLKCTRL_INDEX(0x38) -... -#define OMAP4_GPIO2_CLKCTRL OMAP_CLKCTRL_INDEX(0x60) - -Example: Clock consumer node for GPIO2: - -&gpio2 { - clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 - &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 8>; -}; diff --git a/Documentation/devicetree/bindings/crypto/fsl,sec2.0.yaml b/Documentation/devicetree/bindings/crypto/fsl,sec2.0.yaml new file mode 100644 index 000000000000..2091b89bb726 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/fsl,sec2.0.yaml @@ -0,0 +1,144 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/fsl,sec2.0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale SoC SEC Security Engines versions 1.x-2.x-3.x + +maintainers: + - J. Neuschäfer <j.ne@posteo.net> + +properties: + compatible: + description: + Should contain entries for this and backward compatible SEC versions, + high to low. Warning - SEC1 and SEC2 are mutually exclusive. + oneOf: + - items: + - const: fsl,sec3.3 + - const: fsl,sec3.1 + - const: fsl,sec3.0 + - const: fsl,sec2.4 + - const: fsl,sec2.2 + - const: fsl,sec2.1 + - const: fsl,sec2.0 + - items: + - const: fsl,sec3.1 + - const: fsl,sec3.0 + - const: fsl,sec2.4 + - const: fsl,sec2.2 + - const: fsl,sec2.1 + - const: fsl,sec2.0 + - items: + - const: fsl,sec3.0 + - const: fsl,sec2.4 + - const: fsl,sec2.2 + - const: fsl,sec2.1 + - const: fsl,sec2.0 + - items: + - const: fsl,sec2.4 + - const: fsl,sec2.2 + - const: fsl,sec2.1 + - const: fsl,sec2.0 + - items: + - const: fsl,sec2.2 + - const: fsl,sec2.1 + - const: fsl,sec2.0 + - items: + - const: fsl,sec2.1 + - const: fsl,sec2.0 + - items: + - const: fsl,sec2.0 + - items: + - const: fsl,sec1.2 + - const: fsl,sec1.0 + - items: + - const: fsl,sec1.0 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + fsl,num-channels: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 4 ] + description: An integer representing the number of channels available. + + fsl,channel-fifo-len: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 100 + description: + An integer representing the number of descriptor pointers each channel + fetch fifo can hold. + + fsl,exec-units-mask: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 0xfff + description: | + The bitmask representing what execution units (EUs) are available. + EU information should be encoded following the SEC's Descriptor Header + Dword EU_SEL0 field documentation, i.e. as follows: + + bit 0 = reserved - should be 0 + bit 1 = set if SEC has the ARC4 EU (AFEU) + bit 2 = set if SEC has the DES/3DES EU (DEU) + bit 3 = set if SEC has the message digest EU (MDEU/MDEU-A) + bit 4 = set if SEC has the random number generator EU (RNG) + bit 5 = set if SEC has the public key EU (PKEU) + bit 6 = set if SEC has the AES EU (AESU) + bit 7 = set if SEC has the Kasumi EU (KEU) + bit 8 = set if SEC has the CRC EU (CRCU) + bit 11 = set if SEC has the message digest EU extended alg set (MDEU-B) + + remaining bits are reserved for future SEC EUs. + + fsl,descriptor-types-mask: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + The bitmask representing what descriptors are available. Descriptor type + information should be encoded following the SEC's Descriptor Header Dword + DESC_TYPE field documentation, i.e. as follows: + + bit 0 = SEC supports descriptor type aesu_ctr_nonsnoop + bit 1 = SEC supports descriptor type ipsec_esp + bit 2 = SEC supports descriptor type common_nonsnoop + bit 3 = SEC supports descriptor type 802.11i AES ccmp + bit 4 = SEC supports descriptor type hmac_snoop_no_afeu + bit 5 = SEC supports descriptor type srtp + bit 6 = SEC supports descriptor type non_hmac_snoop_no_afeu + bit 7 = SEC supports descriptor type pkeu_assemble + bit 8 = SEC supports descriptor type aesu_key_expand_output + bit 9 = SEC supports descriptor type pkeu_ptmul + bit 10 = SEC supports descriptor type common_nonsnoop_afeu + bit 11 = SEC supports descriptor type pkeu_ptadd_dbl + + ..and so on and so forth. + +required: + - compatible + - reg + - fsl,num-channels + - fsl,channel-fifo-len + - fsl,exec-units-mask + - fsl,descriptor-types-mask + +unevaluatedProperties: false + +examples: + - | + /* MPC8548E */ + crypto@30000 { + compatible = "fsl,sec2.1", "fsl,sec2.0"; + reg = <0x30000 0x10000>; + interrupts = <29 2>; + interrupt-parent = <&mpic>; + fsl,num-channels = <4>; + fsl,channel-fifo-len = <24>; + fsl,exec-units-mask = <0xfe>; + fsl,descriptor-types-mask = <0x12b0ebf>; + }; + +... diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt deleted file mode 100644 index 125f155d00d0..000000000000 --- a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt +++ /dev/null @@ -1,65 +0,0 @@ -Freescale SoC SEC Security Engines versions 1.x-2.x-3.x - -Required properties: - -- compatible : Should contain entries for this and backward compatible - SEC versions, high to low, e.g., "fsl,sec2.1", "fsl,sec2.0" (SEC2/3) - e.g., "fsl,sec1.2", "fsl,sec1.0" (SEC1) - warning: SEC1 and SEC2 are mutually exclusive -- reg : Offset and length of the register set for the device -- interrupts : the SEC's interrupt number -- fsl,num-channels : An integer representing the number of channels - available. -- fsl,channel-fifo-len : An integer representing the number of - descriptor pointers each channel fetch fifo can hold. -- fsl,exec-units-mask : The bitmask representing what execution units - (EUs) are available. It's a single 32-bit cell. EU information - should be encoded following the SEC's Descriptor Header Dword - EU_SEL0 field documentation, i.e. as follows: - - bit 0 = reserved - should be 0 - bit 1 = set if SEC has the ARC4 EU (AFEU) - bit 2 = set if SEC has the DES/3DES EU (DEU) - bit 3 = set if SEC has the message digest EU (MDEU/MDEU-A) - bit 4 = set if SEC has the random number generator EU (RNG) - bit 5 = set if SEC has the public key EU (PKEU) - bit 6 = set if SEC has the AES EU (AESU) - bit 7 = set if SEC has the Kasumi EU (KEU) - bit 8 = set if SEC has the CRC EU (CRCU) - bit 11 = set if SEC has the message digest EU extended alg set (MDEU-B) - -remaining bits are reserved for future SEC EUs. - -- fsl,descriptor-types-mask : The bitmask representing what descriptors - are available. It's a single 32-bit cell. Descriptor type information - should be encoded following the SEC's Descriptor Header Dword DESC_TYPE - field documentation, i.e. as follows: - - bit 0 = set if SEC supports the aesu_ctr_nonsnoop desc. type - bit 1 = set if SEC supports the ipsec_esp descriptor type - bit 2 = set if SEC supports the common_nonsnoop desc. type - bit 3 = set if SEC supports the 802.11i AES ccmp desc. type - bit 4 = set if SEC supports the hmac_snoop_no_afeu desc. type - bit 5 = set if SEC supports the srtp descriptor type - bit 6 = set if SEC supports the non_hmac_snoop_no_afeu desc.type - bit 7 = set if SEC supports the pkeu_assemble descriptor type - bit 8 = set if SEC supports the aesu_key_expand_output desc.type - bit 9 = set if SEC supports the pkeu_ptmul descriptor type - bit 10 = set if SEC supports the common_nonsnoop_afeu desc. type - bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor type - - ..and so on and so forth. - -Example: - - /* MPC8548E */ - crypto@30000 { - compatible = "fsl,sec2.1", "fsl,sec2.0"; - reg = <0x30000 0x10000>; - interrupts = <29 2>; - interrupt-parent = <&mpic>; - fsl,num-channels = <4>; - fsl,channel-fifo-len = <24>; - fsl,exec-units-mask = <0xfe>; - fsl,descriptor-types-mask = <0x12b0ebf>; - }; diff --git a/Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml b/Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml new file mode 100644 index 000000000000..997bf9717f9e --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip93.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/inside-secure,safexcel-eip93.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Inside Secure SafeXcel EIP-93 cryptographic engine + +maintainers: + - Christian Marangi <ansuelsmth@gmail.com> + +description: | + The Inside Secure SafeXcel EIP-93 is a cryptographic engine IP block + integrated in varios devices with very different and generic name from + PKTE to simply vendor+EIP93. The real IP under the hood is actually + developed by Inside Secure and given to license to vendors. + + The IP block is sold with different model based on what feature are + needed and are identified with the final letter. Each letter correspond + to a specific set of feature and multiple letter reflect the sum of the + feature set. + + EIP-93 models: + - EIP-93i: (basic) DES/Triple DES, AES, PRNG, IPsec ESP, SRTP, SHA1 + - EIP-93ie: i + SHA224/256, AES-192/256 + - EIP-93is: i + SSL/DTLS/DTLS, MD5, ARC4 + - EIP-93ies: i + e + s + - EIP-93iw: i + AES-XCB-MAC, AES-CCM + +properties: + compatible: + oneOf: + - items: + - const: airoha,en7581-eip93 + - const: inside-secure,safexcel-eip93ies + - items: + - not: {} + description: Need a SoC specific compatible + - enum: + - inside-secure,safexcel-eip93i + - inside-secure,safexcel-eip93ie + - inside-secure,safexcel-eip93is + - inside-secure,safexcel-eip93iw + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + crypto@1e004000 { + compatible = "airoha,en7581-eip93", "inside-secure,safexcel-eip93ies"; + reg = <0x1fb70000 0x1000>; + + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/crypto/inside-secure,safexcel.yaml b/Documentation/devicetree/bindings/crypto/inside-secure,safexcel.yaml index ef07258d16c1..343e2d04c797 100644 --- a/Documentation/devicetree/bindings/crypto/inside-secure,safexcel.yaml +++ b/Documentation/devicetree/bindings/crypto/inside-secure,safexcel.yaml @@ -47,6 +47,8 @@ properties: - const: core - const: reg + dma-coherent: true + required: - reg - interrupts diff --git a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml index 5e6f8b642545..ed7e16bd11d3 100644 --- a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml @@ -20,6 +20,7 @@ properties: - qcom,ipq5332-trng - qcom,ipq5424-trng - qcom,ipq9574-trng + - qcom,qcs615-trng - qcom,qcs8300-trng - qcom,sa8255p-trng - qcom,sa8775p-trng diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml index 3ed56d9d378e..3f35122f7873 100644 --- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml @@ -55,6 +55,7 @@ properties: - qcom,sm8550-qce - qcom,sm8650-qce - qcom,sm8750-qce + - qcom,x1e80100-qce - const: qcom,sm8150-qce - const: qcom,qce diff --git a/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml b/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml new file mode 100644 index 000000000000..5e6da66499a5 --- /dev/null +++ b/Documentation/devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/apple,h7-display-pipe-mipi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple pre-DCP display controller MIPI interface + +maintainers: + - Sasha Finkelstein <fnkl.kernel@gmail.com> + +description: + The MIPI controller part of the pre-DCP Apple display controller + +allOf: + - $ref: dsi-controller.yaml# + +properties: + compatible: + items: + - enum: + - apple,t8112-display-pipe-mipi + - apple,t8103-display-pipe-mipi + - const: apple,h7-display-pipe-mipi + + reg: + maxItems: 1 + + power-domains: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Input port. Always connected to the primary controller + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Output MIPI DSI port to the panel + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - ports + +unevaluatedProperties: false + +examples: + - | + dsi@28200000 { + compatible = "apple,t8103-display-pipe-mipi", "apple,h7-display-pipe-mipi"; + reg = <0x28200000 0xc000>; + power-domains = <&ps_dispdfr_mipi>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + dfr_adp_out_mipi: endpoint { + remote-endpoint = <&dfr_adp_out_mipi>; + }; + }; + + port@1 { + reg = <1>; + + dfr_panel_in: endpoint { + remote-endpoint = <&dfr_mipi_out_panel>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml b/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml new file mode 100644 index 000000000000..102fb1804c0c --- /dev/null +++ b/Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/apple,h7-display-pipe.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple pre-DCP display controller + +maintainers: + - Sasha Finkelstein <fnkl.kernel@gmail.com> + +description: + A secondary display controller used to drive the "touchbar" on + certain Apple laptops. + +properties: + compatible: + items: + - enum: + - apple,t8112-display-pipe + - apple,t8103-display-pipe + - const: apple,h7-display-pipe + + reg: + items: + - description: Primary register block, controls planes and blending + - description: + Contains other configuration registers like interrupt + and FIFO control + + reg-names: + items: + - const: be + - const: fe + + power-domains: + description: + Phandles to pmgr entries that are needed for this controller to turn on. + Aside from that, their specific functions are unknown + maxItems: 2 + + interrupts: + items: + - description: Unknown function + - description: Primary interrupt. Vsync events are reported via it + + interrupt-names: + items: + - const: be + - const: fe + + iommus: + maxItems: 1 + + port: + $ref: /schemas/graph.yaml#/properties/port + description: Output port. Always connected to apple,h7-display-pipe-mipi + +required: + - compatible + - reg + - interrupts + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/apple-aic.h> + display-pipe@28200000 { + compatible = "apple,t8103-display-pipe", "apple,h7-display-pipe"; + reg = <0x28200000 0xc000>, + <0x28400000 0x4000>; + reg-names = "be", "fe"; + power-domains = <&ps_dispdfr_fe>, <&ps_dispdfr_be>; + interrupt-parent = <&aic>; + interrupts = <AIC_IRQ 502 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 506 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "be", "fe"; + iommus = <&displaydfr_dart 0>; + + port { + dfr_adp_out_mipi: endpoint { + remote-endpoint = <&dfr_mipi_in_adp>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index 6ceeed76e88e..0487bbffd7f7 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -41,6 +41,7 @@ properties: - enum: - ti,ds90cf364a # For the DS90CF364A FPD-Link LVDS Receiver - ti,ds90cf384a # For the DS90CF384A FPD-Link LVDS Receiver + - ti,sn65lvds822 # For the SN65LVDS822 FlatLink LVDS Receiver - ti,sn65lvds94 # For the SN65DS94 LVDS serdes - const: lvds-decoder # Generic LVDS decoders compatible fallback - enum: diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index bad6f5c81b06..9b5f3f3eab19 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -35,6 +35,9 @@ properties: vcc-supply: description: A 1.8V power supply (see regulator/regulator.yaml). + interrupts: + maxItems: 1 + ports: $ref: /schemas/graph.yaml#/properties/ports diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml index 0f1e556dc8ef..b659d79393a8 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml @@ -27,6 +27,7 @@ properties: - mediatek,mt8188-dp-intf - mediatek,mt8192-dpi - mediatek,mt8195-dp-intf + - mediatek,mt8195-dpi - items: - enum: - mediatek,mt6795-dpi @@ -35,6 +36,10 @@ properties: - enum: - mediatek,mt8365-dpi - const: mediatek,mt8192-dpi + - items: + - enum: + - mediatek,mt8188-dpi + - const: mediatek,mt8195-dpi reg: maxItems: 1 @@ -116,11 +121,13 @@ examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> dpi: dpi@1401d000 { compatible = "mediatek,mt8173-dpi"; reg = <0x1401d000 0x1000>; interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&spm MT8173_POWER_DOMAIN_MM>; clocks = <&mmsys CLK_MM_DPI_PIXEL>, <&mmsys CLK_MM_DPI_ENGINE>, <&apmixedsys CLK_APMIXED_TVDPLL>; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml index 846de6c17d93..a5b88eb97e3b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml @@ -22,6 +22,9 @@ properties: oneOf: - enum: - mediatek,mt8195-disp-dsc + - items: + - const: mediatek,mt8188-disp-dsc + - const: mediatek,mt8195-disp-dsc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index ffbd1dc9470e..2aab33cd0017 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -231,6 +231,7 @@ allOf: then: properties: clocks: + minItems: 7 maxItems: 7 clock-names: items: @@ -248,29 +249,12 @@ allOf: contains: enum: - qcom,msm8916-dsi-ctrl - then: - properties: - clocks: - maxItems: 6 - clock-names: - items: - - const: mdp_core - - const: iface - - const: bus - - const: byte - - const: pixel - - const: core - - - if: - properties: - compatible: - contains: - enum: - qcom,msm8953-dsi-ctrl - qcom,msm8976-dsi-ctrl then: properties: clocks: + minItems: 6 maxItems: 6 clock-names: items: @@ -291,6 +275,7 @@ allOf: then: properties: clocks: + minItems: 7 maxItems: 7 clock-names: items: @@ -311,6 +296,7 @@ allOf: then: properties: clocks: + minItems: 7 maxItems: 7 clock-names: items: @@ -328,28 +314,13 @@ allOf: contains: enum: - qcom,msm8998-dsi-ctrl - - qcom,sm6125-dsi-ctrl - - qcom,sm6350-dsi-ctrl - then: - properties: - clocks: - maxItems: 6 - clock-names: - items: - - const: byte - - const: byte_intf - - const: pixel - - const: core - - const: iface - - const: bus - - - if: - properties: - compatible: - contains: - enum: - qcom,sc7180-dsi-ctrl - qcom,sc7280-dsi-ctrl + - qcom,sdm845-dsi-ctrl + - qcom,sm6115-dsi-ctrl + - qcom,sm6125-dsi-ctrl + - qcom,sm6350-dsi-ctrl + - qcom,sm6375-dsi-ctrl - qcom,sm6150-dsi-ctrl - qcom,sm7150-dsi-ctrl - qcom,sm8150-dsi-ctrl @@ -361,6 +332,7 @@ allOf: then: properties: clocks: + minItems: 6 maxItems: 6 clock-names: items: @@ -380,6 +352,7 @@ allOf: then: properties: clocks: + minItems: 9 maxItems: 9 clock-names: items: @@ -393,27 +366,6 @@ allOf: - const: pixel - const: core - - if: - properties: - compatible: - contains: - enum: - - qcom,sdm845-dsi-ctrl - - qcom,sm6115-dsi-ctrl - - qcom,sm6375-dsi-ctrl - then: - properties: - clocks: - maxItems: 6 - clock-names: - items: - - const: byte - - const: byte_intf - - const: pixel - - const: core - - const: iface - - const: bus - unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml index 6b57ce41c95f..d0ce85a08b6d 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml @@ -15,6 +15,8 @@ description: properties: "#clock-cells": const: 1 + description: + See include/dt-bindings/clock/qcom,dsi-phy-28nm.h for clock IDs. "#phy-cells": const: 0 diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml index ab884e236429..4392aa7a4ffe 100644 --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml @@ -123,6 +123,7 @@ allOf: compatible: contains: enum: + - qcom,adreno-gmu-623.0 - qcom,adreno-gmu-635.0 - qcom,adreno-gmu-660.1 - qcom,adreno-gmu-663.0 diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml index a90a8b3f1a9e..5fac3e266703 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml @@ -52,6 +52,13 @@ patternProperties: items: - const: qcom,sa8775p-dp + "^phy@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + const: qcom,sa8775p-edp-phy + required: - compatible @@ -61,6 +68,7 @@ examples: - | #include <dt-bindings/interconnect/qcom,icc.h> #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,sa8775p-dispcc.h> #include <dt-bindings/clock/qcom,sa8775p-gcc.h> #include <dt-bindings/interconnect/qcom,sa8775p-rpmh.h> #include <dt-bindings/power/qcom,rpmhpd.h> @@ -158,6 +166,26 @@ examples: }; }; + mdss0_dp0_phy: phy@aec2a00 { + compatible = "qcom,sa8775p-edp-phy"; + + reg = <0x0aec2a00 0x200>, + <0x0aec2200 0xd0>, + <0x0aec2600 0xd0>, + <0x0aec2000 0x1c8>; + + clocks = <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_AUX_CLK>, + <&dispcc0 MDSS_DISP_CC_MDSS_AHB_CLK>; + clock-names = "aux", + "cfg_ahb"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vdda-phy-supply = <&vreg_l1c>; + vdda-pll-supply = <&vreg_l4a>; + }; + displayport-controller@af54000 { compatible = "qcom,sa8775p-dp"; @@ -186,9 +214,9 @@ examples: assigned-clocks = <&dispcc_mdss_dptx0_link_clk_src>, <&dispcc_mdss_dptx0_pixel0_clk_src>; - assigned-clock-parents = <&mdss0_edp_phy 0>, <&mdss0_edp_phy 1>; + assigned-clock-parents = <&mdss0_dp0_phy 0>, <&mdss0_dp0_phy 1>; - phys = <&mdss0_edp_phy>; + phys = <&mdss0_dp0_phy>; phy-names = "dp"; operating-points-v2 = <&dp_opp_table>; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml index 1ea50a2c7c8e..59192c59ddb9 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml @@ -30,10 +30,14 @@ properties: maxItems: 1 interconnects: - maxItems: 2 + items: + - description: Interconnect path from mdp0 port to the data bus + - description: Interconnect path from CPU to the reg bus interconnect-names: - maxItems: 2 + items: + - const: mdp0-mem + - const: cpu-cfg patternProperties: "^display-controller@[0-9a-f]+$": @@ -91,9 +95,9 @@ examples: reg = <0x0ae00000 0x1000>; reg-names = "mdss"; - interconnects = <&mmss_noc MASTER_MDP 0 &gem_noc SLAVE_LLCC 0>, - <&mc_virt MASTER_LLCC 0 &mc_virt SLAVE_EBI1 0>; - interconnect-names = "mdp0-mem", "mdp1-mem"; + interconnects = <&mmss_noc MASTER_MDP 0 &mc_virt SLAVE_EBI1 0>, + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_DISPLAY_CFG 0>; + interconnect-names = "mdp0-mem", "cpu-cfg"; resets = <&dispcc DISP_CC_MDSS_CORE_BCR>; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml index 24cece1e888b..a1c53e191033 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-mdss.yaml @@ -29,10 +29,14 @@ properties: maxItems: 1 interconnects: - maxItems: 2 + items: + - description: Interconnect path from mdp0 port to the data bus + - description: Interconnect path from CPU to the reg bus interconnect-names: - maxItems: 2 + items: + - const: mdp0-mem + - const: cpu-cfg patternProperties: "^display-controller@[0-9a-f]+$": @@ -75,12 +79,17 @@ examples: #include <dt-bindings/clock/qcom,rpmh.h> #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/power/qcom,rpmhpd.h> + #include <dt-bindings/interconnect/qcom,sm8650-rpmh.h> display-subsystem@ae00000 { compatible = "qcom,sm8650-mdss"; reg = <0x0ae00000 0x1000>; reg-names = "mdss"; + interconnects = <&mmss_noc MASTER_MDP 0 &mc_virt SLAVE_EBI1 0>, + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_DISPLAY_CFG 0>; + interconnect-names = "mdp0-mem", "cpu-cfg"; + resets = <&dispcc_core_bcr>; power-domains = <&dispcc_gdsc>; diff --git a/Documentation/devicetree/bindings/display/panel/apple,summit.yaml b/Documentation/devicetree/bindings/display/panel/apple,summit.yaml new file mode 100644 index 000000000000..f081755325e9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/apple,summit.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/apple,summit.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple "Summit" display panel + +maintainers: + - Sasha Finkelstein <fnkl.kernel@gmail.com> + +description: + An OLED panel used as a touchbar on certain Apple laptops. + Contains a backlight device, which controls brightness of the panel itself. + The backlight common properties are included for this reason + +allOf: + - $ref: panel-common.yaml# + - $ref: /schemas/leds/backlight/common.yaml# + +properties: + compatible: + items: + - enum: + - apple,j293-summit + - apple,j493-summit + - const: apple,summit + + reg: + maxItems: 1 + +required: + - compatible + - reg + - max-brightness + - port + +unevaluatedProperties: false + +examples: + - | + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "apple,j293-summit", "apple,summit"; + reg = <0>; + max-brightness = <255>; + + port { + endpoint { + remote-endpoint = <&dfr_bridge_out>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml index c649fb085833..e4c1aa5deab9 100644 --- a/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml +++ b/Documentation/devicetree/bindings/display/panel/himax,hx83102.yaml @@ -18,8 +18,14 @@ properties: - enum: # Boe nv110wum-l60 11.0" WUXGA TFT LCD panel - boe,nv110wum-l60 + # CSOT pna957qt1-1 10.95" WUXGA TFT LCD panel + - csot,pna957qt1-1 # IVO t109nw41 11.0" WUXGA TFT LCD panel - ivo,t109nw41 + # KINGDISPLAY KD110N11-51IE 10.95" WUXGA TFT LCD panel + - kingdisplay,kd110n11-51ie + # STARRY 2082109QFH040022-50E 10.95" WUXGA TFT LCD panel + - starry,2082109qfh040022-50e # STARRY himax83102-j02 10.51" WUXGA TFT LCD panel - starry,himax83102-j02 - const: himax,hx83102 diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml index 3623ffa6518d..96621b89ae9e 100644 --- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml +++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml @@ -33,7 +33,9 @@ properties: description: Reference to the regulator powering the panel VCC pins. data-mapping: - const: jeida-24 + enum: + - jeida-18 + - jeida-24 width-mm: const: 210 @@ -41,6 +43,7 @@ properties: height-mm: const: 158 + backlight: true panel-timing: true port: true @@ -48,7 +51,6 @@ additionalProperties: false required: - compatible - - vcc-supply - data-mapping - width-mm - height-mm diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml index e80fc7006984..548f5ac14500 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml @@ -40,6 +40,8 @@ properties: - auo,g185han01 # AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel - auo,g190ean01 + # BOE AV123Z7M-N17 12.3" (1920x720) LVDS TFT LCD panel + - boe,av123z7m-n17 # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel - koe,tx26d202vm0bwa # Lincoln Technology Solutions, LCD185-101CT 10.1" TFT 1920x1200 diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index e3ee3a332bb7..b0de4fd6f3d4 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -63,6 +63,8 @@ properties: - auo,t215hvn01 # Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel - avic,tm070ddh03 + # BOE AV101HDT-a10 10.1" 1280x720 LVDS panel + - boe,av101hdt-a10 # BOE BP082WX1-100 8.2" WXGA (1280x800) LVDS panel - boe,bp082wx1-100 # BOE BP101WX1-100 10.1" WXGA (1280x800) LVDS panel diff --git a/Documentation/devicetree/bindings/display/panel/raydium,rm67200.yaml b/Documentation/devicetree/bindings/display/panel/raydium,rm67200.yaml new file mode 100644 index 000000000000..54c9c0ef45ec --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm67200.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/raydium,rm67200.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Raydium RM67200 based MIPI-DSI panels + +maintainers: + - Sebastian Reichel <sebastian.reichel@collabora.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + - wanchanglong,w552793baa + - const: raydium,rm67200 + + reg: + maxItems: 1 + + vdd-supply: + description: 2.8V Logic voltage + + iovcc-supply: + description: 1.8V IO voltage + + vsp-supply: + description: positive 5.5V voltage + + vsn-supply: + description: negative 5.5V voltage + + backlight: true + port: true + reset-gpios: true + +required: + - compatible + - port + - reg + - reset-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + dsi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "wanchanglong,w552793baa", "raydium,rm67200"; + reg = <0>; + + vdd-supply = <®ulator1>; + iovcc-supply = <®ulator2>; + vsp-supply = <®ulator3>; + vsn-supply = <®ulator4>; + reset-gpios = <&gpiobank 42 GPIO_ACTIVE_LOW>; + + port { + panel0_in: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/visionox,rm692e5.yaml b/Documentation/devicetree/bindings/display/panel/visionox,rm692e5.yaml new file mode 100644 index 000000000000..d4b4672815fe --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/visionox,rm692e5.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/visionox,rm692e5.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Visionox RM692E5 6.55" 2400x1080 120Hz MIPI-DSI Panel + +maintainers: + - Danila Tikhonov <danila@jiaxyga.com> + +description: + The Visionox RM692E5 is a generic DSI Panel IC used to control + AMOLED panels. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + oneOf: + - enum: + - visionox,rm692e5 + - items: + - enum: + - nothing,rm692e5-spacewar + - const: visionox,rm692e5 + + reg: + maxItems: 1 + + vdd-supply: + description: 3.3V source voltage rail + + vddio-supply: + description: 1.8V I/O source voltage rail + + reset-gpios: true + port: true + +required: + - compatible + - reg + - reset-gpios + - vdd-supply + - vddio-supply + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "nothing,rm692e5-spacewar", + "visionox,rm692e5"; + reg = <0>; + + reset-gpios = <&tlmm 44 GPIO_ACTIVE_LOW>; + + vdd-supply = <&vdd_oled>; + vddio-supply = <&vdd_io_oled>; + + port { + panel_in: endpoint { + remote-endpoint = <&mdss_dsi0_out>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index 3880b4c2ea9a..c27dfea7fc62 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -47,12 +47,26 @@ properties: maxItems: 1 # See compatible-specific constraints below. - clocks: true - clock-names: true + clocks: + minItems: 1 + maxItems: 8 + + clock-names: + minItems: 1 + maxItems: 8 + interrupts: + minItems: 1 + maxItems: 4 description: Interrupt specifiers, one per DU channel - resets: true - reset-names: true + + resets: + minItems: 1 + maxItems: 2 + + reset-names: + minItems: 1 + maxItems: 2 power-domains: maxItems: 1 @@ -74,7 +88,7 @@ properties: renesas,cmms: $ref: /schemas/types.yaml#/definitions/phandle-array - minItems: 1 + minItems: 2 maxItems: 4 items: maxItems: 1 @@ -174,6 +188,7 @@ allOf: - pattern: '^dclkin\.[01]$' interrupts: + minItems: 2 maxItems: 2 resets: @@ -229,6 +244,7 @@ allOf: - pattern: '^dclkin\.[01]$' interrupts: + minItems: 2 maxItems: 2 resets: @@ -282,6 +298,7 @@ allOf: - pattern: '^dclkin\.[01]$' interrupts: + minItems: 2 maxItems: 2 resets: @@ -336,6 +353,7 @@ allOf: - pattern: '^dclkin\.[01]$' interrupts: + minItems: 2 maxItems: 2 resets: @@ -397,6 +415,7 @@ allOf: - pattern: '^dclkin\.[012]$' interrupts: + minItems: 3 maxItems: 3 resets: @@ -461,9 +480,11 @@ allOf: - pattern: '^dclkin\.[0123]$' interrupts: + minItems: 4 maxItems: 4 resets: + minItems: 2 maxItems: 2 reset-names: @@ -534,9 +555,11 @@ allOf: - pattern: '^dclkin\.[012]$' interrupts: + minItems: 3 maxItems: 3 resets: + minItems: 2 maxItems: 2 reset-names: @@ -605,9 +628,11 @@ allOf: - pattern: '^dclkin\.[013]$' interrupts: + minItems: 3 maxItems: 3 resets: + minItems: 2 maxItems: 2 reset-names: @@ -726,6 +751,7 @@ allOf: - pattern: '^dclkin\.[01]$' interrupts: + minItems: 2 maxItems: 2 resets: diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml index d8e761865f27..96b4b088eebe 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml @@ -29,6 +29,7 @@ allOf: properties: compatible: enum: + - rockchip,rk3576-dw-hdmi-qp - rockchip,rk3588-dw-hdmi-qp reg: @@ -156,7 +157,7 @@ examples: <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH 0>, <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH 0>; interrupt-names = "avp", "cec", "earc", "main", "hpd"; - phys = <&hdptxphy_hdmi0>; + phys = <&hdptxphy0>; power-domains = <&power RK3588_PD_VO1>; resets = <&cru SRST_HDMITX0_REF>, <&cru SRST_HDMIHDP0>; reset-names = "ref", "hdp"; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml index 2531726af306..f546d481b7e5 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml @@ -14,12 +14,14 @@ description: maintainers: - Sandy Huang <hjc@rock-chips.com> - Heiko Stuebner <heiko@sntech.de> + - Andy Yan <andyshrk@163.com> properties: compatible: enum: - rockchip,rk3566-vop - rockchip,rk3568-vop + - rockchip,rk3576-vop - rockchip,rk3588-vop reg: @@ -37,10 +39,21 @@ properties: - const: gamma-lut interrupts: - maxItems: 1 + minItems: 1 + maxItems: 4 description: - The VOP interrupt is shared by several interrupt sources, such as - frame start (VSYNC), line flag and other status interrupts. + For VOP version under rk3576, the interrupt is shared by several interrupt + sources, such as frame start (VSYNC), line flag and other interrupt status. + For VOP version from rk3576 there is a system interrupt for bus error, and + every video port has it's independent interrupts for vsync and other video + port related error interrupts. + + interrupt-names: + items: + - const: sys + - const: vp0 + - const: vp1 + - const: vp2 # See compatible-specific constraints below. clocks: @@ -53,6 +66,8 @@ properties: - description: Pixel clock for video port 2. - description: Pixel clock for video port 3. - description: Peripheral(vop grf/dsi) clock. + - description: Alternative pixel clock provided by HDMI0 PHY PLL. + - description: Alternative pixel clock provided by HDMI1 PHY PLL. clock-names: minItems: 5 @@ -64,6 +79,8 @@ properties: - const: dclk_vp2 - const: dclk_vp3 - const: pclk_vop + - const: pll_hdmiphy0 + - const: pll_hdmiphy1 rockchip,grf: $ref: /schemas/types.yaml#/definitions/phandle @@ -120,43 +137,100 @@ allOf: properties: compatible: contains: - const: rockchip,rk3588-vop + enum: + - rockchip,rk3566-vop + - rockchip,rk3568-vop then: properties: clocks: - minItems: 7 + maxItems: 5 + clock-names: - minItems: 7 + maxItems: 5 + + interrupts: + maxItems: 1 + + interrupt-names: false ports: required: - port@0 - port@1 - port@2 - - port@3 + + rockchip,vo1-grf: false + rockchip,vop-grf: false + rockchip,pmu: false required: - rockchip,grf - - rockchip,vo1-grf - - rockchip,vop-grf - - rockchip,pmu - else: + - if: + properties: + compatible: + contains: + enum: + - rockchip,rk3576-vop + then: properties: + clocks: + maxItems: 5 + + clock-names: + maxItems: 5 + + interrupts: + minItems: 4 + + interrupt-names: + minItems: 4 + + ports: + required: + - port@0 + - port@1 + - port@2 + rockchip,vo1-grf: false rockchip,vop-grf: false - rockchip,pmu: false + required: + - rockchip,grf + - rockchip,pmu + + - if: + properties: + compatible: + contains: + const: rockchip,rk3588-vop + then: + properties: clocks: - maxItems: 5 + minItems: 7 + maxItems: 9 + clock-names: - maxItems: 5 + minItems: 7 + maxItems: 9 + + interrupts: + maxItems: 1 + + interrupt-names: false ports: required: - port@0 - port@1 - port@2 + - port@3 + + required: + - rockchip,grf + - rockchip,vo1-grf + - rockchip,vop-grf + - rockchip,pmu additionalProperties: false @@ -184,6 +258,7 @@ examples: "dclk_vp1", "dclk_vp2"; power-domains = <&power RK3568_PD_VO>; + rockchip,grf = <&grf>; iommus = <&vop_mmu>; vop_out: ports { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/dma/atmel,at91sam9g45-dma.yaml b/Documentation/devicetree/bindings/dma/atmel,at91sam9g45-dma.yaml new file mode 100644 index 000000000000..a58dc407311b --- /dev/null +++ b/Documentation/devicetree/bindings/dma/atmel,at91sam9g45-dma.yaml @@ -0,0 +1,68 @@ +# 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"; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/atmel,sama5d4-dma.yaml b/Documentation/devicetree/bindings/dma/atmel,sama5d4-dma.yaml index 9ca1c5d1f00f..73fc13b902b3 100644 --- a/Documentation/devicetree/bindings/dma/atmel,sama5d4-dma.yaml +++ b/Documentation/devicetree/bindings/dma/atmel,sama5d4-dma.yaml @@ -32,6 +32,9 @@ properties: - microchip,sam9x60-dma - microchip,sam9x7-dma - const: atmel,sama5d4-dma + - items: + - const: microchip,sama7d65-dma + - const: microchip,sama7g5-dma "#dma-cells": description: | diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt deleted file mode 100644 index f69bcf5a6343..000000000000 --- a/Documentation/devicetree/bindings/dma/atmel-dma.txt +++ /dev/null @@ -1,42 +0,0 @@ -* Atmel Direct Memory Access Controller (DMA) - -Required properties: -- compatible: Should be "atmel,<chip>-dma". -- reg: Should contain DMA registers location and length. -- interrupts: Should contain DMA interrupt. -- #dma-cells: Must be <2>, used to represent the number of integer cells in -the dmas property of client devices. - -Example: - -dma0: dma@ffffec00 { - compatible = "atmel,at91sam9g45-dma"; - reg = <0xffffec00 0x200>; - interrupts = <21>; - #dma-cells = <2>; -}; - -DMA clients connected to the Atmel DMA controller must use the format -described in the dma.txt file, using a three-cell specifier for each channel: -a phandle plus two integer cells. -The three cells in order are: - -1. A phandle pointing to the DMA controller. -2. The memory interface (16 most significant bits), the peripheral interface -(16 less significant bits). -3. Parameters for the at91 DMA configuration register which are device -dependent: - - bit 7-0: peripheral identifier for the hardware handshaking interface. The - identifier can be different for tx and rx. - - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 2 for ASAP. - -Example: - -i2c0@i2c@f8010000 { - compatible = "atmel,at91sam9x5-i2c"; - reg = <0xf8010000 0x100>; - interrupts = <9 4 6>; - dmas = <&dma0 1 7>, - <&dma0 1 8>; - dma-names = "tx", "rx"; -}; diff --git a/Documentation/devicetree/bindings/dma/fsl,edma.yaml b/Documentation/devicetree/bindings/dma/fsl,edma.yaml index 4f925469533e..950e8fa4f4ab 100644 --- a/Documentation/devicetree/bindings/dma/fsl,edma.yaml +++ b/Documentation/devicetree/bindings/dma/fsl,edma.yaml @@ -28,6 +28,14 @@ properties: - fsl,imx95-edma5 - nxp,s32g2-edma - items: + - enum: + - fsl,imx94-edma3 + - const: fsl,imx93-edma3 + - items: + - enum: + - fsl,imx94-edma5 + - const: fsl,imx95-edma5 + - items: - const: fsl,ls1028a-edma - const: fsl,vf610-edma - items: diff --git a/Documentation/devicetree/bindings/dma/fsl,elo-dma.yaml b/Documentation/devicetree/bindings/dma/fsl,elo-dma.yaml new file mode 100644 index 000000000000..92288d76d51b --- /dev/null +++ b/Documentation/devicetree/bindings/dma/fsl,elo-dma.yaml @@ -0,0 +1,137 @@ +# 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>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/fsl,elo3-dma.yaml b/Documentation/devicetree/bindings/dma/fsl,elo3-dma.yaml new file mode 100644 index 000000000000..0f5e475657a7 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/fsl,elo3-dma.yaml @@ -0,0 +1,125 @@ +# 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>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/fsl,eloplus-dma.yaml b/Documentation/devicetree/bindings/dma/fsl,eloplus-dma.yaml new file mode 100644 index 000000000000..8992f244c4db --- /dev/null +++ b/Documentation/devicetree/bindings/dma/fsl,eloplus-dma.yaml @@ -0,0 +1,132 @@ +# 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>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/fsl,mxs-dma.yaml b/Documentation/devicetree/bindings/dma/fsl,mxs-dma.yaml index a17cf2360dd4..75a7d9556699 100644 --- a/Documentation/devicetree/bindings/dma/fsl,mxs-dma.yaml +++ b/Documentation/devicetree/bindings/dma/fsl,mxs-dma.yaml @@ -31,6 +31,12 @@ properties: - fsl,imx6q-dma-apbh - fsl,imx6sx-dma-apbh - fsl,imx7d-dma-apbh + - fsl,imx8dxl-dma-apbh + - fsl,imx8mm-dma-apbh + - fsl,imx8mn-dma-apbh + - fsl,imx8mp-dma-apbh + - fsl,imx8mq-dma-apbh + - fsl,imx8qm-dma-apbh - fsl,imx8qxp-dma-apbh - const: fsl,imx28-dma-apbh - enum: diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml index 525f5f3932f5..935735a59afd 100644 --- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml @@ -59,6 +59,8 @@ properties: minimum: 1 maximum: 8 + dma-noncoherent: true + resets: minItems: 1 maxItems: 2 diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml index ab93ffd3d2e5..b8693e4b4b0d 100644 --- a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml +++ b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml @@ -82,6 +82,15 @@ properties: description: Phandle to syscon block which provide access for processor enablement + resets: + minItems: 1 + + reset-names: + minItems: 1 + items: + - const: runstall + - const: softreset + required: - compatible - reg @@ -164,6 +173,17 @@ allOf: - const: txdb1 - const: rxdb0 - const: rxdb1 + - if: + properties: + compatible: + contains: + enum: + - fsl,imx8mp-dsp + - fsl,imx8mp-hifi4 + then: + required: + - resets + - reset-names additionalProperties: false @@ -186,6 +206,7 @@ examples: }; - | #include <dt-bindings/clock/imx8mp-clock.h> + #include <dt-bindings/reset/imx8mp-reset-audiomix.h> dsp_reserved: dsp@92400000 { reg = <0x92400000 0x1000000>; no-map; @@ -220,5 +241,6 @@ examples: <&mu2 3 0>; memory-region = <&dsp_vdev0buffer>, <&dsp_vdev0vring0>, <&dsp_vdev0vring1>, <&dsp_reserved>; - fsl,dsp-ctrl = <&audio_blk_ctrl>; + resets = <&audio_blk_ctrl IMX8MP_AUDIOMIX_DSP_RUNSTALL>; + reset-names = "runstall"; }; diff --git a/Documentation/devicetree/bindings/dts-coding-style.rst b/Documentation/devicetree/bindings/dts-coding-style.rst index 4772ded8a987..202acac0507a 100644 --- a/Documentation/devicetree/bindings/dts-coding-style.rst +++ b/Documentation/devicetree/bindings/dts-coding-style.rst @@ -133,6 +133,9 @@ The above-described ordering follows this approach: 3. Status is the last information to annotate that device node is or is not finished (board resources are needed). +The individual properties inside each group shall use natural sort order by +the property name. + Example:: /* SoC DTSI */ @@ -158,7 +161,10 @@ Example:: /* Board DTS */ &device_node { - vdd-supply = <&board_vreg1>; + vdd-0v9-supply = <&board_vreg1>; + vdd-1v8-supply = <&board_vreg4>; + vdd-3v3-supply = <&board_vreg2>; + vdd-12v-supply = <&board_vreg3>; status = "okay"; } diff --git a/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml b/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml new file mode 100644 index 000000000000..ec4634c5fa89 --- /dev/null +++ b/Documentation/devicetree/bindings/edac/altr,socfpga-ecc-manager.yaml @@ -0,0 +1,323 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright (C) 2025 Altera Corporation +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/edac/altr,socfpga-ecc-manager.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Altera SoCFPGA ECC Manager + +maintainers: + - Matthew Gerlach <matthew.gerlach@altera.com> + +description: + This binding describes the device tree nodes required for the Altera SoCFPGA + ECC Manager for the Cyclone5, Arria5, Arria10, Stratix10, and Agilex chip + families. + +properties: + + compatible: + oneOf: + - items: + - const: altr,socfpga-s10-ecc-manager + - const: altr,socfpga-a10-ecc-manager + - const: altr,socfpga-a10-ecc-manager + - const: altr,socfpga-ecc-manager + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + ranges: true + + altr,sysmgr-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to Stratix10 System Manager Block with the ECC manager registers + + sdramedac: + type: object + additionalProperties: false + + properties: + compatible: + enum: + - altr,sdram-edac-a10 + - altr,sdram-edac-s10 + + interrupts: + minItems: 1 + maxItems: 2 + + altr,sdr-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to SDRAM parent + + required: + - compatible + - interrupts + - altr,sdr-syscon + +patternProperties: + "^ocram-ecc@[a-f0-9]+$": + type: object + additionalProperties: false + + properties: + compatible: + oneOf: + - items: + - const: altr,socfpga-s10-ocram-ecc + - const: altr,socfpga-a10-ocram-ecc + - const: altr,socfpga-a10-ocram-ecc + - const: altr,socfpga-ocram-ecc + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + + iram: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to OCRAM parent + + altr,ecc-parent: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to OCRAM parent + + required: + - compatible + - reg + - interrupts + + "^usb[0-9]-ecc@[a-f0-9]+$": + type: object + additionalProperties: false + + properties: + compatible: + oneOf: + - items: + - const: altr,socfpga-s10-usb-ecc + - const: altr,socfpga-usb-ecc + - const: altr,socfpga-usb-ecc + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + + altr,ecc-parent: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to USB parent + + required: + - compatible + - reg + - interrupts + - altr,ecc-parent + + "^emac[0-9]-[t,r]x-ecc@[a-f0-9]+$": + type: object + additionalProperties: false + + properties: + compatible: + oneOf: + - items: + - const: altr,socfpga-s10-eth-mac-ecc + - const: altr,socfpga-eth-mac-ecc + - const: altr,socfpga-eth-mac-ecc + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + + altr,ecc-parent: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to ethernet parent + + required: + - compatible + - reg + - interrupts + - altr,ecc-parent + + "^sdmmc[a-f]-ecc@[a-f0-9]+$": + type: object + additionalProperties: false + + properties: + compatible: + oneOf: + - items: + - const: altr,socfpga-s10-sdmmc-ecc + - const: altr,socfpga-sdmmc-ecc + - const: altr,socfpga-sdmmc-ecc + + reg: + maxItems: 1 + + interrupts: + minItems: 2 + maxItems: 4 + + altr,ecc-parent: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to SD/MMC parent + + required: + - compatible + - reg + - interrupts + - altr,ecc-parent + + "^l2-ecc@[a-f0-9]+$": + type: object + additionalProperties: false + + properties: + compatible: + enum: + - altr,socfpga-a10-l2-ecc + - altr,socfpga-l2-ecc + + reg: + maxItems: 1 + + interrupts: + maxItems: 2 + + required: + - compatible + - reg + - interrupts + + "^dma-ecc@[a-f0-9]+$": + type: object + additionalProperties: false + + properties: + compatible: + const: altr,socfpga-dma-ecc + reg: + maxItems: 1 + + interrupts: + maxItems: 2 + + altr,ecc-parent: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to SD/MMC parent + + required: + - compatible + - reg + - interrupts + - altr,ecc-parent + +if: + properties: + compatible: + contains: + const: altr,socfpga-ecc-manager +then: + required: + - compatible + - "#address-cells" + - "#size-cells" + - ranges + +else: + required: + - compatible + - "#address-cells" + - "#size-cells" + - interrupts + - interrupt-controller + - "#interrupt-cells" + - ranges + - altr,sysmgr-syscon + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + eccmgr { + compatible = "altr,socfpga-s10-ecc-manager", + "altr,socfpga-a10-ecc-manager"; + altr,sysmgr-syscon = <&sysmgr>; + #address-cells = <1>; + #size-cells = <1>; + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <2>; + ranges; + + sdramedac { + compatible = "altr,sdram-edac-s10"; + altr,sdr-syscon = <&sdr>; + interrupts = <16 IRQ_TYPE_LEVEL_HIGH>; + }; + + ocram-ecc@ff8cc000 { + compatible = "altr,socfpga-s10-ocram-ecc", + "altr,socfpga-a10-ocram-ecc"; + reg = <0xff8cc000 0x100>; + altr,ecc-parent = <&ocram>; + interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; + }; + + usb0-ecc@ff8c4000 { + compatible = "altr,socfpga-s10-usb-ecc", + "altr,socfpga-usb-ecc"; + reg = <0xff8c4000 0x100>; + altr,ecc-parent = <&usb0>; + interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; + }; + + emac0-rx-ecc@ff8c0000 { + compatible = "altr,socfpga-s10-eth-mac-ecc", + "altr,socfpga-eth-mac-ecc"; + reg = <0xff8c0000 0x100>; + altr,ecc-parent = <&gmac0>; + interrupts = <4 IRQ_TYPE_LEVEL_HIGH>; + }; + + emac0-tx-ecc@ff8c0400 { + compatible = "altr,socfpga-s10-eth-mac-ecc", + "altr,socfpga-eth-mac-ecc"; + reg = <0xff8c0400 0x100>; + altr,ecc-parent = <&gmac0>; + interrupts = <5 IRQ_TYPE_LEVEL_HIGH>; + }; + + sdmmca-ecc@ff8c8c00 { + compatible = "altr,socfpga-s10-sdmmc-ecc", + "altr,socfpga-sdmmc-ecc"; + reg = <0xff8c8c00 0x100>; + altr,ecc-parent = <&mmc>; + interrupts = <14 IRQ_TYPE_LEVEL_HIGH>, + <15 IRQ_TYPE_LEVEL_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt b/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt deleted file mode 100644 index 8f52206cfd2a..000000000000 --- a/Documentation/devicetree/bindings/edac/socfpga-eccmgr.txt +++ /dev/null @@ -1,383 +0,0 @@ -Altera SoCFPGA ECC Manager -This driver uses the EDAC framework to implement the SOCFPGA ECC Manager. -The ECC Manager counts and corrects single bit errors and counts/handles -double bit errors which are uncorrectable. - -Cyclone5 and Arria5 ECC Manager -Required Properties: -- compatible : Should be "altr,socfpga-ecc-manager" -- #address-cells: must be 1 -- #size-cells: must be 1 -- ranges : standard definition, should translate from local addresses - -Subcomponents: - -L2 Cache ECC -Required Properties: -- compatible : Should be "altr,socfpga-l2-ecc" -- reg : Address and size for ECC error interrupt clear registers. -- interrupts : Should be single bit error interrupt, then double bit error - interrupt. Note the rising edge type. - -On Chip RAM ECC -Required Properties: -- compatible : Should be "altr,socfpga-ocram-ecc" -- reg : Address and size for ECC error interrupt clear registers. -- iram : phandle to On-Chip RAM definition. -- interrupts : Should be single bit error interrupt, then double bit error - interrupt. Note the rising edge type. - -Example: - - eccmgr: eccmgr@ffd08140 { - compatible = "altr,socfpga-ecc-manager"; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - l2-ecc@ffd08140 { - compatible = "altr,socfpga-l2-ecc"; - reg = <0xffd08140 0x4>; - interrupts = <0 36 1>, <0 37 1>; - }; - - ocram-ecc@ffd08144 { - compatible = "altr,socfpga-ocram-ecc"; - reg = <0xffd08144 0x4>; - iram = <&ocram>; - interrupts = <0 178 1>, <0 179 1>; - }; - }; - -Arria10 SoCFPGA ECC Manager -The Arria10 SoC ECC Manager handles the IRQs for each peripheral -in a shared register instead of individual IRQs like the Cyclone5 -and Arria5. Therefore the device tree is different as well. - -Required Properties: -- compatible : Should be "altr,socfpga-a10-ecc-manager" -- altr,sysgr-syscon : phandle to Arria10 System Manager Block - containing the ECC manager registers. -- #address-cells: must be 1 -- #size-cells: must be 1 -- interrupts : Should be single bit error interrupt, then double bit error - interrupt. -- interrupt-controller : boolean indicator that ECC Manager is an interrupt controller -- #interrupt-cells : must be set to 2. -- ranges : standard definition, should translate from local addresses - -Subcomponents: - -L2 Cache ECC -Required Properties: -- compatible : Should be "altr,socfpga-a10-l2-ecc" -- reg : Address and size for ECC error interrupt clear registers. -- interrupts : Should be single bit error interrupt, then double bit error - interrupt, in this order. - -On-Chip RAM ECC -Required Properties: -- compatible : Should be "altr,socfpga-a10-ocram-ecc" -- reg : Address and size for ECC block registers. -- interrupts : Should be single bit error interrupt, then double bit error - interrupt, in this order. - -Ethernet FIFO ECC -Required Properties: -- compatible : Should be "altr,socfpga-eth-mac-ecc" -- reg : Address and size for ECC block registers. -- altr,ecc-parent : phandle to parent Ethernet node. -- interrupts : Should be single bit error interrupt, then double bit error - interrupt, in this order. - -NAND FIFO ECC -Required Properties: -- compatible : Should be "altr,socfpga-nand-ecc" -- reg : Address and size for ECC block registers. -- altr,ecc-parent : phandle to parent NAND node. -- interrupts : Should be single bit error interrupt, then double bit error - interrupt, in this order. - -DMA FIFO ECC -Required Properties: -- compatible : Should be "altr,socfpga-dma-ecc" -- reg : Address and size for ECC block registers. -- altr,ecc-parent : phandle to parent DMA node. -- interrupts : Should be single bit error interrupt, then double bit error - interrupt, in this order. - -USB FIFO ECC -Required Properties: -- compatible : Should be "altr,socfpga-usb-ecc" -- reg : Address and size for ECC block registers. -- altr,ecc-parent : phandle to parent USB node. -- interrupts : Should be single bit error interrupt, then double bit error - interrupt, in this order. - -QSPI FIFO ECC -Required Properties: -- compatible : Should be "altr,socfpga-qspi-ecc" -- reg : Address and size for ECC block registers. -- altr,ecc-parent : phandle to parent QSPI node. -- interrupts : Should be single bit error interrupt, then double bit error - interrupt, in this order. - -SDMMC FIFO ECC -Required Properties: -- compatible : Should be "altr,socfpga-sdmmc-ecc" -- reg : Address and size for ECC block registers. -- altr,ecc-parent : phandle to parent SD/MMC node. -- interrupts : Should be single bit error interrupt, then double bit error - interrupt, in this order for port A, and then single bit error interrupt, - then double bit error interrupt in this order for port B. - -Example: - - eccmgr: eccmgr@ffd06000 { - compatible = "altr,socfpga-a10-ecc-manager"; - altr,sysmgr-syscon = <&sysmgr>; - #address-cells = <1>; - #size-cells = <1>; - interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>, - <0 0 IRQ_TYPE_LEVEL_HIGH>; - interrupt-controller; - #interrupt-cells = <2>; - ranges; - - l2-ecc@ffd06010 { - compatible = "altr,socfpga-a10-l2-ecc"; - reg = <0xffd06010 0x4>; - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>, - <32 IRQ_TYPE_LEVEL_HIGH>; - }; - - ocram-ecc@ff8c3000 { - compatible = "altr,socfpga-a10-ocram-ecc"; - reg = <0xff8c3000 0x90>; - interrupts = <1 IRQ_TYPE_LEVEL_HIGH>, - <33 IRQ_TYPE_LEVEL_HIGH> ; - }; - - emac0-rx-ecc@ff8c0800 { - compatible = "altr,socfpga-eth-mac-ecc"; - reg = <0xff8c0800 0x400>; - altr,ecc-parent = <&gmac0>; - interrupts = <4 IRQ_TYPE_LEVEL_HIGH>, - <36 IRQ_TYPE_LEVEL_HIGH>; - }; - - emac0-tx-ecc@ff8c0c00 { - compatible = "altr,socfpga-eth-mac-ecc"; - reg = <0xff8c0c00 0x400>; - altr,ecc-parent = <&gmac0>; - interrupts = <5 IRQ_TYPE_LEVEL_HIGH>, - <37 IRQ_TYPE_LEVEL_HIGH>; - }; - - nand-buf-ecc@ff8c2000 { - compatible = "altr,socfpga-nand-ecc"; - reg = <0xff8c2000 0x400>; - altr,ecc-parent = <&nand>; - interrupts = <11 IRQ_TYPE_LEVEL_HIGH>, - <43 IRQ_TYPE_LEVEL_HIGH>; - }; - - nand-rd-ecc@ff8c2400 { - compatible = "altr,socfpga-nand-ecc"; - reg = <0xff8c2400 0x400>; - altr,ecc-parent = <&nand>; - interrupts = <13 IRQ_TYPE_LEVEL_HIGH>, - <45 IRQ_TYPE_LEVEL_HIGH>; - }; - - nand-wr-ecc@ff8c2800 { - compatible = "altr,socfpga-nand-ecc"; - reg = <0xff8c2800 0x400>; - altr,ecc-parent = <&nand>; - interrupts = <12 IRQ_TYPE_LEVEL_HIGH>, - <44 IRQ_TYPE_LEVEL_HIGH>; - }; - - dma-ecc@ff8c8000 { - compatible = "altr,socfpga-dma-ecc"; - reg = <0xff8c8000 0x400>; - altr,ecc-parent = <&pdma>; - interrupts = <10 IRQ_TYPE_LEVEL_HIGH>, - <42 IRQ_TYPE_LEVEL_HIGH>; - - usb0-ecc@ff8c8800 { - compatible = "altr,socfpga-usb-ecc"; - reg = <0xff8c8800 0x400>; - altr,ecc-parent = <&usb0>; - interrupts = <2 IRQ_TYPE_LEVEL_HIGH>, - <34 IRQ_TYPE_LEVEL_HIGH>; - }; - - qspi-ecc@ff8c8400 { - compatible = "altr,socfpga-qspi-ecc"; - reg = <0xff8c8400 0x400>; - altr,ecc-parent = <&qspi>; - interrupts = <14 IRQ_TYPE_LEVEL_HIGH>, - <46 IRQ_TYPE_LEVEL_HIGH>; - }; - - sdmmc-ecc@ff8c2c00 { - compatible = "altr,socfpga-sdmmc-ecc"; - reg = <0xff8c2c00 0x400>; - altr,ecc-parent = <&mmc>; - interrupts = <15 IRQ_TYPE_LEVEL_HIGH>, - <47 IRQ_TYPE_LEVEL_HIGH>, - <16 IRQ_TYPE_LEVEL_HIGH>, - <48 IRQ_TYPE_LEVEL_HIGH>; - }; - }; - -Stratix10 SoCFPGA ECC Manager (ARM64) -The Stratix10 SoC ECC Manager handles the IRQs for each peripheral -in a shared register similar to the Arria10. However, Stratix10 ECC -requires access to registers that can only be read from Secure Monitor -with SMC calls. Therefore the device tree is slightly different. Note -that only 1 interrupt is sent in Stratix10 because the double bit errors -are treated as SErrors in ARM64 instead of IRQs in ARM32. - -Required Properties: -- compatible : Should be "altr,socfpga-s10-ecc-manager" -- altr,sysgr-syscon : phandle to Stratix10 System Manager Block - containing the ECC manager registers. -- interrupts : Should be single bit error interrupt. -- interrupt-controller : boolean indicator that ECC Manager is an interrupt controller -- #interrupt-cells : must be set to 2. -- #address-cells: must be 1 -- #size-cells: must be 1 -- ranges : standard definition, should translate from local addresses - -Subcomponents: - -SDRAM ECC -Required Properties: -- compatible : Should be "altr,sdram-edac-s10" -- interrupts : Should be single bit error interrupt. - -On-Chip RAM ECC -Required Properties: -- compatible : Should be "altr,socfpga-s10-ocram-ecc" -- reg : Address and size for ECC block registers. -- altr,ecc-parent : phandle to parent OCRAM node. -- interrupts : Should be single bit error interrupt. - -Ethernet FIFO ECC -Required Properties: -- compatible : Should be "altr,socfpga-s10-eth-mac-ecc" -- reg : Address and size for ECC block registers. -- altr,ecc-parent : phandle to parent Ethernet node. -- interrupts : Should be single bit error interrupt. - -NAND FIFO ECC -Required Properties: -- compatible : Should be "altr,socfpga-s10-nand-ecc" -- reg : Address and size for ECC block registers. -- altr,ecc-parent : phandle to parent NAND node. -- interrupts : Should be single bit error interrupt. - -DMA FIFO ECC -Required Properties: -- compatible : Should be "altr,socfpga-s10-dma-ecc" -- reg : Address and size for ECC block registers. -- altr,ecc-parent : phandle to parent DMA node. -- interrupts : Should be single bit error interrupt. - -USB FIFO ECC -Required Properties: -- compatible : Should be "altr,socfpga-s10-usb-ecc" -- reg : Address and size for ECC block registers. -- altr,ecc-parent : phandle to parent USB node. -- interrupts : Should be single bit error interrupt. - -SDMMC FIFO ECC -Required Properties: -- compatible : Should be "altr,socfpga-s10-sdmmc-ecc" -- reg : Address and size for ECC block registers. -- altr,ecc-parent : phandle to parent SD/MMC node. -- interrupts : Should be single bit error interrupt for port A - and then single bit error interrupt for port B. - -Example: - - eccmgr { - compatible = "altr,socfpga-s10-ecc-manager"; - altr,sysmgr-syscon = <&sysmgr>; - #address-cells = <1>; - #size-cells = <1>; - interrupts = <0 15 4>; - interrupt-controller; - #interrupt-cells = <2>; - ranges; - - sdramedac { - compatible = "altr,sdram-edac-s10"; - interrupts = <16 IRQ_TYPE_LEVEL_HIGH>; - }; - - ocram-ecc@ff8cc000 { - compatible = "altr,socfpga-s10-ocram-ecc"; - reg = <ff8cc000 0x100>; - altr,ecc-parent = <&ocram>; - interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; - }; - - emac0-rx-ecc@ff8c0000 { - compatible = "altr,socfpga-s10-eth-mac-ecc"; - reg = <0xff8c0000 0x100>; - altr,ecc-parent = <&gmac0>; - interrupts = <4 IRQ_TYPE_LEVEL_HIGH>; - }; - - emac0-tx-ecc@ff8c0400 { - compatible = "altr,socfpga-s10-eth-mac-ecc"; - reg = <0xff8c0400 0x100>; - altr,ecc-parent = <&gmac0>; - interrupts = <5 IRQ_TYPE_LEVEL_HIGH>' - }; - - nand-buf-ecc@ff8c8000 { - compatible = "altr,socfpga-s10-nand-ecc"; - reg = <0xff8c8000 0x100>; - altr,ecc-parent = <&nand>; - interrupts = <11 IRQ_TYPE_LEVEL_HIGH>; - }; - - nand-rd-ecc@ff8c8400 { - compatible = "altr,socfpga-s10-nand-ecc"; - reg = <0xff8c8400 0x100>; - altr,ecc-parent = <&nand>; - interrupts = <13 IRQ_TYPE_LEVEL_HIGH>; - }; - - nand-wr-ecc@ff8c8800 { - compatible = "altr,socfpga-s10-nand-ecc"; - reg = <0xff8c8800 0x100>; - altr,ecc-parent = <&nand>; - interrupts = <12 IRQ_TYPE_LEVEL_HIGH>; - }; - - dma-ecc@ff8c9000 { - compatible = "altr,socfpga-s10-dma-ecc"; - reg = <0xff8c9000 0x100>; - altr,ecc-parent = <&pdma>; - interrupts = <10 IRQ_TYPE_LEVEL_HIGH>; - - usb0-ecc@ff8c4000 { - compatible = "altr,socfpga-s10-usb-ecc"; - reg = <0xff8c4000 0x100>; - altr,ecc-parent = <&usb0>; - interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; - }; - - sdmmc-ecc@ff8c8c00 { - compatible = "altr,socfpga-s10-sdmmc-ecc"; - reg = <0xff8c8c00 0x100>; - altr,ecc-parent = <&mmc>; - interrupts = <14 IRQ_TYPE_LEVEL_HIGH>, - <15 IRQ_TYPE_LEVEL_HIGH>; - }; - }; diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml index c9e4afbdc448..0ac68646c077 100644 --- a/Documentation/devicetree/bindings/eeprom/at24.yaml +++ b/Documentation/devicetree/bindings/eeprom/at24.yaml @@ -130,10 +130,13 @@ properties: - const: giantec,gt24c32a - const: atmel,24c32 - items: - - const: onnn,n24s64b + - enum: + - onnn,n24s64b + - puya,p24c64f - const: atmel,24c64 - items: - enum: + - giantec,gt24p128e - giantec,gt24p128f - renesas,r1ex24128 - samsung,s524ad0xd1 diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-scom.yaml b/Documentation/devicetree/bindings/fsi/ibm,p9-scom.yaml index 8cd14a70bedf..b106f5212ea9 100644 --- a/Documentation/devicetree/bindings/fsi/ibm,p9-scom.yaml +++ b/Documentation/devicetree/bindings/fsi/ibm,p9-scom.yaml @@ -16,6 +16,7 @@ description: properties: compatible: enum: + - ibm,fsi2pib - ibm,p9-scom - ibm,i2cr-scom diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 735c7f06c24e..019bd28a29f1 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -17,6 +17,7 @@ properties: oneOf: - items: - enum: + - allwinner,sun50i-h616-mali - amlogic,meson-g12a-mali - mediatek,mt8183-mali - mediatek,mt8183b-mali @@ -24,7 +25,9 @@ properties: - realtek,rtd1619-mali - renesas,r9a07g044-mali - renesas,r9a07g054-mali + - renesas,r9a09g057-mali - rockchip,px30-mali + - rockchip,rk3562-mali - rockchip,rk3568-mali - rockchip,rk3576-mali - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable @@ -142,6 +145,7 @@ allOf: enum: - renesas,r9a07g044-mali - renesas,r9a07g054-mali + - renesas,r9a09g057-mali then: properties: interrupts: diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml index 0801da33a385..48daba21a890 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml @@ -47,10 +47,13 @@ properties: - const: arm,mali-t760 - items: - enum: + - samsung,exynos7870-mali + - const: arm,mali-t830 + - items: + - enum: - rockchip,rk3399-mali - const: arm,mali-t860 - # "arm,mali-t830" # "arm,mali-t880" reg: diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml index 70cc2ee9ee27..8d47b290b4ed 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml @@ -30,6 +30,7 @@ properties: - items: - enum: - samsung,exynos5433-hsi2c + - samsung,exynos7870-hsi2c - tesla,fsd-hsi2c - const: samsung,exynos7-hsi2c - items: diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml index 1dcb9c78de3b..969030a6f82a 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml @@ -26,6 +26,7 @@ properties: - fsl,imx8qm-lpi2c - fsl,imx8ulp-lpi2c - fsl,imx93-lpi2c + - fsl,imx94-lpi2c - fsl,imx95-lpi2c - const: fsl,imx7ulp-lpi2c diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml index a9dae5b52f28..8101afa6f146 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml @@ -37,6 +37,7 @@ properties: - rockchip,px30-i2c - rockchip,rk3308-i2c - rockchip,rk3328-i2c + - rockchip,rk3562-i2c - rockchip,rk3568-i2c - rockchip,rk3576-i2c - rockchip,rk3588-i2c diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml index f43947514d48..758d8f6321e1 100644 --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.yaml @@ -40,6 +40,9 @@ properties: - const: tx - const: rx + interconnects: + maxItems: 1 + interrupts: maxItems: 1 @@ -52,9 +55,15 @@ properties: - const: default - const: sleep + power-domains: + maxItems: 1 + reg: maxItems: 1 + required-opps: + maxItems: 1 + required: - compatible - clock-names @@ -67,7 +76,9 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/clock/qcom,gcc-msm8998.h> + #include <dt-bindings/interconnect/qcom,msm8996.h> #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> i2c@c175000 { compatible = "qcom,i2c-qup-v2.2.1"; @@ -82,6 +93,9 @@ examples: pinctrl-names = "default", "sleep"; pinctrl-0 = <&blsp1_i2c1_default>; pinctrl-1 = <&blsp1_i2c1_sleep>; + power-domains = <&rpmpd MSM8909_VDDCX>; + required-opps = <&rpmpd_opp_svs_krait>; + interconnects = <&pnoc MASTER_BLSP_1 &bimc SLAVE_EBI_CH0>; clock-frequency = <400000>; #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml index bbc568485627..6ba7d793504c 100644 --- a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml @@ -22,6 +22,7 @@ properties: - samsung,exynos5-sata-phy-i2c - items: - enum: + - samsung,exynos7870-i2c - samsung,exynos7885-i2c - samsung,exynos850-i2c - const: samsung,s3c2440-i2c diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml index e5d05263c45a..bc5d0fb5abfe 100644 --- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml @@ -27,6 +27,11 @@ properties: oneOf: - description: Generic Synopsys DesignWare I2C controller const: snps,designware-i2c + - description: Renesas RZ/N1D I2C controller + items: + - const: renesas,r9a06g032-i2c # RZ/N1D + - const: renesas,rzn1-i2c # RZ/N1 + - const: snps,designware-i2c - description: Microsemi Ocelot SoCs I2C controller items: - const: mscc,ocelot-i2c diff --git a/Documentation/devicetree/bindings/i2c/spacemit,k1-i2c.yaml b/Documentation/devicetree/bindings/i2c/spacemit,k1-i2c.yaml new file mode 100644 index 000000000000..3d6aefb0d0f1 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/spacemit,k1-i2c.yaml @@ -0,0 +1,61 @@ +# 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>; + }; + +... diff --git a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml index 8c2e35fabf5b..58d32ceeacfc 100644 --- a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml @@ -47,6 +47,11 @@ properties: $ref: /schemas/types.yaml#/definitions/string deprecated: true + mux-states: + description: + mux controller node to route the I2C signals from SoC to clients. + maxItems: 1 + required: - compatible - reg @@ -87,4 +92,5 @@ examples: interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>; #address-cells = <1>; #size-cells = <0>; + mux-states = <&i2c_mux 1>; }; diff --git a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml index c56ff77677f1..4fbdcdac0aee 100644 --- a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml +++ b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml @@ -14,7 +14,9 @@ allOf: properties: compatible: - const: silvaco,i3c-master-v1 + enum: + - nuvoton,npcm845-i3c + - silvaco,i3c-master-v1 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml index 4fc13e3c0f75..5f6467375811 100644 --- a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml +++ b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml @@ -34,6 +34,9 @@ properties: interrupts: maxItems: 1 + power-domains: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml new file mode 100644 index 000000000000..54e7349317b7 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4030.yaml @@ -0,0 +1,110 @@ +# 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>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml index 7d2229dee444..cbde7a0505d2 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4695.yaml @@ -84,6 +84,10 @@ properties: description: The Reset Input (RESET). Should be configured GPIO_ACTIVE_LOW. maxItems: 1 + pwms: + description: PWM signal connected to the CNV pin. + maxItems: 1 + interrupts: minItems: 1 items: @@ -106,6 +110,15 @@ properties: The first cell is the GPn number: 0 to 3. The second cell takes standard GPIO flags. + '#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 + "#address-cells": const: 1 diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4851.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4851.yaml new file mode 100644 index 000000000000..c6676d91b4e6 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4851.yaml @@ -0,0 +1,153 @@ +# 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>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7191.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7191.yaml new file mode 100644 index 000000000000..801ed319ee82 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7191.yaml @@ -0,0 +1,149 @@ +# 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>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml index ada08005b3cd..ff4f5c21c548 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml @@ -27,6 +27,7 @@ description: | * https://www.analog.com/en/products/ad7388-4.html * https://www.analog.com/en/products/adaq4370-4.html * https://www.analog.com/en/products/adaq4380-4.html + * https://www.analog.com/en/products/adaq4381-4.html $ref: /schemas/spi/spi-peripheral-props.yaml# @@ -50,6 +51,7 @@ properties: - adi,ad7388-4 - adi,adaq4370-4 - adi,adaq4380-4 + - adi,adaq4381-4 reg: maxItems: 1 @@ -201,6 +203,7 @@ allOf: - adi,ad7380-4 - adi,adaq4370-4 - adi,adaq4380-4 + - adi,adaq4381-4 then: properties: refio-supply: false @@ -218,6 +221,7 @@ allOf: enum: - adi,adaq4370-4 - adi,adaq4380-4 + - adi,adaq4381-4 then: required: - vs-p-supply diff --git a/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml b/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml index e1f450b80db2..cf74f84d6103 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml @@ -17,13 +17,25 @@ description: | interface for the actual ADC, while this IP core will interface to the data-lines of the ADC and handle the streaming of data into memory via DMA. + 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://wiki.analog.com/resources/fpga/docs/axi_adc_ip + https://analogdevicesinc.github.io/hdl/library/axi_ad485x/index.html + http://analogdevicesinc.github.io/hdl/library/axi_ad7606x/index.html properties: compatible: enum: - adi,axi-adc-10.0.a + - adi,axi-ad7606x + - adi,axi-ad485x reg: maxItems: 1 @@ -47,17 +59,48 @@ properties: '#io-backend-cells': const: 0 + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + "^adc@[0-9a-f]+$": + type: object + properties: + reg: + maxItems: 1 + additionalProperties: true + required: + - compatible + - reg + required: - compatible - dmas - reg - clocks +allOf: + - if: + properties: + compatible: + not: + contains: + const: adi,axi-ad7606x + then: + properties: + '#address-cells': false + '#size-cells': false + patternProperties: + "^adc@[0-9a-f]+$": false + additionalProperties: false examples: - | - axi-adc@44a00000 { + adc@44a00000 { compatible = "adi,axi-adc-10.0.a"; reg = <0x44a00000 0x10000>; dmas = <&rx_dma 0>; @@ -65,4 +108,31 @@ examples: clocks = <&axi_clk>; #io-backend-cells = <0>; }; + - | + #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 = <¶llel_bus_controller>; + }; + }; ... diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml index dfc3f512918f..c2e5ff418920 100644 --- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml @@ -19,7 +19,14 @@ description: properties: compatible: - const: nxp,imx93-adc + oneOf: + - enum: + - nxp,imx93-adc + - items: + - enum: + - nxp,imx94-adc + - nxp,imx95-adc + - const: nxp,imx93-adc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml index fd93ed3991e0..41e0c56ef8e3 100644 --- a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.yaml @@ -15,6 +15,8 @@ properties: - const: rockchip,saradc - const: rockchip,rk3066-tsadc - const: rockchip,rk3399-saradc + - const: rockchip,rk3528-saradc + - const: rockchip,rk3562-saradc - const: rockchip,rk3588-saradc - items: - const: rockchip,rk3576-saradc diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads7138.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads7138.yaml new file mode 100644 index 000000000000..a51893e207d4 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads7138.yaml @@ -0,0 +1,63 @@ +# 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 = <®_stb_3v3>; + interrupt-parent = <&gpio2>; + interrupts = <12 IRQ_TYPE_LEVEL_LOW>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml index 9eb9928500e2..3e323f1a5458 100644 --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5380.yaml @@ -55,18 +55,18 @@ examples: #address-cells = <1>; #size-cells = <0>; dac@0 { - reg = <0>; - compatible = "adi,ad5390-5"; - vref-supply = <&dacvref>; + reg = <0>; + compatible = "adi,ad5390-5"; + vref-supply = <&dacvref>; }; }; - | i2c { - #address-cells = <1>; - #size-cells = <0>; - dac@42 { - reg = <0x42>; - compatible = "adi,ad5380-3"; - }; + #address-cells = <1>; + #size-cells = <0>; + dac@42 { + reg = <0x42>; + compatible = "adi,ad5380-3"; + }; }; ... diff --git a/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml b/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml index 1cb2adaf66f9..53d607441612 100644 --- a/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml +++ b/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml @@ -30,8 +30,9 @@ properties: clock-names: description: - Must be "clkin" - maxItems: 1 + Must be "clkin" if the input reference is single ended or "clkin-diff" + if the input reference is differential. + enum: [clkin, clkin-diff] adi,mute-till-lock-en: type: boolean diff --git a/Documentation/devicetree/bindings/iio/humidity/sciosense,ens210.yaml b/Documentation/devicetree/bindings/iio/humidity/sciosense,ens210.yaml index ed0ea938f7f8..1e25cf781cf1 100644 --- a/Documentation/devicetree/bindings/iio/humidity/sciosense,ens210.yaml +++ b/Documentation/devicetree/bindings/iio/humidity/sciosense,ens210.yaml @@ -43,13 +43,13 @@ additionalProperties: false examples: - | i2c { - #address-cells = <1>; - #size-cells = <0>; + #address-cells = <1>; + #size-cells = <0>; - temperature-sensor@43 { - compatible = "sciosense,ens210"; - reg = <0x43>; - }; + temperature-sensor@43 { + compatible = "sciosense,ens210"; + reg = <0x43>; + }; }; ... diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16550.yaml b/Documentation/devicetree/bindings/iio/imu/adi,adis16550.yaml new file mode 100644 index 000000000000..a4c273c7a67f --- /dev/null +++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16550.yaml @@ -0,0 +1,74 @@ +# 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>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/light/brcm,apds9160.yaml b/Documentation/devicetree/bindings/iio/light/brcm,apds9160.yaml new file mode 100644 index 000000000000..bb1cc4404a55 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/brcm,apds9160.yaml @@ -0,0 +1,78 @@ +# 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>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml b/Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml index a3a979553e32..f1048c30e73e 100644 --- a/Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml +++ b/Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml @@ -4,14 +4,16 @@ $id: http://devicetree.org/schemas/iio/light/dynaimage,al3010.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Dyna-Image AL3010 sensor +title: Dyna-Image AL3000a/AL3010 sensor maintainers: - David Heidelberg <david@ixit.cz> properties: compatible: - const: dynaimage,al3010 + enum: + - dynaimage,al3000a + - dynaimage,al3010 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/magnetometer/silabs,si7210.yaml b/Documentation/devicetree/bindings/iio/magnetometer/silabs,si7210.yaml new file mode 100644 index 000000000000..d4a3f7981c36 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/magnetometer/silabs,si7210.yaml @@ -0,0 +1,48 @@ +# 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>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml b/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml index 7cc365e0ebc8..7c0c6ab6fc69 100644 --- a/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml +++ b/Documentation/devicetree/bindings/iio/temperature/maxim,max31865.yaml @@ -40,15 +40,15 @@ unevaluatedProperties: false examples: - | spi { - #address-cells = <1>; - #size-cells = <0>; - - temperature-sensor@0 { - compatible = "maxim,max31865"; - reg = <0>; - spi-max-frequency = <400000>; - spi-cpha; - maxim,3-wire; - }; + #address-cells = <1>; + #size-cells = <0>; + + temperature-sensor@0 { + compatible = "maxim,max31865"; + reg = <0>; + spi-max-frequency = <400000>; + spi-cpha; + maxim,3-wire; + }; }; ... diff --git a/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml b/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml index 58aa1542776b..fbba5e934861 100644 --- a/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml +++ b/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml @@ -44,8 +44,8 @@ examples: #size-cells = <0>; tmp117@48 { - compatible = "ti,tmp117"; - reg = <0x48>; - vcc-supply = <&pmic_reg_3v3>; + compatible = "ti,tmp117"; + reg = <0x48>; + vcc-supply = <&pmic_reg_3v3>; }; }; diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt deleted file mode 100644 index 570dc10f0cd7..000000000000 --- a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt +++ /dev/null @@ -1,49 +0,0 @@ -* GPIO driven matrix keypad device tree bindings - -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. - -Required Properties: -- compatible: Should be "gpio-matrix-keypad" -- row-gpios: 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: 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: The definition can be found at - bindings/input/matrix-keymap.txt - -Optional Properties: -- linux,no-autorepeat: do no enable autorepeat feature. -- wakeup-source: use any event on keypad as wakeup event. - (Legacy property supported: "linux,wakeup") -- debounce-delay-ms: debounce interval in milliseconds -- col-scan-delay-us: delay, measured in microseconds, that is needed - before we can scan keypad after activating column gpio -- drive-inactive-cols: drive inactive columns during scan, - default is to turn inactive columns into inputs. - -Example: - 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>; - }; diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml new file mode 100644 index 000000000000..ebfff9e42a36 --- /dev/null +++ b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml @@ -0,0 +1,103 @@ +# 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; + }; diff --git a/Documentation/devicetree/bindings/input/qcom,pm8921-keypad.yaml b/Documentation/devicetree/bindings/input/qcom,pm8921-keypad.yaml index 88764adcd696..e03611eef93d 100644 --- a/Documentation/devicetree/bindings/input/qcom,pm8921-keypad.yaml +++ b/Documentation/devicetree/bindings/input/qcom,pm8921-keypad.yaml @@ -62,28 +62,28 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/input/input.h> - #include <dt-bindings/interrupt-controller/irq.h> - pmic { - #address-cells = <1>; - #size-cells = <0>; + #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>; - }; - }; + 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>; + }; + }; ... diff --git a/Documentation/devicetree/bindings/input/qcom,pm8921-pwrkey.yaml b/Documentation/devicetree/bindings/input/qcom,pm8921-pwrkey.yaml index 12c74c083258..64590894857a 100644 --- a/Documentation/devicetree/bindings/input/qcom,pm8921-pwrkey.yaml +++ b/Documentation/devicetree/bindings/input/qcom,pm8921-pwrkey.yaml @@ -52,24 +52,24 @@ unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/irq.h> - ssbi { - #address-cells = <1>; - #size-cells = <0>; + #include <dt-bindings/interrupt-controller/irq.h> + ssbi { + #address-cells = <1>; + #size-cells = <0>; - pmic@0 { - reg = <0x0>; - #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; - }; - }; - }; + 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; + }; + }; + }; ... diff --git a/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml b/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml new file mode 100644 index 000000000000..402ca6bffd34 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml @@ -0,0 +1,70 @@ +# 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>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml index d90f045ac06c..c40d92b7f4af 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix,gt9916.yaml @@ -19,6 +19,7 @@ allOf: properties: compatible: enum: + - goodix,gt9897 - goodix,gt9916 reg: diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml b/Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml index 604921733d2c..8f6335d7da1c 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml @@ -164,20 +164,20 @@ examples: #size-cells = <0>; touchscreen@0 { - 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 = <®_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>; - }; + 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 = <®_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>; + }; }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2712-msix.yaml b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2712-msix.yaml new file mode 100644 index 000000000000..c84614663b5d --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2712-msix.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/brcm,bcm2712-msix.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom bcm2712 MSI-X Interrupt Peripheral support + +maintainers: + - Stanimir Varbanov <svarbanov@suse.de> + +description: + This interrupt controller is used to provide interrupt vectors to the + generic interrupt controller (GIC) on bcm2712. It will be used as + external MSI-X controller for PCIe root complex. + +allOf: + - $ref: /schemas/interrupt-controller/msi-controller.yaml# + +properties: + compatible: + const: brcm,bcm2712-mip + + reg: + items: + - description: Base register address + - description: PCIe message address + + "#msi-cells": + const: 0 + + brcm,msi-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Shift the allocated MSI's. + +unevaluatedProperties: false + +required: + - compatible + - reg + - msi-controller + - msi-ranges + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + axi { + #address-cells = <2>; + #size-cells = <2>; + + msi-controller@1000130000 { + compatible = "brcm,bcm2712-mip"; + reg = <0x10 0x00130000 0x00 0xc0>, + <0xff 0xfffff000 0x00 0x1000>; + msi-controller; + #msi-cells = <0>; + msi-ranges = <&gicv2 GIC_SPI 128 IRQ_TYPE_EDGE_RISING 64>; + }; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt deleted file mode 100644 index 0bfb3ba55f4c..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt +++ /dev/null @@ -1,58 +0,0 @@ -* NXP LPC32xx MIC, SIC1 and SIC2 Interrupt Controllers - -Required properties: -- compatible: "nxp,lpc3220-mic" or "nxp,lpc3220-sic". -- reg: should contain IC registers location and length. -- interrupt-controller: identifies the node as an interrupt controller. -- #interrupt-cells: the number of cells to define an interrupt, should be 2. - The first cell is the IRQ number, the second cell is used to specify - one of the supported IRQ types: - IRQ_TYPE_EDGE_RISING = low-to-high edge triggered, - IRQ_TYPE_EDGE_FALLING = high-to-low edge triggered, - IRQ_TYPE_LEVEL_HIGH = active high level-sensitive, - IRQ_TYPE_LEVEL_LOW = active low level-sensitive. - Reset value is IRQ_TYPE_LEVEL_LOW. - -Optional properties: -- interrupts: empty for MIC interrupt controller, cascaded MIC - hardware interrupts for SIC1 and SIC2 - -Examples: - - /* LPC32xx MIC, SIC1 and SIC2 interrupt controllers */ - mic: interrupt-controller@40008000 { - compatible = "nxp,lpc3220-mic"; - reg = <0x40008000 0x4000>; - interrupt-controller; - #interrupt-cells = <2>; - }; - - sic1: interrupt-controller@4000c000 { - compatible = "nxp,lpc3220-sic"; - reg = <0x4000c000 0x4000>; - interrupt-controller; - #interrupt-cells = <2>; - - interrupt-parent = <&mic>; - interrupts = <0 IRQ_TYPE_LEVEL_LOW>, - <30 IRQ_TYPE_LEVEL_LOW>; - }; - - sic2: interrupt-controller@40010000 { - compatible = "nxp,lpc3220-sic"; - reg = <0x40010000 0x4000>; - interrupt-controller; - #interrupt-cells = <2>; - - interrupt-parent = <&mic>; - interrupts = <1 IRQ_TYPE_LEVEL_LOW>, - <31 IRQ_TYPE_LEVEL_LOW>; - }; - - /* ADC */ - adc@40048000 { - compatible = "nxp,lpc3220-adc"; - reg = <0x40048000 0x1000>; - interrupt-parent = <&sic1>; - interrupts = <7 IRQ_TYPE_LEVEL_HIGH>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.yaml b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.yaml new file mode 100644 index 000000000000..724c869e3c40 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/nxp,lpc3220-mic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP LPC32xx MIC, SIC1 and SIC2 Interrupt Controllers + +maintainers: + - Vladimir Zapolskiy <vz@mleia.com> + +properties: + compatible: + enum: + - nxp,lpc3220-mic + - nxp,lpc3220-sic + + reg: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + interrupts: + items: + - description: Regular interrupt request + - description: Fast interrupt request + +required: + - compatible + - reg + - interrupt-controller + - '#interrupt-cells' + +allOf: + - if: + properties: + compatible: + contains: + const: nxp,lpc3220-sic + then: + required: + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + mic: interrupt-controller@40008000 { + compatible = "nxp,lpc3220-mic"; + reg = <0x40008000 0x4000>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + interrupt-controller@4000c000 { + compatible = "nxp,lpc3220-sic"; + reg = <0x4000c000 0x4000>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&mic>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>, + <30 IRQ_TYPE_LEVEL_LOW>; + }; diff --git a/Documentation/devicetree/bindings/leds/backlight/apple,dwi-bl.yaml b/Documentation/devicetree/bindings/leds/backlight/apple,dwi-bl.yaml new file mode 100644 index 000000000000..29caeb356e6f --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/apple,dwi-bl.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/apple,dwi-bl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple DWI 2-Wire Interface Backlight Controller + +maintainers: + - Nick Chan <towinchenmi@gmail.com> + +description: + Apple SoCs contain a 2-wire interface called DWI. On some Apple iPhones, + iPads and iPod touches with a LCD display, 1-2 backlight controllers + are connected via DWI. Interfacing with DWI controls all backlight + controllers at the same time. As such, the backlight controllers are + treated as a single controller regardless of the underlying + configuration. + +allOf: + - $ref: common.yaml# + +properties: + compatible: + items: + - enum: + - apple,s5l8960x-dwi-bl + - apple,t7000-dwi-bl + - apple,s8000-dwi-bl + - apple,t8010-dwi-bl + - apple,t8015-dwi-bl + - const: apple,dwi-bl + + reg: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + dwi_bl: backlight@20e200010 { + compatible = "apple,s5l8960x-dwi-bl", "apple,dwi-bl"; + reg = <0x2 0x0e200010 0x0 0x8>; + power-domains = <&ps_dwi>; + }; + }; diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml index 8b82c45d1a48..841a0229c472 100644 --- a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml +++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml @@ -39,6 +39,10 @@ properties: - enum: - qcom,pm8550-pwm - const: qcom,pm8350c-pwm + - items: + - enum: + - qcom,pm8937-pwm + - const: qcom,pm8916-pwm "#pwm-cells": const: 2 diff --git a/Documentation/devicetree/bindings/leds/leds-tlc591xx.txt b/Documentation/devicetree/bindings/leds/leds-tlc591xx.txt deleted file mode 100644 index 3bbbf7024411..000000000000 --- a/Documentation/devicetree/bindings/leds/leds-tlc591xx.txt +++ /dev/null @@ -1,40 +0,0 @@ -LEDs connected to tlc59116 or tlc59108 - -Required properties -- compatible: should be "ti,tlc59116" or "ti,tlc59108" -- #address-cells: must be 1 -- #size-cells: must be 0 -- reg: typically 0x68 - -Each led is represented as a sub-node of the ti,tlc59116. -See Documentation/devicetree/bindings/leds/common.txt - -LED sub-node properties: -- reg: number of LED line, 0 to 15 or 0 to 7 -- label: (optional) name of LED -- linux,default-trigger : (optional) - -Examples: - -tlc59116@68 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "ti,tlc59116"; - reg = <0x68>; - - wan@0 { - label = "wrt1900ac:amber:wan"; - reg = <0x0>; - }; - - 2g@2 { - label = "wrt1900ac:white:2g"; - reg = <0x2>; - }; - - alive@9 { - label = "wrt1900ac:green:alive"; - reg = <0x9>; - linux,default_trigger = "heartbeat"; - }; -}; diff --git a/Documentation/devicetree/bindings/leds/ti,tlc59116.yaml b/Documentation/devicetree/bindings/leds/ti,tlc59116.yaml new file mode 100644 index 000000000000..ce9713793908 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/ti,tlc59116.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/ti,tlc59116.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LEDs connected to tlc59116 or tlc59108 + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + +properties: + compatible: + enum: + - ti,tlc59108 + - ti,tlc59116 + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^led@[0-9a-f]$": + type: object + $ref: common.yaml# + properties: + reg: + items: + minimum: 0 + maximum: 15 + + unevaluatedProperties: false + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +allOf: + - if: + properties: + compatible: + contains: + const: ti,tlc59108 + then: + patternProperties: + "^led@[0-9a-f]$": + properties: + reg: + items: + maximum: 7 + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@68 { + compatible = "ti,tlc59116"; + reg = <0x68>; + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0x0>; + label = "wrt1900ac:amber:wan"; + }; + + led@2 { + reg = <0x2>; + label = "wrt1900ac:white:2g"; + }; + + led@9 { + reg = <0x9>; + label = "wrt1900ac:green:alive"; + linux,default-trigger = "heartbeat"; + }; + }; + }; + diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml index 00631afcd51d..581425aacdcc 100644 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml @@ -54,6 +54,10 @@ properties: - fsl,imx8qm-mu - fsl,imx8qxp-mu - const: fsl,imx6sx-mu + - items: + - enum: + - fsl,imx94-mu + - const: fsl,imx95-mu reg: maxItems: 1 @@ -142,7 +146,8 @@ allOf: not: properties: compatible: - const: fsl,imx95-mu + contains: + const: fsl,imx95-mu then: patternProperties: "^sram@[a-f0-9]+": false diff --git a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml index cef9d7601398..73d6db34d64a 100644 --- a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml @@ -25,6 +25,7 @@ properties: - mediatek,mt8188-gce - mediatek,mt8192-gce - mediatek,mt8195-gce + - mediatek,mt8196-gce - items: - const: mediatek,mt6795-gce - const: mediatek,mt8173-gce @@ -49,6 +50,9 @@ properties: items: - const: gce + iommus: + maxItems: 1 + required: - compatible - "#mbox-cells" diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 78f68dacd028..a58a018f3f7b 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -26,6 +26,7 @@ properties: - const: qcom,ipq6018-apcs-apps-global - items: - enum: + - qcom,msm8226-apcs-kpss-global - qcom,qcs404-apcs-apps-global - const: qcom,msm8916-apcs-kpss-global - const: syscon diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml index 110e8f5f1f9e..ebc615584f92 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml @@ -41,10 +41,6 @@ properties: minItems: 1 maxItems: 5 - assigned-clocks: true - - assigned-clock-parents: true - iommus: minItems: 1 maxItems: 32 @@ -78,8 +74,6 @@ required: - clocks - clock-names - iommus - - assigned-clocks - - assigned-clock-parents allOf: - if: diff --git a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml index a5598ade399f..1578514ec58d 100644 --- a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.yaml @@ -38,50 +38,16 @@ properties: patternProperties: "^.*@[0-3],[a-f0-9]+$": type: object + $ref: mc-peripheral-props.yaml# additionalProperties: true - description: - The actual device nodes should be added as subnodes to the SROMc node. - These subnodes, in addition to regular device specification, should - contain the following properties, describing configuration - of the relevant SROM bank. properties: - reg: - description: - Bank number, base address (relative to start of the bank) and size - of the memory mapped for the device. Note that base address will be - typically 0 as this is the start of the bank. - maxItems: 1 - reg-io-width: enum: [1, 2] description: Data width in bytes (1 or 2). If omitted, default of 1 is used. - samsung,srom-page-mode: - description: - If page mode is set, 4 data page mode will be configured, - else normal (1 data) page mode will be set. - type: boolean - - samsung,srom-timing: - $ref: /schemas/types.yaml#/definitions/uint32-array - minItems: 6 - maxItems: 6 - description: | - Array of 6 integers, specifying bank timings in the following order: - Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs. - Each value is specified in cycles and has the following meaning - and valid range: - Tacp: Page mode access cycle at Page mode (0 - 15) - Tcah: Address holding time after CSn (0 - 15) - Tcoh: Chip selection hold on OEn (0 - 15) - Tacc: Access cycle (0 - 31, the actual time is N + 1) - Tcos: Chip selection set-up before OEn (0 - 15) - Tacs: Address set-up before CSn (0 - 15) - required: - - reg - samsung,srom-timing required: diff --git a/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml index 00deeb09f87d..73a6dac946b7 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml @@ -36,6 +36,8 @@ allOf: - $ref: st,stm32-fmc2-ebi-props.yaml# - $ref: ingenic,nemc-peripherals.yaml# - $ref: intel,ixp4xx-expansion-peripheral-props.yaml# + - $ref: qcom,ebi2-peripheral-props.yaml# + - $ref: samsung,exynos4210-srom-peripheral-props.yaml# - $ref: ti,gpmc-child.yaml# - $ref: fsl/fsl,imx-weim-peripherals.yaml diff --git a/Documentation/devicetree/bindings/memory-controllers/qcom,ebi2-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/qcom,ebi2-peripheral-props.yaml new file mode 100644 index 000000000000..29f8c30e8a88 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/qcom,ebi2-peripheral-props.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/qcom,ebi2-peripheral-props.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Peripheral Properties for Qualcomm External Bus Interface 2 (EBI2) + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + +properties: + # SLOW chip selects + qcom,xmem-recovery-cycles: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + The time the memory continues to drive the data bus after OE + is de-asserted, in order to avoid contention on the data bus. + They are inserted when reading one CS and switching to another + CS or read followed by write on the same CS. Minimum value is + actually 1, so a value of 0 will still yield 1 recovery cycle. + minimum: 0 + maximum: 15 + + qcom,xmem-write-hold-cycles: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + The extra cycles inserted after every write minimum 1. The + data out is driven from the time WE is asserted until CS is + asserted. With a hold of 1 (value = 0), the CS stays active + for 1 extra cycle, etc. + minimum: 0 + maximum: 15 + + qcom,xmem-write-delta-cycles: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + The initial latency for write cycles inserted for the first + write to a page or burst memory. + minimum: 0 + maximum: 255 + + qcom,xmem-read-delta-cycles: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + The initial latency for read cycles inserted for the first + read to a page or burst memory. + minimum: 0 + maximum: 255 + + qcom,xmem-write-wait-cycles: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + The number of wait cycles for every write access. + minimum: 0 + maximum: 15 + + qcom,xmem-read-wait-cycles: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + The number of wait cycles for every read access. + minimum: 0 + maximum: 15 + + + # FAST chip selects + qcom,xmem-address-hold-enable: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + Holds the address for an extra cycle to meet hold time + requirements with ADV assertion, when set to 1. + enum: [ 0, 1 ] + + qcom,xmem-adv-to-oe-recovery-cycles: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + The number of cycles elapsed before an OE assertion, with + respect to the cycle where ADV (address valid) is asserted. + minimum: 0 + maximum: 3 + + qcom,xmem-read-hold-cycles: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + The length in cycles of the first segment of a read transfer. + For a single read transfer this will be the time from CS + assertion to OE assertion. + minimum: 0 + maximum: 15 + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/bus/qcom,ebi2.yaml b/Documentation/devicetree/bindings/memory-controllers/qcom,ebi2.yaml index 1b1fb3538e6e..423d7a75134f 100644 --- a/Documentation/devicetree/bindings/bus/qcom,ebi2.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/qcom,ebi2.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/bus/qcom,ebi2.yaml# +$id: http://devicetree.org/schemas/memory-controllers/qcom,ebi2.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm External Bus Interface 2 (EBI2) @@ -104,91 +104,8 @@ required: patternProperties: "^.*@[0-5],[0-9a-f]+$": type: object + $ref: mc-peripheral-props.yaml# additionalProperties: true - properties: - reg: - maxItems: 1 - - # SLOW chip selects - qcom,xmem-recovery-cycles: - $ref: /schemas/types.yaml#/definitions/uint32 - description: > - The time the memory continues to drive the data bus after OE - is de-asserted, in order to avoid contention on the data bus. - They are inserted when reading one CS and switching to another - CS or read followed by write on the same CS. Minimum value is - actually 1, so a value of 0 will still yield 1 recovery cycle. - minimum: 0 - maximum: 15 - - qcom,xmem-write-hold-cycles: - $ref: /schemas/types.yaml#/definitions/uint32 - description: > - The extra cycles inserted after every write minimum 1. The - data out is driven from the time WE is asserted until CS is - asserted. With a hold of 1 (value = 0), the CS stays active - for 1 extra cycle, etc. - minimum: 0 - maximum: 15 - - qcom,xmem-write-delta-cycles: - $ref: /schemas/types.yaml#/definitions/uint32 - description: > - The initial latency for write cycles inserted for the first - write to a page or burst memory. - minimum: 0 - maximum: 255 - - qcom,xmem-read-delta-cycles: - $ref: /schemas/types.yaml#/definitions/uint32 - description: > - The initial latency for read cycles inserted for the first - read to a page or burst memory. - minimum: 0 - maximum: 255 - - qcom,xmem-write-wait-cycles: - $ref: /schemas/types.yaml#/definitions/uint32 - description: > - The number of wait cycles for every write access. - minimum: 0 - maximum: 15 - - qcom,xmem-read-wait-cycles: - $ref: /schemas/types.yaml#/definitions/uint32 - description: > - The number of wait cycles for every read access. - minimum: 0 - maximum: 15 - - - # FAST chip selects - qcom,xmem-address-hold-enable: - $ref: /schemas/types.yaml#/definitions/uint32 - description: > - Holds the address for an extra cycle to meet hold time - requirements with ADV assertion, when set to 1. - enum: [ 0, 1 ] - - qcom,xmem-adv-to-oe-recovery-cycles: - $ref: /schemas/types.yaml#/definitions/uint32 - description: > - The number of cycles elapsed before an OE assertion, with - respect to the cycle where ADV (address valid) is asserted. - minimum: 0 - maximum: 3 - - qcom,xmem-read-hold-cycles: - $ref: /schemas/types.yaml#/definitions/uint32 - description: > - The length in cycles of the first segment of a read transfer. - For a single read transfer this will be the time from CS - assertion to OE assertion. - minimum: 0 - maximum: 15 - - required: - - reg additionalProperties: false diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos4210-srom-peripheral-props.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos4210-srom-peripheral-props.yaml new file mode 100644 index 000000000000..c474f90846e5 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos4210-srom-peripheral-props.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/samsung,exynos4210-srom-peripheral-props.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Peripheral Properties for Samsung Exynos SoC SROM Controller + +maintainers: + - Krzysztof Kozlowski <krzk@kernel.org> + +properties: + samsung,srom-page-mode: + description: + If page mode is set, 4 data page mode will be configured, + else normal (1 data) page mode will be set. + type: boolean + + samsung,srom-timing: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 6 + maxItems: 6 + description: | + Array of 6 integers, specifying bank timings in the following order: + Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs. + Each value is specified in cycles and has the following meaning + and valid range: + Tacp: Page mode access cycle at Page mode (0 - 15) + Tcah: Address holding time after CSn (0 - 15) + Tcoh: Chip selection hold on OEn (0 - 15) + Tacc: Access cycle (0 - 31, the actual time is N + 1) + Tcos: Chip selection set-up before OEn (0 - 15) + Tacs: Address set-up before CSn (0 - 15) + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml index 5dfe77aca167..d88854e60b7f 100644 --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.yaml @@ -1,5 +1,5 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -# # Copyright (c) 2021 Aspeed Tehchnology Inc. +# # Copyright (c) 2021 Aspeed Technology Inc. %YAML 1.2 --- $id: http://devicetree.org/schemas/mfd/aspeed-lpc.yaml# diff --git a/Documentation/devicetree/bindings/mfd/atmel,sama5d2-flexcom.yaml b/Documentation/devicetree/bindings/mfd/atmel,sama5d2-flexcom.yaml index 0dc6a40b63f4..c7d6cf96796c 100644 --- a/Documentation/devicetree/bindings/mfd/atmel,sama5d2-flexcom.yaml +++ b/Documentation/devicetree/bindings/mfd/atmel,sama5d2-flexcom.yaml @@ -19,12 +19,11 @@ properties: oneOf: - const: atmel,sama5d2-flexcom - items: - - const: microchip,sam9x7-flexcom + - enum: + - microchip,sam9x7-flexcom + - microchip,sama7d65-flexcom + - microchip,sama7g5-flexcom - const: atmel,sama5d2-flexcom - - items: - - const: microchip,sama7g5-flexcom - - const: atmel,sama5d2-flexcom - reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mfd/fsl,mcu-mpc8349emitx.yaml b/Documentation/devicetree/bindings/mfd/fsl,mcu-mpc8349emitx.yaml new file mode 100644 index 000000000000..8beb2ed9edb7 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/fsl,mcu-mpc8349emitx.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/fsl,mcu-mpc8349emitx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale MPC8349E-mITX-compatible Power Management Micro Controller Unit (MCU) + +maintainers: + - J. Neuschäfer <j.ne@posteo.net> + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,mc9s08qg8-mpc8315erdb + - fsl,mc9s08qg8-mpc8349emitx + - fsl,mc9s08qg8-mpc8377erdb + - fsl,mc9s08qg8-mpc8378erdb + - fsl,mc9s08qg8-mpc8379erdb + - const: fsl,mcu-mpc8349emitx + + reg: + maxItems: 1 + + "#gpio-cells": + const: 2 + + gpio-controller: true + +required: + - compatible + - reg + - "#gpio-cells" + - gpio-controller + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + mcu@a { + #gpio-cells = <2>; + compatible = "fsl,mc9s08qg8-mpc8349emitx", + "fsl,mcu-mpc8349emitx"; + reg = <0x0a>; + gpio-controller; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77705.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77705.yaml new file mode 100644 index 000000000000..0ec89f0adc64 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max77705.yaml @@ -0,0 +1,158 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max77705.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77705 Companion Power Management and USB Type-C interface + +maintainers: + - Dzmitry Sankouski <dsankouski@gmail.com> + +description: | + This is a part of device tree bindings for Maxim MAX77705. + + Maxim MAX77705 is a Companion Power Management and Type-C + interface IC which includes charger, fuelgauge, LED, haptic motor driver and + Type-C management. + +properties: + compatible: + const: maxim,max77705 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + haptic: + type: object + additionalProperties: false + + properties: + compatible: + const: maxim,max77705-haptic + + haptic-supply: true + + pwms: + maxItems: 1 + + required: + - compatible + - haptic-supply + - pwms + + leds: + type: object + additionalProperties: false + description: + Up to 4 LED channels supported. + + properties: + compatible: + const: maxim,max77705-rgb + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + multi-led: + type: object + $ref: /schemas/leds/leds-class-multicolor.yaml# + unevaluatedProperties: false + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + "^led@[0-3]$": + type: object + $ref: /schemas/leds/common.yaml# + unevaluatedProperties: false + + properties: + reg: + maxItems: 1 + + required: + - reg + + patternProperties: + "^led@[0-3]$": + type: object + $ref: /schemas/leds/common.yaml# + unevaluatedProperties: false + + properties: + reg: + maxItems: 1 + + required: + - reg + + required: + - compatible + +required: + - compatible + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/leds/common.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "maxim,max77705"; + reg = <0x66>; + interrupt-parent = <&pm8998_gpios>; + interrupts = <11 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&chg_int_default>; + pinctrl-names = "default"; + + leds { + compatible = "maxim,max77705-rgb"; + + multi-led { + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_STATUS; + #address-cells = <1>; + #size-cells = <0>; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_RED>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@3 { + reg = <3>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + }; + + haptic { + compatible = "maxim,max77705-haptic"; + haptic-supply = <&vib_regulator>; + pwms = <&vib_pwm 0 50000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml index a503b67f2dbe..7e7225aadae3 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.yaml @@ -52,6 +52,7 @@ properties: - qcom,tcsr-msm8660 - qcom,tcsr-msm8916 - qcom,tcsr-msm8917 + - qcom,tcsr-msm8937 - qcom,tcsr-msm8953 - qcom,tcsr-msm8960 - qcom,tcsr-msm8974 diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml index a4be642de33c..ac5d0c149796 100644 --- a/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml +++ b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml @@ -25,6 +25,7 @@ properties: - samsung,s2mps14-pmic - samsung,s2mps15-pmic - samsung,s2mpu02-pmic + - samsung,s2mpu05-pmic clocks: $ref: /schemas/clock/samsung,s2mps11.yaml @@ -125,6 +126,18 @@ allOf: samsung,s2mps11-acokb-ground: false samsung,s2mps11-wrstbi-ground: false + - if: + properties: + compatible: + contains: + const: samsung,s2mpu05-pmic + then: + properties: + regulators: + $ref: /schemas/regulator/samsung,s2mpu05.yaml + samsung,s2mps11-acokb-ground: false + samsung,s2mps11-wrstbi-ground: false + examples: - | #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml index b0e438ff4950..66aa1550a4e5 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml @@ -21,7 +21,9 @@ maintainers: properties: compatible: - const: st,stm32-timers + enum: + - st,stm32-timers + - st,stm32mp25-timers reg: maxItems: 1 @@ -36,6 +38,9 @@ properties: resets: maxItems: 1 + power-domains: + maxItems: 1 + dmas: minItems: 1 maxItems: 7 @@ -77,7 +82,9 @@ properties: properties: compatible: - const: st,stm32-pwm + enum: + - st,stm32-pwm + - st,stm32mp25-pwm "#pwm-cells": const: 3 @@ -113,7 +120,9 @@ properties: properties: compatible: - const: st,stm32-timer-counter + enum: + - st,stm32-timer-counter + - st,stm32mp25-timer-counter required: - compatible @@ -128,12 +137,13 @@ patternProperties: enum: - st,stm32-timer-trigger - st,stm32h7-timer-trigger + - st,stm32mp25-timer-trigger reg: description: Identify trigger hardware block. items: minimum: 0 - maximum: 16 + maximum: 19 required: - compatible diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index 2836e4793afc..c6bbb19c3e3e 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -27,6 +27,7 @@ select: compatible: contains: enum: + - airoha,en7581-pbus-csr - al,alpine-sysfabric-service - allwinner,sun8i-a83t-system-controller - allwinner,sun8i-h3-system-controller @@ -90,6 +91,8 @@ select: - microchip,lan966x-cpu-syscon - microchip,mpfs-sysreg-scb - microchip,sam9x60-sfr + - microchip,sama7d65-ddr3phy + - microchip,sama7d65-sfrbu - microchip,sama7g5-ddr3phy - mscc,ocelot-cpu-syscon - mstar,msc313-pmsleep @@ -127,6 +130,7 @@ properties: compatible: items: - enum: + - airoha,en7581-pbus-csr - al,alpine-sysfabric-service - allwinner,sun8i-a83t-system-controller - allwinner,sun8i-h3-system-controller @@ -190,6 +194,8 @@ properties: - microchip,lan966x-cpu-syscon - microchip,mpfs-sysreg-scb - microchip,sam9x60-sfr + - microchip,sama7d65-ddr3phy + - microchip,sama7d65-sfrbu - microchip,sama7g5-ddr3phy - mscc,ocelot-cpu-syscon - mstar,msc313-pmsleep diff --git a/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml new file mode 100644 index 000000000000..d129d6382847 --- /dev/null +++ b/Documentation/devicetree/bindings/mips/mti,mips-cm.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mips/mti,mips-cm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MIPS Coherence Manager + +description: + The Coherence Manager (CM) is responsible for establishing the + global ordering of requests from all elements of the system and + sending the correct data back to the requester. It supports Cache + to Cache transfers. + https://training.mips.com/cps_mips/PDF/CPS_Introduction.pdf + https://training.mips.com/cps_mips/PDF/Coherency_Manager.pdf + +maintainers: + - Jiaxun Yang <jiaxun.yang@flygoat.com> + +properties: + compatible: + oneOf: + - const: mti,mips-cm + - const: mobileye,eyeq6-cm + description: + On EyeQ6 the HCI (Hardware Cache Initialization) information for + the L2 cache in multi-cluster configuration is broken. + + reg: + description: + Base address and size of the Global Configuration Registers + referred to as CMGCR.They are the system programmer's interface + to the Coherency Manager. Their location in the memory map is + determined at core build time. In a functional system, the base + address is provided by the Coprocessor 0, but some + System-on-Chip (SoC) designs may not provide an accurate address + that needs to be described statically. + + maxItems: 1 + +required: + - compatible + +additionalProperties: false + +examples: + - | + coherency-manager@1fbf8000 { + compatible = "mti,mips-cm"; + reg = <0x1bde8000 0x8000>; + }; + + - | + coherency-manager { + compatible = "mobileye,eyeq6-cm"; + }; +... diff --git a/Documentation/devicetree/bindings/net/smsc,lan9115.yaml b/Documentation/devicetree/bindings/net/smsc,lan9115.yaml index f86667cbcca8..42279ae8c2b9 100644 --- a/Documentation/devicetree/bindings/net/smsc,lan9115.yaml +++ b/Documentation/devicetree/bindings/net/smsc,lan9115.yaml @@ -11,6 +11,7 @@ maintainers: allOf: - $ref: ethernet-controller.yaml# + - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml# properties: compatible: @@ -89,10 +90,7 @@ required: - reg - interrupts -# There are lots of bus-specific properties ("qcom,*", "samsung,*", "fsl,*", -# "gpmc,*", ...) to be found, that actually depend on the compatible value of -# the parent node. -additionalProperties: true +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/pci/altr,pcie-root-port.yaml b/Documentation/devicetree/bindings/pci/altr,pcie-root-port.yaml index 52533fccc134..5d3f48a001b7 100644 --- a/Documentation/devicetree/bindings/pci/altr,pcie-root-port.yaml +++ b/Documentation/devicetree/bindings/pci/altr,pcie-root-port.yaml @@ -12,9 +12,19 @@ maintainers: properties: compatible: + description: Each family of socfpga has its own implementation of the + PCI controller. The altr,pcie-root-port-1.0 is used for the Cyclone5 + family of chips. The Stratix10 family of chips is supported by the + altr,pcie-root-port-2.0. The Agilex family of chips has three, + non-register compatible, variants of PCIe Hard IP referred to as the + F-Tile, P-Tile, and R-Tile, depending on the specific chip instance. + enum: - altr,pcie-root-port-1.0 - altr,pcie-root-port-2.0 + - altr,pcie-root-port-3.0-f-tile + - altr,pcie-root-port-3.0-p-tile + - altr,pcie-root-port-3.0-r-tile reg: items: diff --git a/Documentation/devicetree/bindings/pci/amd,versal2-mdb-host.yaml b/Documentation/devicetree/bindings/pci/amd,versal2-mdb-host.yaml new file mode 100644 index 000000000000..43dc2585c237 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/amd,versal2-mdb-host.yaml @@ -0,0 +1,121 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/amd,versal2-mdb-host.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AMD Versal2 MDB(Multimedia DMA Bridge) Host Controller + +maintainers: + - Thippeswamy Havalige <thippeswamy.havalige@amd.com> + +allOf: + - $ref: /schemas/pci/pci-host-bridge.yaml# + - $ref: /schemas/pci/snps,dw-pcie.yaml# + +properties: + compatible: + const: amd,versal2-mdb-host + + reg: + items: + - description: MDB System Level Control and Status Register (SLCR) Base + - description: configuration region + - description: data bus interface + - description: address translation unit register + + reg-names: + items: + - const: slcr + - const: config + - const: dbi + - const: atu + + ranges: + maxItems: 2 + + msi-map: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-map-mask: + items: + - const: 0 + - const: 0 + - const: 0 + - const: 7 + + interrupt-map: + maxItems: 4 + + "#interrupt-cells": + const: 1 + + interrupt-controller: + description: identifies the node as an interrupt controller + type: object + additionalProperties: false + properties: + interrupt-controller: true + + "#address-cells": + const: 0 + + "#interrupt-cells": + const: 1 + + required: + - interrupt-controller + - "#address-cells" + - "#interrupt-cells" + +required: + - reg + - reg-names + - interrupts + - interrupt-map + - interrupt-map-mask + - msi-map + - "#interrupt-cells" + - interrupt-controller + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + pcie@ed931000 { + compatible = "amd,versal2-mdb-host"; + reg = <0x0 0xed931000 0x0 0x2000>, + <0x1000 0x100000 0x0 0xff00000>, + <0x1000 0x0 0x0 0x1000>, + <0x0 0xed860000 0x0 0x2000>; + reg-names = "slcr", "config", "dbi", "atu"; + ranges = <0x2000000 0x00 0xa0000000 0x00 0xa0000000 0x00 0x10000000>, + <0x43000000 0x1100 0x00 0x1100 0x00 0x00 0x1000000>; + interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>; + interrupt-parent = <&gic>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 1 &pcie_intc_0 0>, + <0 0 0 2 &pcie_intc_0 1>, + <0 0 0 3 &pcie_intc_0 2>, + <0 0 0 4 &pcie_intc_0 3>; + msi-map = <0x0 &gic_its 0x00 0x10000>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + device_type = "pci"; + pcie_intc_0: interrupt-controller { + #address-cells = <0>; + #interrupt-cells = <1>; + interrupt-controller; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml index 2ad1652c2584..29f0e1eb5096 100644 --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml @@ -14,6 +14,7 @@ properties: items: - enum: - brcm,bcm2711-pcie # The Raspberry Pi 4 + - brcm,bcm2712-pcie # Raspberry Pi 5 - brcm,bcm4908-pcie - brcm,bcm7211-pcie # Broadcom STB version of RPi4 - brcm,bcm7216-pcie # Broadcom 7216 Arm @@ -101,7 +102,10 @@ properties: reset-names: minItems: 1 - maxItems: 3 + items: + - enum: [perst, rescal] + - const: bridge + - const: swinit required: - compatible diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml index 4c76cd3f98a9..ca5f2970f217 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml @@ -47,12 +47,16 @@ properties: maxItems: 5 interrupts: + minItems: 1 items: - description: builtin MSI controller. + - description: builtin DMA controller. interrupt-names: + minItems: 1 items: - const: msi + - const: dma reset-gpio: description: Should specify the GPIO for controlling the PCI bus device diff --git a/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie-ep.yaml index 399efa7364c9..d78a6d1f7198 100644 --- a/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,layerscape-pcie-ep.yaml @@ -94,9 +94,6 @@ examples: reg-names = "regs", "addr_space"; interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; /* PME interrupt */ interrupt-names = "pme"; - num-ib-windows = <6>; - num-ob-windows = <8>; - status = "disabled"; }; }; ... diff --git a/Documentation/devicetree/bindings/pci/fsl,mpc8xxx-pci.yaml b/Documentation/devicetree/bindings/pci/fsl,mpc8xxx-pci.yaml new file mode 100644 index 000000000000..28759ab1caaa --- /dev/null +++ b/Documentation/devicetree/bindings/pci/fsl,mpc8xxx-pci.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/pci/fsl,mpc8xxx-pci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale MPC83xx PCI/PCI-X/PCIe controllers + +description: + Binding for the PCI/PCI-X/PCIe host bridges on MPC8xxx SoCs + +maintainers: + - J. Neuschäfer <j.neuschaefer@gmx.net> + +allOf: + - $ref: /schemas/pci/pci-host-bridge.yaml# + +properties: + compatible: + oneOf: + - enum: + - fsl,mpc8314-pcie + - fsl,mpc8349-pci + - fsl,mpc8540-pci + - fsl,mpc8548-pcie + - fsl,mpc8641-pcie + - items: + - enum: + - fsl,mpc8308-pcie + - fsl,mpc8315-pcie + - fsl,mpc8377-pcie + - fsl,mpc8378-pcie + - const: fsl,mpc8314-pcie + - items: + - const: fsl,mpc8360-pci + - const: fsl,mpc8349-pci + - items: + - const: fsl,mpc8540-pcix + - const: fsl,mpc8540-pci + + reg: + minItems: 1 + items: + - description: internal registers + - description: config space access registers + + clock-frequency: true + + interrupts: + items: + - description: Consolidated PCI interrupt + + fsl,pci-agent-force-enum: + type: boolean + description: + Typically any Freescale PCI-X bridge hardware strapped into Agent mode is + prevented from enumerating the bus. The PrPMC form-factor requires all + mezzanines to be PCI-X Agents, but one per system may still enumerate the + bus. + + This property allows a PCI-X bridge to be used for bus enumeration + despite being strapped into Agent mode. + +required: + - reg + - compatible + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + pcie@e0009000 { + compatible = "fsl,mpc8315-pcie", "fsl,mpc8314-pcie"; + reg = <0xe0009000 0x00001000>; + ranges = <0x02000000 0 0xa0000000 0xa0000000 0 0x10000000 + 0x01000000 0 0x00000000 0xb1000000 0 0x00800000>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + device_type = "pci"; + bus-range = <0 255>; + interrupt-map-mask = <0xf800 0 0 7>; + interrupt-map = <0 0 0 1 &ipic 1 IRQ_TYPE_LEVEL_LOW + 0 0 0 2 &ipic 1 IRQ_TYPE_LEVEL_LOW + 0 0 0 3 &ipic 1 IRQ_TYPE_LEVEL_LOW + 0 0 0 4 &ipic 1 IRQ_TYPE_LEVEL_LOW>; + clock-frequency = <0>; + }; + + - | + pci@ef008000 { + compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci"; + reg = <0xef008000 0x1000>; + ranges = <0x02000000 0 0x80000000 0x80000000 0 0x20000000 + 0x01000000 0 0x00000000 0xd0000000 0 0x01000000>; + #interrupt-cells = <1>; + #size-cells = <2>; + #address-cells = <3>; + device_type = "pci"; + clock-frequency = <33333333>; + interrupt-map-mask = <0xf800 0x0 0x0 0x7>; + interrupt-map = </* IDSEL */ + 0xe000 0 0 1 &mpic 2 1 + 0xe000 0 0 2 &mpic 3 1>; + interrupts-extended = <&mpic 24 2>; + bus-range = <0 0>; + fsl,pci-agent-force-enum; + }; + +... diff --git a/Documentation/devicetree/bindings/pci/fsl,pci.txt b/Documentation/devicetree/bindings/pci/fsl,pci.txt deleted file mode 100644 index d8ac4a768e7e..000000000000 --- a/Documentation/devicetree/bindings/pci/fsl,pci.txt +++ /dev/null @@ -1,27 +0,0 @@ -* Bus Enumeration by Freescale PCI-X Agent - -Typically any Freescale PCI-X bridge hardware strapped into Agent mode -is prevented from enumerating the bus. The PrPMC form-factor requires -all mezzanines to be PCI-X Agents, but one per system may still -enumerate the bus. - -The property defined below will allow a PCI-X bridge to be used for bus -enumeration despite being strapped into Agent mode. - -Required properties: -- fsl,pci-agent-force-enum : There is no value associated with this - property. The property itself is treated as a boolean. - -Example: - - /* PCI-X bridge known to be PrPMC Monarch */ - pci0: pci@ef008000 { - fsl,pci-agent-force-enum; - #interrupt-cells = <1>; - #size-cells = <2>; - #address-cells = <3>; - compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci"; - device_type = "pci"; - ... - ... - }; diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml index f05aab2b1add..162406e0691a 100644 --- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml @@ -109,6 +109,17 @@ properties: power-domains: maxItems: 1 + mediatek,pbus-csr: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to pbus-csr syscon + - description: offset of pbus-csr base address register + - description: offset of pbus-csr base address mask register + description: + Phandle with two arguments to the syscon node used to detect if + a given address is accessible on PCIe controller. + '#interrupt-cells': const: 1 @@ -168,6 +179,8 @@ allOf: minItems: 1 maxItems: 2 + mediatek,pbus-csr: false + - if: properties: compatible: @@ -197,6 +210,8 @@ allOf: minItems: 1 maxItems: 2 + mediatek,pbus-csr: false + - if: properties: compatible: @@ -224,6 +239,8 @@ allOf: minItems: 1 maxItems: 2 + mediatek,pbus-csr: false + - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/pci/pci-ep-bus.yaml b/Documentation/devicetree/bindings/pci/pci-ep-bus.yaml new file mode 100644 index 000000000000..a2cd7905f5bf --- /dev/null +++ b/Documentation/devicetree/bindings/pci/pci-ep-bus.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/pci-ep-bus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common Properties for PCI MFD EP with Peripherals Addressable from BARs + +maintainers: + - A. della Porta <andrea.porta@suse.com> + +description: + Define a generic node representing a PCI endpoint which contains several sub- + peripherals. The peripherals can be accessed through one or more BARs. + This common schema is intended to be referenced from device tree bindings and + does not represent a device tree binding by itself. + +properties: + '#address-cells': + const: 3 + + '#size-cells': + const: 2 + + ranges: + minItems: 1 + maxItems: 6 + items: + maxItems: 8 + additionalItems: true + items: + - maximum: 5 # The BAR number + - const: 0 + - const: 0 + +patternProperties: + '^pci-ep-bus@[0-5]$': + type: object + description: + One node for each BAR used by peripherals contained in the PCI endpoint. + Each node represents a bus on which peripherals are connected. + This allows for some segmentation, e.g., one peripheral is accessible + through BAR0 and another through BAR1, and you don't want the two + peripherals to be able to act on the other BAR. Alternatively, when + different peripherals need to share BARs, you can define only one node + and use a 'ranges' property to map all the used BARs. + + additionalProperties: true + + properties: + compatible: + const: simple-bus + + required: + - compatible + +additionalProperties: true +... diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml index 1226ee5d08d1..ac3414203d38 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml @@ -14,6 +14,7 @@ properties: oneOf: - enum: - qcom,sa8775p-pcie-ep + - qcom,sar2130p-pcie-ep - qcom,sdx55-pcie-ep - qcom,sm8450-pcie-ep - items: @@ -44,11 +45,11 @@ properties: clocks: minItems: 5 - maxItems: 8 + maxItems: 9 clock-names: minItems: 5 - maxItems: 8 + maxItems: 9 qcom,perst-regs: description: Reference to a syscon representing TCSR followed by the two @@ -75,6 +76,9 @@ properties: - const: doorbell - const: dma + iommus: + maxItems: 1 + reset-gpios: description: GPIO used as PERST# input signal maxItems: 1 @@ -91,6 +95,8 @@ properties: - const: pcie-mem - const: cpu-pcie + dma-coherent: true + resets: maxItems: 1 @@ -126,6 +132,38 @@ required: allOf: - $ref: pci-ep.yaml# + + - if: + properties: + compatible: + contains: + enum: + - qcom,sar2130p-pcie-ep + then: + properties: + clocks: + items: + - description: PCIe Auxiliary clock + - description: PCIe CFG AHB clock + - description: PCIe Master AXI clock + - description: PCIe Slave AXI clock + - description: PCIe Slave Q2A AXI clock + - description: PCIe DDRSS SF TBU clock + - description: PCIe AGGRE NOC AXI clock + - description: PCIe CFG NOC AXI clock + - description: PCIe QMIP AHB clock + clock-names: + items: + - const: aux + - const: cfg + - const: bus_master + - const: bus_slave + - const: slave_q2a + - const: ddrss_sf_tbu + - const: aggre_noc_axi + - const: cnoc_sf_axi + - const: qmip_pcie_ahb + - if: properties: compatible: @@ -135,9 +173,43 @@ allOf: then: properties: reg: + minItems: 6 maxItems: 6 reg-names: + minItems: 6 maxItems: 6 + interrupts: + minItems: 2 + maxItems: 2 + interrupt-names: + minItems: 2 + maxItems: 2 + iommus: false + else: + properties: + reg: + minItems: 7 + maxItems: 7 + reg-names: + minItems: 7 + maxItems: 7 + interrupts: + minItems: 3 + maxItems: 3 + interrupt-names: + minItems: 3 + maxItems: 3 + required: + - iommus + + - if: + properties: + compatible: + contains: + enum: + - qcom,sdx55-pcie-ep + then: + properties: clocks: items: - description: PCIe Auxiliary clock @@ -156,10 +228,6 @@ allOf: - const: slave_q2a - const: sleep - const: ref - interrupts: - maxItems: 2 - interrupt-names: - maxItems: 2 - if: properties: @@ -169,10 +237,6 @@ allOf: - qcom,sm8450-pcie-ep then: properties: - reg: - maxItems: 6 - reg-names: - maxItems: 6 clocks: items: - description: PCIe Auxiliary clock @@ -193,10 +257,6 @@ allOf: - const: ref - const: ddrss_sf_tbu - const: aggre_noc_axi - interrupts: - maxItems: 2 - interrupt-names: - maxItems: 2 - if: properties: @@ -206,12 +266,6 @@ allOf: - qcom,sa8775p-pcie-ep then: properties: - reg: - minItems: 7 - maxItems: 7 - reg-names: - minItems: 7 - maxItems: 7 clocks: items: - description: PCIe Auxiliary clock @@ -226,12 +280,6 @@ allOf: - const: bus_master - const: bus_slave - const: slave_q2a - interrupts: - minItems: 3 - maxItems: 3 - interrupt-names: - minItems: 3 - maxItems: 3 unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml index 7235d6554cfb..8f628939209e 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml @@ -33,6 +33,7 @@ properties: - qcom,pcie-sdx55 - items: - enum: + - qcom,pcie-ipq5332 - qcom,pcie-ipq5424 - const: qcom,pcie-ipq9574 - items: @@ -49,11 +50,11 @@ properties: interrupts: minItems: 1 - maxItems: 8 + maxItems: 9 interrupt-names: minItems: 1 - maxItems: 8 + maxItems: 9 iommu-map: minItems: 1 @@ -443,6 +444,7 @@ allOf: interrupts: minItems: 8 interrupt-names: + minItems: 8 items: - const: msi0 - const: msi1 @@ -452,6 +454,7 @@ allOf: - const: msi5 - const: msi6 - const: msi7 + - const: global - if: properties: @@ -599,6 +602,7 @@ allOf: - properties: interrupts: minItems: 8 + maxItems: 8 interrupt-names: items: - const: msi0 diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml index 205326fb2d75..1117a86fb6f7 100644 --- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml @@ -113,6 +113,8 @@ properties: enum: [ smu, mpu ] - description: Tegra234 aperture enum: [ ecam ] + - description: AMD MDB PCIe SLCR region + const: slcr allOf: - contains: const: dbi diff --git a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml index b63a759ec2d7..d674a24c8ccc 100644 --- a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml +++ b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml @@ -18,6 +18,7 @@ properties: - xlnx,versal-cpm-host-1.00 - xlnx,versal-cpm5-host - xlnx,versal-cpm5-host1 + - xlnx,versal-cpm5nc-host reg: items: diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml index 21209126ed00..580c3296a18d 100644 --- a/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml @@ -20,7 +20,9 @@ properties: - allwinner,sun20i-d1-usb-phy - allwinner,sun50i-a64-usb-phy - items: - - const: allwinner,sun50i-a100-usb-phy + - enum: + - allwinner,sun50i-a100-usb-phy + - allwinner,sun55i-a523-usb-phy - const: allwinner,sun20i-d1-usb-phy reg: diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml index 1b3de6678c08..888e6b2aac5a 100644 --- a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml @@ -12,6 +12,7 @@ maintainers: properties: compatible: enum: + - rockchip,rk3562-naneng-combphy - rockchip,rk3568-naneng-combphy - rockchip,rk3576-naneng-combphy - rockchip,rk3588-naneng-combphy diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq5332-uniphy-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq5332-uniphy-pcie-phy.yaml new file mode 100644 index 000000000000..e39168d55d23 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,ipq5332-uniphy-pcie-phy.yaml @@ -0,0 +1,76 @@ +# 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>; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml index 89391649e0b5..2c6c9296e4c0 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml @@ -17,6 +17,7 @@ properties: compatible: enum: - qcom,qcs615-qmp-gen3x1-pcie-phy + - qcom,qcs8300-qmp-gen4x2-pcie-phy - qcom,sa8775p-qmp-gen4x2-pcie-phy - qcom,sa8775p-qmp-gen4x4-pcie-phy - qcom,sar2130p-qmp-gen3x2-pcie-phy @@ -45,6 +46,7 @@ properties: - qcom,x1e80100-qmp-gen4x2-pcie-phy - qcom,x1e80100-qmp-gen4x4-pcie-phy - qcom,x1e80100-qmp-gen4x8-pcie-phy + - qcom,x1p42100-qmp-gen4x4-pcie-phy reg: minItems: 1 @@ -124,6 +126,7 @@ allOf: enum: - qcom,sc8280xp-qmp-gen3x4-pcie-phy - qcom,x1e80100-qmp-gen4x4-pcie-phy + - qcom,x1p42100-qmp-gen4x4-pcie-phy then: properties: reg: @@ -180,6 +183,7 @@ allOf: - qcom,x1e80100-qmp-gen4x2-pcie-phy - qcom,x1e80100-qmp-gen4x4-pcie-phy - qcom,x1e80100-qmp-gen4x8-pcie-phy + - qcom,x1p42100-qmp-gen4x4-pcie-phy then: properties: clocks: @@ -192,6 +196,7 @@ allOf: compatible: contains: enum: + - qcom,qcs8300-qmp-gen4x2-pcie-phy - qcom,sa8775p-qmp-gen4x2-pcie-phy - qcom,sa8775p-qmp-gen4x4-pcie-phy then: @@ -217,12 +222,6 @@ allOf: minItems: 2 reset-names: minItems: 2 - else: - properties: - resets: - maxItems: 1 - reset-names: - maxItems: 1 - if: properties: diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml index 72bed2933b03..a58370a6a5d3 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml @@ -44,6 +44,7 @@ properties: - qcom,sm8475-qmp-ufs-phy - qcom,sm8550-qmp-ufs-phy - qcom,sm8650-qmp-ufs-phy + - qcom,sm8750-qmp-ufs-phy reg: maxItems: 1 @@ -111,6 +112,7 @@ allOf: - qcom,sm8475-qmp-ufs-phy - qcom,sm8550-qmp-ufs-phy - qcom,sm8650-qmp-ufs-phy + - qcom,sm8750-qmp-ufs-phy then: properties: clocks: diff --git a/Documentation/devicetree/bindings/phy/rockchip,rk3588-hdptx-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,rk3588-hdptx-phy.yaml index 84fe59dbcf48..7a307f45cdec 100644 --- a/Documentation/devicetree/bindings/phy/rockchip,rk3588-hdptx-phy.yaml +++ b/Documentation/devicetree/bindings/phy/rockchip,rk3588-hdptx-phy.yaml @@ -11,8 +11,13 @@ maintainers: properties: compatible: - enum: - - rockchip,rk3588-hdptx-phy + oneOf: + - enum: + - rockchip,rk3588-hdptx-phy + - items: + - enum: + - rockchip,rk3576-hdptx-phy + - const: rockchip,rk3588-hdptx-phy reg: maxItems: 1 @@ -34,24 +39,12 @@ properties: const: 0 resets: - items: - - description: PHY reset line - - description: APB reset line - - description: INIT reset line - - description: CMN reset line - - description: LANE reset line - - description: ROPLL reset line - - description: LCPLL reset line + minItems: 4 + maxItems: 7 reset-names: - items: - - const: phy - - const: apb - - const: init - - const: cmn - - const: lane - - const: ropll - - const: lcpll + minItems: 4 + maxItems: 7 rockchip,grf: $ref: /schemas/types.yaml#/definitions/phandle @@ -67,6 +60,39 @@ required: - reset-names - rockchip,grf +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 + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/phy/rockchip,rk3588-mipi-dcphy.yaml b/Documentation/devicetree/bindings/phy/rockchip,rk3588-mipi-dcphy.yaml new file mode 100644 index 000000000000..c8ff5ba22a86 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/rockchip,rk3588-mipi-dcphy.yaml @@ -0,0 +1,87 @@ +# 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: + compatible: + enum: + - rockchip,rk3576-mipi-dcphy + - rockchip,rk3588-mipi-dcphy + + reg: + maxItems: 1 + + "#phy-cells": + const: 1 + description: | + Argument is mode to operate in. Supported modes are: + - PHY_TYPE_DPHY + - PHY_TYPE_CPHY + See include/dt-bindings/phy/phy.h for constants. + + clocks: + maxItems: 2 + + clock-names: + items: + - const: pclk + - const: ref + + resets: + maxItems: 4 + + reset-names: + items: + - const: m_phy + - const: apb + - const: grf + - const: s_phy + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon managing the 'mipi dcphy general register files'. + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - "#phy-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rockchip,rk3588-cru.h> + #include <dt-bindings/reset/rockchip,rk3588-cru.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + phy@feda0000 { + compatible = "rockchip,rk3588-mipi-dcphy"; + reg = <0x0 0xfeda0000 0x0 0x10000>; + clocks = <&cru PCLK_MIPI_DCPHY0>, + <&cru CLK_USBDPPHY_MIPIDCPPHY_REF>; + clock-names = "pclk", "ref"; + resets = <&cru SRST_M_MIPI_DCPHY0>, + <&cru SRST_P_MIPI_DCPHY0>, + <&cru SRST_P_MIPI_DCPHY0_GRF>, + <&cru SRST_S_MIPI_DCPHY0>; + reset-names = "m_phy", "apb", "grf", "s_phy"; + rockchip,grf = <&mipidcphy0_grf>; + #phy-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml index f402e31bf58d..d70ffeb6e824 100644 --- a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml @@ -18,6 +18,7 @@ properties: - google,gs101-ufs-phy - samsung,exynos7-ufs-phy - samsung,exynosautov9-ufs-phy + - samsung,exynosautov920-ufs-phy - tesla,fsd-ufs-phy reg: diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml index 16321cdd4919..27295acbba76 100644 --- a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml @@ -83,14 +83,19 @@ properties: pll-supply: description: Power supply for the USB PLL. + dvdd-usb20-supply: description: DVDD power supply for the USB 2.0 phy. + vddh-usb20-supply: description: VDDh power supply for the USB 2.0 phy. + vdd33-usb20-supply: description: 3.3V power supply for the USB 2.0 phy. + vdda-usbdp-supply: description: VDDa power supply for the USB DP phy. + vddh-usbdp-supply: description: VDDh power supply for the USB DP phy. @@ -109,6 +114,8 @@ allOf: contains: const: google,gs101-usb31drd-phy then: + $ref: /schemas/usb/usb-switch.yaml# + properties: clocks: items: @@ -117,6 +124,7 @@ allOf: - description: Gate of control interface AXI clock - description: Gate of control interface APB clock - description: Gate of SCL APB clock + clock-names: items: - const: phy @@ -124,12 +132,17 @@ allOf: - const: ctrl_aclk - const: ctrl_pclk - const: scl_pclk + reg: minItems: 3 + reg-names: minItems: 3 + required: - reg-names + - orientation-switch + - port - pll-supply - dvdd-usb20-supply - vddh-usb20-supply @@ -149,6 +162,7 @@ allOf: clocks: minItems: 5 maxItems: 5 + clock-names: items: - const: phy @@ -156,8 +170,10 @@ allOf: - const: phy_utmi - const: phy_pipe - const: itp + reg: maxItems: 1 + reg-names: maxItems: 1 @@ -174,16 +190,19 @@ allOf: clocks: minItems: 2 maxItems: 2 + clock-names: items: - const: phy - const: ref + reg: maxItems: 1 + reg-names: maxItems: 1 -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/pinctrl/airoha,en7581-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/airoha,en7581-pinctrl.yaml index b2601d698dcd..21fd4f1ba78b 100644 --- a/Documentation/devicetree/bindings/pinctrl/airoha,en7581-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/airoha,en7581-pinctrl.yaml @@ -24,6 +24,9 @@ properties: '#gpio-cells': const: 2 + gpio-ranges: + maxItems: 1 + interrupt-controller: true '#interrupt-cells': diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml new file mode 100644 index 000000000000..154e03da8ce9 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun55i-a523-pinctrl.yaml @@ -0,0 +1,175 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/allwinner,sun55i-a523-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A523 Pin Controller + +maintainers: + - Andre Przywara <andre.przywara@arm.com> + +properties: + "#gpio-cells": + const: 3 + description: + GPIO consumers must use three arguments, first the number of the + bank, then the pin number inside that bank, and finally the GPIO + flags. + + "#interrupt-cells": + const: 3 + description: + Interrupts consumers must use three arguments, first the number + of the bank, then the pin number inside that bank, and finally + the interrupts flags. + + compatible: + enum: + - allwinner,sun55i-a523-pinctrl + - allwinner,sun55i-a523-r-pinctrl + + reg: + maxItems: 1 + + interrupts: + minItems: 2 + maxItems: 10 + description: + One interrupt per external interrupt bank supported on the + controller, sorted by bank number ascending order. + + clocks: + items: + - description: Bus Clock + - description: High Frequency Oscillator + - description: Low Frequency Oscillator + + clock-names: + items: + - const: apb + - const: hosc + - const: losc + + gpio-controller: true + interrupt-controller: true + gpio-line-names: true + + input-debounce: + description: + Debouncing periods in microseconds, one period per interrupt + bank found in the controller + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 10 + +patternProperties: + # It's pretty scary, but the basic idea is that: + # - One node name can start with either s- or r- for PRCM nodes, + # - Then, the name itself can be any repetition of <string>- (to + # accommodate with nodes like uart4-rts-cts-pins), where each + # string can be either starting with 'p' but in a string longer + # than 3, or something that doesn't start with 'p', + # - Then, the bank name is optional and will be between pa and pm. + # Some pins groups that have several options will have the pin + # numbers then, + # - Finally, the name will end with either -pin or pins. + + "^([rs]-)?(([a-z0-9]{3,}|[a-oq-z][a-z0-9]*?)?-)+?(p[a-m][0-9]*?-)??pins?$": + type: object + + properties: + pins: true + function: true + bias-disable: true + bias-pull-up: true + bias-pull-down: true + + drive-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [10, 20, 30, 40] + + allwinner,pinmux: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + Pinmux selector value, for each pin. Almost every time this value + is the same for all pins, so any array shorter than the number of + pins will repeat the last value, to allow just specifying a single + cell, for all cells. + + required: + - pins + - allwinner,pinmux + - function + + additionalProperties: false + + "^vcc-p[a-m]-supply$": + description: + Power supplies for pin banks. + +required: + - "#gpio-cells" + - compatible + - reg + - clocks + - clock-names + - gpio-controller + - "#interrupt-cells" + - interrupts + - interrupt-controller + +allOf: + - $ref: pinctrl.yaml# + - if: + properties: + compatible: + enum: + - allwinner,sun55i-a523-pinctrl + + then: + properties: + interrupts: + minItems: 10 + maxItems: 10 + + - if: + properties: + compatible: + enum: + - allwinner,sun55i-a523-r-pinctrl + + then: + properties: + interrupts: + minItems: 2 + maxItems: 2 + +additionalProperties: false + +examples: + - | + r_pio: pinctrl@7022000 { + compatible = "allwinner,sun55i-a523-r-pinctrl"; + reg = <0x7022000 0x800>; + interrupts = <0 159 4>, <0 161 4>; + clocks = <&r_ccu 1>, <&osc24M>, <&osc32k>; + clock-names = "apb", "hosc", "losc"; + gpio-controller; + #gpio-cells = <3>; + interrupt-controller; + #interrupt-cells = <3>; + + r_i2c_pins: r-i2c-pins { + pins = "PL0", "PL1"; + allwinner,pinmux = <2>; + function = "r_i2c0"; + bias-pull-up; + }; + + r_spi_pins: r-spi-pins { + pins = "PL11" ,"PL12", "PL13"; + allwinner,pinmux = <6>; + function = "r_spi"; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml new file mode 100644 index 000000000000..8eb50cad61d5 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/amlogic,pinctrl-a4.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic pinmux controller + +maintainers: + - Xianwei Zhao <xianwei.zhao@amlogic.com> + +allOf: + - $ref: pinctrl.yaml# + +properties: + compatible: + const: amlogic,pinctrl-a4 + + "#address-cells": + const: 2 + + "#size-cells": + const: 2 + + ranges: true + +patternProperties: + "^gpio@[0-9a-f]+$": + type: object + + additionalProperties: false + properties: + reg: + minItems: 1 + items: + - description: pin config register + - description: pin mux setting register (some special pin fixed function) + - description: pin drive strength register (optional) + + reg-names: + minItems: 1 + items: + - const: gpio + - const: mux + - const: ds + + gpio-controller: true + + "#gpio-cells": + const: 2 + + gpio-ranges: + maxItems: 1 + + required: + - reg + - reg-names + - gpio-controller + - "#gpio-cells" + - gpio-ranges + + "^func-[0-9a-z-]+$": + type: object + additionalProperties: false + patternProperties: + "^group-[0-9a-z-]+$": + type: object + allOf: + - $ref: /schemas/pinctrl/pincfg-node.yaml + - $ref: /schemas/pinctrl/pinmux-node.yaml + + required: + - pinmux + +required: + - compatible + - "#address-cells" + - "#size-cells" + - ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/amlogic,pinctrl.h> + apb { + #address-cells = <2>; + #size-cells = <2>; + periphs_pinctrl: pinctrl { + compatible = "amlogic,pinctrl-a4"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + + gpio@4240 { + reg = <0 0x4240 0 0x40>, <0 0x4000 0 0x8>; + reg-names = "gpio", "mux"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&periphs_pinctrl 0 8 10>; + }; + + func-uart-b { + group-default { + pinmux = <AML_PINMUX(AMLOGIC_GPIO_B, 1, 4)>; + bias-pull-up; + drive-strength-microamp = <4000>; + }; + + group-pins1 { + pinmux = <AML_PINMUX(AMLOGIC_GPIO_B, 5, 2)>; + bias-pull-up; + drive-strength-microamp = <4000>; + }; + }; + + func-uart-c { + group-default { + pinmux = <AML_PINMUX(AMLOGIC_GPIO_B, 3, 1)>, + <AML_PINMUX(AMLOGIC_GPIO_B, 2, 1)>; + bias-pull-up; + drive-strength-microamp = <4000>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt index 774c3c269c40..81a05a09f19f 100644 --- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt @@ -6,6 +6,7 @@ configure it. Required properties: - compatible: "atmel,sama5d2-pinctrl" + "microchip,sama7d65-pinctrl", "microchip,sama7g5-pinctrl" "microchip,sama7g5-pinctrl" - reg: base address and length of the PIO controller. - interrupts: interrupt outputs from the controller, one for each bank. diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm21664-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm21664-pinctrl.yaml new file mode 100644 index 000000000000..1283a588416d --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm21664-pinctrl.yaml @@ -0,0 +1,152 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/brcm,bcm21664-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM21664 pin controller + +maintainers: + - Florian Fainelli <florian.fainelli@broadcom.com> + - Ray Jui <rjui@broadcom.com> + - Scott Branden <sbranden@broadcom.com> + +allOf: + - $ref: pinctrl.yaml# + +properties: + compatible: + const: brcm,bcm21664-pinctrl + + reg: + maxItems: 1 + +patternProperties: + '-pins$': + type: object + additionalProperties: false + + patternProperties: + '-grp[0-9]$': + type: object + + properties: + pins: + description: + Specifies the name(s) of one or more pins to be configured by + this node. + items: + enum: [ adcsyn, batrm, bsc1clk, bsc1dat, camcs0, camcs1, clk32k, + clk_cx8, dclk1, dclk4, dclkreq1, dclkreq4, dmic0clk, + dmic0dq, dsi0te, gpio00, gpio01, gpio02, gpio03, gpio04, + gpio05, gpio06, gpio07, gpio08, gpio09, gpio10, gpio11, + gpio12, gpio13, gpio14, gpio15, gpio16, gpio17, gpio18, + gpio19, gpio20, gpio21, gpio22, gpio23, gpio24, gpio25, + gpio26, gpio27, gpio28, gpio32, gpio33, gpio34, gpio93, + gpio94, gps_calreq, gps_hostreq, gps_pablank, gps_tmark, + icusbdm, icusbdp, lcdcs0, lcdres, lcdscl, lcdsda, lcdte, + mdmgpio00, mdmgpio01, mdmgpio02, mdmgpio03, mdmgpio04, + mdmgpio05, mdmgpio06, mdmgpio07, mdmgpio08, mmc0ck, + mmc0cmd, mmc0dat0, mmc0dat1, mmc0dat2, mmc0dat3, mmc0dat4, + mmc0dat5, mmc0dat6, mmc0dat7, mmc0rst, mmc1ck, mmc1cmd, + mmc1dat0, mmc1dat1, mmc1dat2, mmc1dat3, mmc1dat4, + mmc1dat5, mmc1dat6, mmc1dat7, mmc1rst, pc1, pc2, pmbscclk, + pmbscdat, pmuint, resetn, rfst2g_mtsloten3g, + rtxdata2g_txdata3g1, rtxen2g_txdata3g2, rxdata3g0, + rxdata3g1, rxdata3g2, sdck, sdcmd, sddat0, sddat1, sddat2, + sddat3, simclk, simdat, simdet, simrst, spi0clk, spi0fss, + spi0rxd, spi0txd, sri_c, sri_d, sri_e, sspck, sspdi, + sspdo, sspsyn, stat1, stat2, swclktck, swdiotms, sysclken, + tdi, tdo, testmode, traceclk, tracedt00, tracedt01, + tracedt02, tracedt03, tracedt04, tracedt05, tracedt06, + tracedt07, tracedt08, tracedt09, tracedt10, tracedt11, + tracedt12, tracedt13, tracedt14, tracedt15, trstb, + txdata3g0, ubctsn, ubrtsn, ubrx, ubtx ] + + function: + description: + Specifies the pin mux selection. + enum: [ alt1, alt2, alt3, alt4, alt5, alt6 ] + + bias-disable: true + + bias-pull-up: + type: boolean + + bias-pull-down: + type: boolean + + slew-rate: + description: | + Meaning depends on configured pin mux: + bsc*clk/pmbscclk or bsc*dat/pmbscdat or gpio16/gpio17: + 0: Standard (100 kbps) & Fast (400 kbps) mode + 1: Highspeed (3.4 Mbps) mode + Otherwise: + 0: fast slew rate + 1: normal slew rate + + drive-strength: + enum: [ 2, 4, 6, 8, 10, 12, 14, 16 ] + + input-enable: true + input-disable: true + + input-schmitt-enable: true + input-schmitt-disable: true + + required: + - pins + + additionalProperties: false + + allOf: + - $ref: pincfg-node.yaml# + # Limitations for I2C pins + - if: + properties: + pins: + contains: + enum: [ bsc1clk, bsc1dat, gpio16, gpio17, pmbscclk, + pmbscdat ] + then: + properties: + drive-strength: false + bias-pull-down: false + input-schmitt-enable: false + input-schmitt-disable: false + + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + pinctrl@35004800 { + compatible = "brcm,bcm21664-pinctrl"; + reg = <0x35004800 0x7f0>; + + dev-a-active-pins { + /* group node defining 1 standard pin */ + std-grp0 { + pins = "gpio00"; + function = "alt1"; + input-schmitt-enable; + bias-disable; + slew-rate = <1>; + drive-strength = <4>; + }; + + /* group node defining 2 I2C pins */ + i2c-grp0 { + pins = "bsc1clk", "bsc1dat"; + function = "alt2"; + bias-pull-up; + input-enable; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml index 890961826c6f..84e960255a36 100644 --- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml @@ -42,6 +42,7 @@ properties: - ingenic,jz4780-pinctrl - ingenic,x1000-pinctrl - ingenic,x1500-pinctrl + - ingenic,x1600-pinctrl - ingenic,x1830-pinctrl - ingenic,x2000-pinctrl - ingenic,x2100-pinctrl @@ -81,6 +82,7 @@ patternProperties: - ingenic,jz4780-gpio - ingenic,x1000-gpio - ingenic,x1500-gpio + - ingenic,x1600-gpio - ingenic,x1830-gpio - ingenic,x2000-gpio - ingenic,x2100-gpio diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml index 749dbc563ac5..7a156b9bfaf3 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sa8775p-tlmm.yaml @@ -79,7 +79,7 @@ $defs: cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, ddr_pxi4, ddr_pxi5, edp0_hot, edp0_lcd, edp1_hot, edp1_lcd, edp2_hot, edp2_lcd, edp3_hot, - edp3_lcd, emac0_mcg0, emac0_mcg1, emac0_mcg2, emac0_mcg3, + edp3_lcd, egpio, emac0_mcg0, emac0_mcg1, emac0_mcg2, emac0_mcg3, emac0_mdc, emac0_mdio, emac0_ptp_aux, emac0_ptp_pps, emac1_mcg0, emac1_mcg1, emac1_mcg2, emac1_mcg3, emac1_mdc, emac1_mdio, emac1_ptp_aux, emac1_ptp_pps, gcc_gp1, gcc_gp2, gcc_gp3, diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml index 80a2b1934849..960758dc417f 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml @@ -44,6 +44,7 @@ properties: - rockchip,rk3328-pinctrl - rockchip,rk3368-pinctrl - rockchip,rk3399-pinctrl + - rockchip,rk3528-pinctrl - rockchip,rk3562-pinctrl - rockchip,rk3568-pinctrl - rockchip,rk3576-pinctrl diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml index 68ed714eb0a1..0da6d69f5991 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml @@ -40,6 +40,7 @@ properties: - items: - enum: - samsung,exynos5433-wakeup-eint + - samsung,exynos7870-wakeup-eint - samsung,exynos7885-wakeup-eint - samsung,exynos850-wakeup-eint - samsung,exynos8895-wakeup-eint @@ -47,6 +48,7 @@ properties: - items: - enum: - google,gs101-wakeup-eint + - samsung,exynos2200-wakeup-eint - samsung,exynos9810-wakeup-eint - samsung,exynos990-wakeup-eint - samsung,exynosautov9-wakeup-eint @@ -104,6 +106,7 @@ allOf: - contains: enum: - samsung,exynos5433-wakeup-eint + - samsung,exynos7870-wakeup-eint - samsung,exynos7885-wakeup-eint - samsung,exynos8895-wakeup-eint then: diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml index 5296a9e4faae..de8460856141 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml @@ -42,6 +42,7 @@ properties: - samsung,s3c2450-pinctrl - samsung,s3c64xx-pinctrl - samsung,s5pv210-pinctrl + - samsung,exynos2200-pinctrl - samsung,exynos3250-pinctrl - samsung,exynos4210-pinctrl - samsung,exynos4x12-pinctrl @@ -51,6 +52,7 @@ properties: - samsung,exynos5420-pinctrl - samsung,exynos5433-pinctrl - samsung,exynos7-pinctrl + - samsung,exynos7870-pinctrl - samsung,exynos7885-pinctrl - samsung,exynos850-pinctrl - samsung,exynos8895-pinctrl diff --git a/Documentation/devicetree/bindings/pinctrl/sophgo,sg2042-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/sophgo,sg2042-pinctrl.yaml new file mode 100644 index 000000000000..924dfe1404a5 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/sophgo,sg2042-pinctrl.yaml @@ -0,0 +1,129 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/sophgo,sg2042-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sophgo SG2042 Pin Controller + +maintainers: + - Inochi Amaoto <inochiama@outlook.com> + +properties: + compatible: + enum: + - sophgo,sg2042-pinctrl + - sophgo,sg2044-pinctrl + + reg: + maxItems: 1 + +patternProperties: + '-cfg$': + type: object + description: + A pinctrl node should contain at least one subnode representing the + pinctrl groups available on the machine. + + additionalProperties: false + + patternProperties: + '-pins$': + type: object + description: | + Each subnode will list the pins it needs, and how they should + be configured, with regard to muxer configuration, bias input + enable/disable, input schmitt trigger enable, drive strength + output enable/disable state. For configuration detail, + refer to https://github.com/sophgo/sophgo-doc/. + + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + + properties: + pinmux: + description: | + The list of GPIOs and their mux settings that properties in the + node apply to. This should be set using the PINMUX macro. + + bias-disable: true + + bias-pull-up: + type: boolean + + bias-pull-down: + type: boolean + + drive-strength-microamp: + description: typical current when output low level. + + input-schmitt-enable: true + + input-schmitt-disable: true + + required: + - pinmux + + additionalProperties: false + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: sophgo,sg2042-pinctrl + then: + patternProperties: + '-cfg$': + patternProperties: + '-pins$': + properties: + drive-strength-microamp: + enum: [ 5400, 8100, 10700, 13400, + 16100, 18800, 21400, 24100, + 26800, 29400, 32100, 34800, + 37400, 40100, 42800, 45400 ] + + - if: + properties: + compatible: + contains: + const: sophgo,sg2044-pinctrl + then: + patternProperties: + '-cfg$': + patternProperties: + '-pins$': + properties: + drive-strength-microamp: + enum: [ 3200, 6400, 9600, 12700, + 15900, 19100, 22200, 25300, + 29500, 32700, 35900, 39000, + 42000, 45200, 48300, 51400] + +additionalProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/pinctrl-sg2042.h> + + pinctrl@30011000 { + compatible = "sophgo,sg2042-pinctrl"; + reg = <30011000 0x1000>; + + uart0_cfg: uart0-cfg { + uart0-pins { + pinmux = <PINMUX(PIN_UART0_TX, 0)>, + <PINMUX(PIN_UART0_RX, 0)>; + bias-pull-up; + drive-strength-microamp = <13400>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml b/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml index 0735ceb7c103..9c34249b2d6d 100644 --- a/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml +++ b/Documentation/devicetree/bindings/power/reset/atmel,sama5d2-shdwc.yaml @@ -17,6 +17,11 @@ properties: compatible: oneOf: - items: + - enum: + - microchip,sama7d65-shdwc + - const: microchip,sama7g5-shdwc + - const: syscon + - items: - const: microchip,sama7g5-shdwc - const: syscon - enum: diff --git a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml index 799831636194..079ad977b907 100644 --- a/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml +++ b/Documentation/devicetree/bindings/power/reset/xlnx,zynqmp-power.yaml @@ -46,7 +46,6 @@ properties: required: - compatible - - interrupts additionalProperties: false diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max77705.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max77705.yaml new file mode 100644 index 000000000000..bce7fabbd9d3 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/maxim,max77705.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/maxim,max77705.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX777705 charger + +maintainers: + - Dzmitry Sankouski <dsankouski@gmail.com> + +description: | + This is a device tree bindings for charger found in Maxim MAX77705 chip. + +allOf: + - $ref: power-supply.yaml# + +properties: + compatible: + const: maxim,max77705-charger + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - monitored-battery + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + charger@69 { + compatible = "maxim,max77705-charger"; + reg = <0x69>; + monitored-battery = <&battery>; + interrupt-parent = <&pm8998_gpios>; + interrupts = <11 IRQ_TYPE_LEVEL_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml index 5ccd375eb294..3504c76a01d8 100644 --- a/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/x-powers,axp20x-battery-power-supply.yaml @@ -14,9 +14,6 @@ maintainers: - Chen-Yu Tsai <wens@csie.org> - Sebastian Reichel <sre@kernel.org> -allOf: - - $ref: power-supply.yaml# - properties: compatible: oneOf: @@ -35,7 +32,24 @@ properties: this gauge. $ref: /schemas/types.yaml#/definitions/phandle + x-powers,no-thermistor: + type: boolean + description: Indicates that no thermistor is connected to the TS pin + required: - compatible +allOf: + - $ref: power-supply.yaml# + - if: + not: + properties: + compatible: + contains: + enum: + - x-powers,axp717-battery-power-supply + then: + properties: + x-powers,no-thermistor: false + additionalProperties: false diff --git a/Documentation/devicetree/bindings/power/wakeup-source.txt b/Documentation/devicetree/bindings/power/wakeup-source.txt index 27f1797be963..66bb016305f9 100644 --- a/Documentation/devicetree/bindings/power/wakeup-source.txt +++ b/Documentation/devicetree/bindings/power/wakeup-source.txt @@ -23,7 +23,7 @@ List of legacy properties and respective binding document 1. "gpio-key,wakeup" Documentation/devicetree/bindings/input/gpio-keys{,-polled}.txt 2. "has-tpo" Documentation/devicetree/bindings/rtc/rtc-opal.txt -3. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt +3. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.yaml Documentation/devicetree/bindings/mfd/tc3589x.txt Documentation/devicetree/bindings/input/touchscreen/ti,ads7843.yaml 4. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8921-keypad.yaml diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt deleted file mode 100644 index c11ad5c6db21..000000000000 --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt +++ /dev/null @@ -1,204 +0,0 @@ -* Freescale DMA Controllers - -** Freescale Elo DMA Controller - This is a little-endian 4-channel DMA controller, used in Freescale mpc83xx - series chips such as mpc8315, mpc8349, mpc8379 etc. - -Required properties: - -- compatible : must include "fsl,elo-dma" -- reg : DMA General Status Register, i.e. DGSR which contains - status for all the 4 DMA channels -- ranges : describes the mapping between the address space of the - DMA channels and the address space of the DMA controller -- cell-index : controller index. 0 for controller @ 0x8100 -- interrupts : interrupt specifier for DMA IRQ - -- DMA channel nodes: - - compatible : must include "fsl,elo-dma-channel" - However, see note below. - - reg : DMA channel specific registers - - cell-index : DMA channel index starts at 0. - -Optional properties: - - interrupts : interrupt specifier for DMA channel IRQ - (on 83xx this is expected to be identical to - the interrupts property of the parent node) - -Example: - dma@82a8 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,mpc8349-dma", "fsl,elo-dma"; - reg = <0x82a8 4>; - ranges = <0 0x8100 0x1a4>; - interrupt-parent = <&ipic>; - interrupts = <71 8>; - cell-index = <0>; - dma-channel@0 { - compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; - cell-index = <0>; - reg = <0 0x80>; - interrupt-parent = <&ipic>; - interrupts = <71 8>; - }; - dma-channel@80 { - compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; - cell-index = <1>; - reg = <0x80 0x80>; - interrupt-parent = <&ipic>; - interrupts = <71 8>; - }; - dma-channel@100 { - compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; - cell-index = <2>; - reg = <0x100 0x80>; - interrupt-parent = <&ipic>; - interrupts = <71 8>; - }; - dma-channel@180 { - compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; - cell-index = <3>; - reg = <0x180 0x80>; - interrupt-parent = <&ipic>; - interrupts = <71 8>; - }; - }; - -** Freescale EloPlus DMA Controller - 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. - -Required properties: - -- compatible : must include "fsl,eloplus-dma" -- reg : DMA General Status Register, i.e. DGSR which contains - status for all the 4 DMA channels -- cell-index : controller index. 0 for controller @ 0x21000, - 1 for controller @ 0xc000 -- ranges : describes the mapping between the address space of the - DMA channels and the address space of the DMA controller - -- DMA channel nodes: - - compatible : must include "fsl,eloplus-dma-channel" - However, see note below. - - cell-index : DMA channel index starts at 0. - - reg : DMA channel specific registers - - interrupts : interrupt specifier for DMA channel IRQ - -Example: - dma@21300 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma"; - reg = <0x21300 4>; - 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>; - interrupt-parent = <&mpic>; - interrupts = <20 2>; - }; - dma-channel@80 { - compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; - reg = <0x80 0x80>; - cell-index = <1>; - interrupt-parent = <&mpic>; - interrupts = <21 2>; - }; - dma-channel@100 { - compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; - reg = <0x100 0x80>; - cell-index = <2>; - interrupt-parent = <&mpic>; - interrupts = <22 2>; - }; - dma-channel@180 { - compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; - reg = <0x180 0x80>; - cell-index = <3>; - interrupt-parent = <&mpic>; - interrupts = <23 2>; - }; - }; - -** Freescale Elo3 DMA Controller - 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. - -Required properties: - -- compatible : must include "fsl,elo3-dma" -- reg : contains two entries for DMA General Status Registers, - i.e. DGSR0 which includes status for channel 1~4, and - DGSR1 for channel 5~8 -- ranges : describes the mapping between the address space of the - DMA channels and the address space of the DMA controller - -- DMA channel nodes: - - compatible : must include "fsl,eloplus-dma-channel" - - reg : DMA channel specific registers - - interrupts : interrupt specifier for DMA channel IRQ - -Example: -dma@100300 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,elo3-dma"; - reg = <0x100300 0x4>, - <0x100600 0x4>; - ranges = <0x0 0x100100 0x500>; - dma-channel@0 { - compatible = "fsl,eloplus-dma-channel"; - reg = <0x0 0x80>; - interrupts = <28 2 0 0>; - }; - dma-channel@80 { - compatible = "fsl,eloplus-dma-channel"; - reg = <0x80 0x80>; - interrupts = <29 2 0 0>; - }; - dma-channel@100 { - compatible = "fsl,eloplus-dma-channel"; - reg = <0x100 0x80>; - interrupts = <30 2 0 0>; - }; - dma-channel@180 { - compatible = "fsl,eloplus-dma-channel"; - reg = <0x180 0x80>; - interrupts = <31 2 0 0>; - }; - dma-channel@300 { - compatible = "fsl,eloplus-dma-channel"; - reg = <0x300 0x80>; - interrupts = <76 2 0 0>; - }; - dma-channel@380 { - compatible = "fsl,eloplus-dma-channel"; - reg = <0x380 0x80>; - interrupts = <77 2 0 0>; - }; - dma-channel@400 { - compatible = "fsl,eloplus-dma-channel"; - reg = <0x400 0x80>; - interrupts = <78 2 0 0>; - }; - dma-channel@480 { - compatible = "fsl,eloplus-dma-channel"; - reg = <0x480 0x80>; - interrupts = <79 2 0 0>; - }; -}; - -Note on DMA channel compatible properties: The compatible property must say -"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA -driver (fsldma). Any DMA channel used by fsldma cannot be used by another -DMA driver, such as the SSI sound drivers for the MPC8610. Therefore, any DMA -channel that should be used for another driver should not use -"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel". For the SSI drivers, for -example, the compatible property should be "fsl,ssi-dma-channel". See ssi.txt -for more information. diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt b/Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt deleted file mode 100644 index 37f91fa57654..000000000000 --- a/Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt +++ /dev/null @@ -1,17 +0,0 @@ -Freescale MPC8349E-mITX-compatible Power Management Micro Controller Unit (MCU) - -Required properties: -- compatible : "fsl,<mcu-chip>-<board>", "fsl,mcu-mpc8349emitx". -- reg : should specify I2C address (0x0a). -- #gpio-cells : should be 2. -- gpio-controller : should be present. - -Example: - -mcu@a { - #gpio-cells = <2>; - compatible = "fsl,mc9s08qg8-mpc8349emitx", - "fsl,mcu-mpc8349emitx"; - reg = <0x0a>; - gpio-controller; -}; diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.yaml b/Documentation/devicetree/bindings/pps/pps-gpio.yaml index fd4adfa8d2d4..383a838744eb 100644 --- a/Documentation/devicetree/bindings/pps/pps-gpio.yaml +++ b/Documentation/devicetree/bindings/pps/pps-gpio.yaml @@ -36,14 +36,14 @@ additionalProperties: false examples: - | - #include <dt-bindings/gpio/gpio.h> - - pps { - compatible = "pps-gpio"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_pps>; - gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>; - assert-falling-edge; - echo-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>; - echo-active-ms = <100>; - }; + #include <dt-bindings/gpio/gpio.h> + + pps { + compatible = "pps-gpio"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pps>; + gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>; + assert-falling-edge; + echo-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>; + echo-active-ms = <100>; + }; diff --git a/Documentation/devicetree/bindings/regulator/samsung,s2mpu05.yaml b/Documentation/devicetree/bindings/regulator/samsung,s2mpu05.yaml new file mode 100644 index 000000000000..378518a5a7f5 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/samsung,s2mpu05.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/samsung,s2mpu05.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S2MPU05 Power Management IC regulators + +maintainers: + - Kaustabh Chakraborty <kauschluss@disroot.org> + +description: | + This is a part of device tree bindings for S2M and S5M family of Power + Management IC (PMIC). + + The S2MPU05 provides buck and LDO regulators. + + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for + additional information and example. + +patternProperties: + # 21 LDOs + "^ldo([1-9]|10|2[5-9]|3[0-5])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single LDO regulator. + + LDOs 11-24 are used for CP, and they're left unimplemented due to lack + of documentation on these regulators. + + required: + - regulator-name + + # 5 bucks + "^buck[1-5]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + Properties for single buck regulator. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml b/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml index 78e64521d401..7c64e588a8b5 100644 --- a/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml +++ b/Documentation/devicetree/bindings/regulator/ti,tps65219.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/regulator/ti,tps65219.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: TI tps65219 Power Management Integrated Circuit regulators +title: TI TPS65214/TPS65215/TPS65219 Power Management Integrated Circuit maintainers: - Jerome Neanne <jerome.neanne@baylibre.com> @@ -12,9 +12,20 @@ maintainers: description: | Regulator nodes should be named to buck<number> and ldo<number>. + TI TPS65219 is a Power Management IC with 3 Buck regulators, 4 Low + Drop-out Regulators (LDOs), 1 GPIO, 2 GPOs, and power-button. + + TI TPS65215 is a derivative of TPS65219 with 3 Buck regulators, 2 Low + Drop-out Regulators (LDOs), 1 GPIO, 1 GPO, and power-button. + + TI TPS65214 is a derivative of TPS65219 with 3 Buck regulators, 2 Low + Drop-out Regulators (LDOs), 1 GPIO, 1 GPO, and power-button. + properties: compatible: enum: + - ti,tps65214 + - ti,tps65215 - ti,tps65219 reg: @@ -90,6 +101,20 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + enum: + - ti,tps65214 + - ti,tps65215 + then: + properties: + regulators: + patternProperties: + "^ldo[3-4]$": false + examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml index 588b010b2a9e..c179b560572b 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml @@ -17,8 +17,10 @@ properties: compatible: oneOf: - enum: + - qcom,msm8226-mss-pil - qcom,msm8909-mss-pil - qcom,msm8916-mss-pil + - qcom,msm8926-mss-pil - qcom,msm8953-mss-pil - qcom,msm8974-mss-pil @@ -70,16 +72,18 @@ properties: items: - description: CX proxy power domain (control handed over after startup) - description: MX proxy power domain (control handed over after startup) + (not valid for qcom,msm8226-mss-pil, qcom,msm8926-mss-pil + and qcom,msm8974-mss-pil) - description: MSS proxy power domain (control handed over after startup) (only valid for qcom,msm8953-mss-pil) - minItems: 2 + minItems: 1 power-domain-names: items: - const: cx - - const: mx + - const: mx # not valid for qcom,msm8226-mss-pil, qcom-msm8926-mss-pil and qcom,msm8974-mss-pil - const: mss # only valid for qcom,msm8953-mss-pil - minItems: 2 + minItems: 1 pll-supply: description: PLL proxy supply (control handed over after startup) @@ -106,6 +110,15 @@ properties: items: - const: stop + qcom,ext-bhs-reg: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: External power block headswitch (BHS) register + (only valid for qcom,msm8226-mss-pil) + items: + - items: + - description: phandle to external BHS syscon region + - description: offset to the external BHS register + qcom,halt-regs: $ref: /schemas/types.yaml#/definitions/phandle-array description: @@ -207,17 +220,58 @@ allOf: required: - power-domains - power-domain-names - else: + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8909-mss-pil + - qcom,msm8916-mss-pil + then: properties: power-domains: + minItems: 2 maxItems: 2 power-domain-names: + minItems: 2 maxItems: 2 - if: properties: compatible: - const: qcom,msm8974-mss-pil + contains: + enum: + - qcom,msm8226-mss-pil + - qcom,msm8926-mss-pil + - qcom,msm8974-mss-pil + then: + properties: + power-domains: + maxItems: 1 + power-domain-names: + maxItems: 1 + required: + - mx-supply + + - if: + properties: + compatible: + const: qcom,msm8226-mss-pil + then: + required: + - qcom,ext-bhs-reg + else: + properties: + qcom,ext-bhs-reg: false + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8926-mss-pil + - qcom,msm8974-mss-pil then: required: - mss-supply diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml deleted file mode 100644 index 45ee9fbe0966..000000000000 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc8180x-pas.yaml +++ /dev/null @@ -1,96 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/remoteproc/qcom,sc8180x-pas.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Qualcomm SC8180X Peripheral Authentication Service - -maintainers: - - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> - -description: - Qualcomm SC8180X SoC Peripheral Authentication Service loads and boots - firmware on the Qualcomm DSP Hexagon cores. - -properties: - compatible: - enum: - - qcom,sc8180x-adsp-pas - - qcom,sc8180x-cdsp-pas - - qcom,sc8180x-mpss-pas - - reg: - maxItems: 1 - - clocks: - items: - - description: XO clock - - clock-names: - items: - - const: xo - - qcom,qmp: - $ref: /schemas/types.yaml#/definitions/phandle - description: Reference to the AOSS side-channel message RAM. - - smd-edge: false - - memory-region: - maxItems: 1 - description: Reference to the reserved-memory for the Hexagon core - - firmware-name: - maxItems: 1 - description: Firmware name for the Hexagon core - -required: - - compatible - - reg - - memory-region - -allOf: - - $ref: /schemas/remoteproc/qcom,pas-common.yaml# - - if: - properties: - compatible: - enum: - - qcom,sc8180x-adsp-pas - - qcom,sc8180x-cdsp-pas - then: - properties: - interrupts: - maxItems: 5 - interrupt-names: - maxItems: 5 - else: - properties: - interrupts: - minItems: 6 - interrupt-names: - minItems: 6 - - - if: - properties: - compatible: - enum: - - qcom,sc8180x-adsp-pas - - qcom,sc8180x-cdsp-pas - then: - properties: - power-domains: - items: - - description: LCX power domain - - description: LMX power domain - power-domain-names: - items: - - const: lcx - - const: lmx - else: - properties: - # TODO: incomplete - power-domains: false - power-domain-names: false - -unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml index 059cb87b4d6c..eeb6a8aafeb9 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm6115-pas.yaml @@ -127,7 +127,7 @@ examples: clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>; clock-names = "xo"; - firmware-name = "qcom/sm6115/adsp.mdt"; + firmware-name = "qcom/sm6115/adsp.mbn"; interrupts-extended = <&intc GIC_SPI 282 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml index d67386c50fa4..56ff6386534d 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8150-pas.yaml @@ -60,6 +60,9 @@ allOf: properties: compatible: enum: + - qcom,sc8180x-adsp-pas + - qcom,sc8180x-cdsp-pas + - qcom,sc8180x-slpi-pas - qcom,sm8150-adsp-pas - qcom,sm8150-cdsp-pas - qcom,sm8150-slpi-pas @@ -83,6 +86,8 @@ allOf: properties: compatible: enum: + - qcom,sc8180x-adsp-pas + - qcom,sc8180x-cdsp-pas - qcom,sm8150-adsp-pas - qcom,sm8150-cdsp-pas - qcom,sm8250-cdsp-pas @@ -99,6 +104,7 @@ allOf: properties: compatible: enum: + - qcom,sc8180x-mpss-pas - qcom,sm8150-mpss-pas then: properties: @@ -115,6 +121,7 @@ allOf: properties: compatible: enum: + - qcom,sc8180x-slpi-pas - qcom,sm8150-slpi-pas - qcom,sm8250-adsp-pas - qcom,sm8250-slpi-pas diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml index a24cbb61bda7..2dd479cf4821 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml @@ -24,11 +24,15 @@ properties: - qcom,sm8650-adsp-pas - qcom,sm8650-cdsp-pas - qcom,sm8650-mpss-pas + - qcom,sm8750-mpss-pas - qcom,x1e80100-adsp-pas - qcom,x1e80100-cdsp-pas - items: - const: qcom,sm8750-adsp-pas - const: qcom,sm8550-adsp-pas + - items: + - const: qcom,sm8750-cdsp-pas + - const: qcom,sm8650-cdsp-pas reg: maxItems: 1 @@ -114,6 +118,23 @@ allOf: memory-region: minItems: 3 maxItems: 3 + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8750-cdsp-pas + then: + properties: + interrupts: + maxItems: 6 + interrupt-names: + maxItems: 6 + memory-region: + minItems: 3 + maxItems: 3 + - if: properties: compatible: @@ -147,6 +168,21 @@ allOf: - if: properties: compatible: + enum: + - qcom,sm8750-mpss-pas + then: + properties: + interrupts: + minItems: 6 + interrupt-names: + minItems: 6 + memory-region: + minItems: 4 + maxItems: 4 + + - if: + properties: + compatible: contains: enum: - qcom,sm8550-adsp-pas @@ -171,6 +207,7 @@ allOf: - qcom,sdx75-mpss-pas - qcom,sm8550-mpss-pas - qcom,sm8650-mpss-pas + - qcom,sm8750-mpss-pas then: properties: power-domains: @@ -184,10 +221,11 @@ allOf: - if: properties: compatible: - enum: - - qcom,sm8550-cdsp-pas - - qcom,sm8650-cdsp-pas - - qcom,x1e80100-cdsp-pas + contains: + enum: + - qcom,sm8550-cdsp-pas + - qcom,sm8650-cdsp-pas + - qcom,x1e80100-cdsp-pas then: properties: power-domains: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml index 8e033b22d28c..117fb4d0c4ad 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml @@ -69,9 +69,11 @@ properties: CX regulator to be held on behalf of the booting of the WCNSS core. power-domains: + minItems: 1 maxItems: 2 power-domain-names: + minItems: 1 items: - const: cx - const: mx @@ -187,22 +189,43 @@ allOf: - qcom,pronto-v1-pil - qcom,pronto-v2-pil then: - properties: - vddmx-supply: - deprecated: true - description: Deprecated for qcom,pronto-v1/2-pil - - vddcx-supply: - deprecated: true - description: Deprecated for qcom,pronto-v1/2-pil - + # CX and MX must be present either as power domains or regulators oneOf: + # Both CX and MX represented as power domains - required: - power-domains - power-domain-names + properties: + power-domains: + minItems: 2 + power-domain-names: + minItems: 2 + vddmx-supply: false + vddcx-supply: false + # CX represented as power domain, MX as regulator + - required: + - power-domains + - power-domain-names + - vddmx-supply + properties: + power-domains: + maxItems: 1 + power-domain-names: + maxItems: 1 + vddcx-supply: false + # Both CX and MX represented as regulators - required: - vddmx-supply - vddcx-supply + properties: + power-domains: false + power-domain-names: false + vddmx-supply: + deprecated: true + description: Deprecated for qcom,pronto-v1/2-pil + vddcx-supply: + deprecated: true + description: Deprecated for qcom,pronto-v1/2-pil - if: properties: @@ -212,6 +235,10 @@ allOf: - qcom,pronto-v3-pil then: properties: + power-domains: + minItems: 2 + power-domain-names: + minItems: 2 vddmx-supply: false vddcx-supply: false diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml index a63b994e0763..bcab59e0cc2e 100644 --- a/Documentation/devicetree/bindings/riscv/extensions.yaml +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml @@ -224,6 +224,12 @@ properties: as ratified at commit 4a69197e5617 ("Update to ratified state") of riscv-svvptc. + - const: zaamo + description: | + The standard Zaamo extension for atomic memory operations as + ratified at commit e87412e621f1 ("integrate Zaamo and Zalrsc text + (#1304)") of the unprivileged ISA specification. + - const: zabha description: | The Zabha extension for Byte and Halfword Atomic Memory Operations @@ -236,6 +242,12 @@ properties: is supported as ratified at commit 5059e0ca641c ("update to ratified") of the riscv-zacas. + - const: zalrsc + description: | + The standard Zalrsc extension for load-reserved/store-conditional as + ratified at commit e87412e621f1 ("integrate Zaamo and Zalrsc text + (#1304)") of the unprivileged ISA specification. + - const: zawrs description: | The Zawrs extension for entering a low-power state or for trapping @@ -329,6 +341,12 @@ properties: instructions, as ratified in commit 056b6ff ("Zfa is ratified") of riscv-isa-manual. + - const: zfbfmin + description: + The standard Zfbfmin extension which provides minimal support for + 16-bit half-precision brain floating-point instructions, as ratified + in commit 4dc23d62 ("Added Chapter title to BF16") of riscv-isa-manual. + - const: zfh description: The standard Zfh extension for 16-bit half-precision binary @@ -525,6 +543,18 @@ properties: in commit 6f702a2 ("Vector extensions are now ratified") of riscv-v-spec. + - const: zvfbfmin + description: + The standard Zvfbfmin extension for minimal support for vectored + 16-bit half-precision brain floating-point instructions, as ratified + in commit 4dc23d62 ("Added Chapter title to BF16") of riscv-isa-manual. + + - const: zvfbfwma + description: + The standard Zvfbfwma extension for vectored half-precision brain + floating-point widening multiply-accumulate instructions, as ratified + in commit 4dc23d62 ("Added Chapter title to BF16") of riscv-isa-manual. + - const: zvfh description: The standard Zvfh extension for vectored half-precision @@ -639,6 +669,12 @@ properties: https://github.com/T-head-Semi/thead-extension-spec/blob/95358cb2cca9489361c61d335e03d3134b14133f/xtheadvector.adoc. allOf: + - if: + contains: + const: d + then: + contains: + const: f # Zcb depends on Zca - if: contains: @@ -673,6 +709,119 @@ properties: then: contains: const: zca + # Zfbfmin depends on F + - if: + contains: + const: zfbfmin + then: + contains: + const: f + # Zvfbfmin depends on V or Zve32f + - if: + contains: + const: zvfbfmin + then: + oneOf: + - contains: + const: v + - contains: + const: zve32f + # Zvfbfwma depends on Zfbfmin and Zvfbfmin + - if: + contains: + const: zvfbfwma + then: + allOf: + - contains: + const: zfbfmin + - contains: + const: zvfbfmin + # Zacas depends on Zaamo + - if: + contains: + const: zacas + then: + contains: + const: zaamo + + - if: + contains: + const: zve32x + then: + contains: + const: zicsr + + - if: + contains: + const: zve32f + then: + allOf: + - contains: + const: f + - contains: + const: zve32x + + - if: + contains: + const: zve64x + then: + contains: + const: zve32x + + - if: + contains: + const: zve64f + then: + allOf: + - contains: + const: f + - contains: + const: zve32f + - contains: + const: zve64x + + - if: + contains: + const: zve64d + then: + allOf: + - contains: + const: d + - contains: + const: zve64f + + - if: + contains: + anyOf: + - const: zvbc + - const: zvkn + - const: zvknc + - const: zvkng + - const: zvknhb + - const: zvksc + then: + contains: + anyOf: + - const: v + - const: zve64x + + - if: + contains: + anyOf: + - const: zvbb + - const: zvkb + - const: zvkg + - const: zvkned + - const: zvknha + - const: zvksed + - const: zvksh + - const: zvks + - const: zvkt + then: + contains: + anyOf: + - const: v + - const: zve32x allOf: # Zcf extension does not exist on rv64 diff --git a/Documentation/devicetree/bindings/rng/rockchip,rk3588-rng.yaml b/Documentation/devicetree/bindings/rng/rockchip,rk3588-rng.yaml new file mode 100644 index 000000000000..ca71b400bcae --- /dev/null +++ b/Documentation/devicetree/bindings/rng/rockchip,rk3588-rng.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/rockchip,rk3588-rng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3588 TRNG + +description: True Random Number Generator on Rockchip RK3588 SoC + +maintainers: + - Nicolas Frattaroli <nicolas.frattaroli@collabora.com> + +properties: + compatible: + enum: + - rockchip,rk3588-rng + + reg: + maxItems: 1 + + clocks: + items: + - description: TRNG AHB clock + + interrupts: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rockchip,rk3588-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/reset/rockchip,rk3588-cru.h> + bus { + #address-cells = <2>; + #size-cells = <2>; + + rng@fe378000 { + compatible = "rockchip,rk3588-rng"; + reg = <0x0 0xfe378000 0x0 0x200>; + interrupts = <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&scmi_clk SCMI_HCLK_SECURE_NS>; + resets = <&scmi_reset SCMI_SRST_H_TRNG_NS>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/rtc/adi,max31335.yaml b/Documentation/devicetree/bindings/rtc/adi,max31335.yaml index 0125cf6727cc..bce7558d0d87 100644 --- a/Documentation/devicetree/bindings/rtc/adi,max31335.yaml +++ b/Documentation/devicetree/bindings/rtc/adi,max31335.yaml @@ -18,7 +18,9 @@ allOf: properties: compatible: - const: adi,max31335 + enum: + - adi,max31331 + - adi,max31335 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml index 2d9fe5a75b06..11fcf0ca1ae0 100644 --- a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml @@ -8,6 +8,7 @@ title: NXP PCF2127 Real Time Clock allOf: - $ref: rtc.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# maintainers: - Alexandre Belloni <alexandre.belloni@bootlin.com> @@ -34,7 +35,7 @@ required: - compatible - reg -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml index d274bb7a534b..68ef3208c886 100644 --- a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml @@ -50,6 +50,11 @@ properties: items: - const: offset + qcom,no-alarm: + type: boolean + description: + RTC alarm is not owned by the OS + wakeup-source: true required: diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml index 0bde2379e864..dc0d52920575 100644 --- a/Documentation/devicetree/bindings/serial/8250.yaml +++ b/Documentation/devicetree/bindings/serial/8250.yaml @@ -77,7 +77,6 @@ properties: - altr,16550-FIFO64 - altr,16550-FIFO128 - fsl,16550-FIFO64 - - fsl,ns16550 - andestech,uart16550 - nxp,lpc1850-uart - opencores,uart16550-rtlsvn105 @@ -86,6 +85,7 @@ properties: - items: - enum: - ns16750 + - fsl,ns16550 - cavium,octeon-3860-uart - xlnx,xps-uart16550-2.00.b - ralink,rt2880-uart diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml index 3f9ace89dee9..c42261b5a80a 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml @@ -30,6 +30,7 @@ properties: - items: - enum: - fsl,imx93-lpuart + - fsl,imx94-lpuart - fsl,imx95-lpuart - const: fsl,imx8ulp-lpuart - const: fsl,imx7ulp-lpuart diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra264-utc.yaml b/Documentation/devicetree/bindings/serial/nvidia,tegra264-utc.yaml new file mode 100644 index 000000000000..572cc574da64 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/nvidia,tegra264-utc.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/nvidia,tegra264-utc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra UTC (UART Trace Controller) client + +maintainers: + - Kartik Rajput <kkartik@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + - Jonathan Hunter <jonathanh@nvidia.com> + +description: + Represents a client interface of the Tegra UTC (UART Trace Controller). The + Tegra UTC allows multiple clients within the Tegra SoC to share a physical + UART interface. It supports up to 16 clients. Each client operates as an + independent UART endpoint with a dedicated interrupt and 128-character TX/RX + FIFOs. + + The Tegra UTC clients use 8-N-1 configuration and operates on a baudrate + configured by the bootloader at the controller level. + +allOf: + - $ref: serial.yaml# + +properties: + compatible: + const: nvidia,tegra264-utc + + reg: + items: + - description: TX region. + - description: RX region. + + reg-names: + items: + - const: tx + - const: rx + + interrupts: + maxItems: 1 + + tx-threshold: + minimum: 1 + maximum: 128 + + rx-threshold: + minimum: 1 + maximum: 128 + +required: + - compatible + - reg + - reg-names + - interrupts + - tx-threshold + - rx-threshold + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + tegra_utc: serial@c4e0000 { + compatible = "nvidia,tegra264-utc"; + reg = <0xc4e0000 0x8000>, <0xc4e8000 0x8000>; + reg-names = "tx", "rx"; + interrupts = <GIC_SPI 514 IRQ_TYPE_LEVEL_HIGH>; + tx-threshold = <4>; + rx-threshold = <4>; + }; diff --git a/Documentation/devicetree/bindings/serial/pl011.yaml b/Documentation/devicetree/bindings/serial/pl011.yaml index 9571041030b7..3fcf2d042372 100644 --- a/Documentation/devicetree/bindings/serial/pl011.yaml +++ b/Documentation/devicetree/bindings/serial/pl011.yaml @@ -92,6 +92,9 @@ properties: 3000ms. default: 3000 + power-domains: + maxItems: 1 + resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml index 070eba9f19d3..83d9986d8e98 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml @@ -42,6 +42,10 @@ properties: - samsung,exynosautov9-uart - samsung,exynosautov920-uart - const: samsung,exynos850-uart + - items: + - enum: + - samsung,exynos7870-uart + - const: samsung,exynos8895-uart reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml index 1c163cb5dff1..1aa3480d8d81 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml @@ -16,6 +16,20 @@ allOf: - if: properties: compatible: + items: + - enum: + - renesas,r9a06g032-uart + - renesas,r9a06g033-uart + - const: renesas,rzn1-uart + - const: snps,dw-apb-uart + then: + properties: + dmas: false + dma-names: false + + - if: + properties: + compatible: contains: const: starfive,jh7110-uart then: @@ -35,6 +49,12 @@ properties: - renesas,r9a06g032-uart - renesas,r9a06g033-uart - const: renesas,rzn1-uart + - const: snps,dw-apb-uart + - items: + - enum: + - renesas,r9a06g032-uart + - renesas,r9a06g033-uart + - const: renesas,rzn1-uart - items: - enum: - brcm,bcm11351-dw-apb-uart @@ -51,6 +71,7 @@ properties: - rockchip,rk3368-uart - rockchip,rk3399-uart - rockchip,rk3528-uart + - rockchip,rk3562-uart - rockchip,rk3568-uart - rockchip,rk3576-uart - rockchip,rk3588-uart diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.yaml b/Documentation/devicetree/bindings/serial/sprd-uart.yaml index a2a5056eba04..5bf2656afcfd 100644 --- a/Documentation/devicetree/bindings/serial/sprd-uart.yaml +++ b/Documentation/devicetree/bindings/serial/sprd-uart.yaml @@ -17,13 +17,18 @@ properties: oneOf: - items: - enum: - - sprd,sc9632-uart + - sprd,ums9632-uart + - const: sprd,sc9632-uart + - items: + - enum: - sprd,sc9860-uart - sprd,sc9863a-uart - sprd,ums512-uart - sprd,ums9620-uart - const: sprd,sc9836-uart - - const: sprd,sc9836-uart + - enum: + - sprd,sc9632-uart + - sprd,sc9836-uart reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,aips-bus.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,aips-bus.yaml index 80d99861fec5..70a4af650110 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,aips-bus.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,aips-bus.yaml @@ -22,6 +22,9 @@ select: required: - compatible +allOf: + - $ref: /schemas/simple-bus.yaml# + properties: compatible: items: @@ -35,7 +38,7 @@ required: - compatible - reg -additionalProperties: true +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/submitting-patches.rst b/Documentation/devicetree/bindings/submitting-patches.rst index a64f21a5f299..f3e23e69a638 100644 --- a/Documentation/devicetree/bindings/submitting-patches.rst +++ b/Documentation/devicetree/bindings/submitting-patches.rst @@ -54,11 +54,22 @@ I. For patch submitters followed as of commit bff5da4335256513497cc8c79f9a9d1665e09864 ("checkpatch: add DT compatible string documentation checks"). ] - 7) If a documented compatible string is not yet matched by the + 7) DTS is treated in general as driver-independent hardware description, thus + any DTS patches, regardless whether using existing or new bindings, should + be placed at the end of patchset to indicate no dependency of drivers on + the DTS. DTS will be anyway applied through separate tree or branch, so + different order would indicate the serie is non-bisectable. + + If a driver subsystem maintainer prefers to apply entire set, instead of + their relevant portion of patchset, please split the DTS patches into + separate patchset with a reference in changelog or cover letter to the + bindings submission on the mailing list. + + 8) If a documented compatible string is not yet matched by the driver, the documentation should also include a compatible string that is matched by the driver. - 8) Bindings are actively used by multiple projects other than the Linux + 9) Bindings are actively used by multiple projects other than the Linux Kernel, extra care and consideration may need to be taken when making changes to existing bindings. @@ -79,6 +90,10 @@ II. For kernel maintainers 3) For a series going though multiple trees, the binding patch should be kept with the driver using the binding. + 4) The DTS files should however never be applied via driver subsystem tree, + but always via platform SoC trees on dedicated branches (see also + Documentation/process/maintainer-soc.rst). + III. Notes ========== diff --git a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml index dad8de900495..3e61689f6dd4 100644 --- a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml +++ b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml @@ -142,38 +142,38 @@ unevaluatedProperties: false examples: - | thermal-sensor@1f04000 { - compatible = "allwinner,sun8i-a83t-ths"; - reg = <0x01f04000 0x100>; - interrupts = <0 31 0>; - nvmem-cells = <&ths_calibration>; - nvmem-cell-names = "calibration"; - #thermal-sensor-cells = <1>; + compatible = "allwinner,sun8i-a83t-ths"; + reg = <0x01f04000 0x100>; + interrupts = <0 31 0>; + nvmem-cells = <&ths_calibration>; + nvmem-cell-names = "calibration"; + #thermal-sensor-cells = <1>; }; - | thermal-sensor@1c25000 { - compatible = "allwinner,sun8i-h3-ths"; - reg = <0x01c25000 0x400>; - clocks = <&ccu 0>, <&ccu 1>; - clock-names = "bus", "mod"; - resets = <&ccu 2>; - interrupts = <0 31 0>; - nvmem-cells = <&ths_calibration>; - nvmem-cell-names = "calibration"; - #thermal-sensor-cells = <0>; + compatible = "allwinner,sun8i-h3-ths"; + reg = <0x01c25000 0x400>; + clocks = <&ccu 0>, <&ccu 1>; + clock-names = "bus", "mod"; + resets = <&ccu 2>; + interrupts = <0 31 0>; + nvmem-cells = <&ths_calibration>; + nvmem-cell-names = "calibration"; + #thermal-sensor-cells = <0>; }; - | thermal-sensor@5070400 { - compatible = "allwinner,sun50i-h6-ths"; - reg = <0x05070400 0x100>; - clocks = <&ccu 0>; - clock-names = "bus"; - resets = <&ccu 2>; - interrupts = <0 15 0>; - nvmem-cells = <&ths_calibration>; - nvmem-cell-names = "calibration"; - #thermal-sensor-cells = <1>; + compatible = "allwinner,sun50i-h6-ths"; + reg = <0x05070400 0x100>; + clocks = <&ccu 0>; + clock-names = "bus"; + resets = <&ccu 2>; + interrupts = <0 15 0>; + nvmem-cells = <&ths_calibration>; + nvmem-cell-names = "calibration"; + #thermal-sensor-cells = <1>; }; ... diff --git a/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.yaml b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.yaml index 081486b44382..2f62551a49c1 100644 --- a/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.yaml +++ b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.yaml @@ -18,6 +18,7 @@ properties: compatible: items: - enum: + - brcm,avs-tmon-bcm74110 - brcm,avs-tmon-bcm7216 - brcm,avs-tmon-bcm7445 - const: brcm,avs-tmon diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml index 337560562337..949b154856c5 100644 --- a/Documentation/devicetree/bindings/thermal/imx-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/imx-thermal.yaml @@ -80,19 +80,19 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> efuse@21bc000 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,imx6sx-ocotp", "syscon"; - reg = <0x021bc000 0x4000>; - clocks = <&clks IMX6SX_CLK_OCOTP>; - - tempmon_calib: calib@38 { - reg = <0x38 4>; - }; - - tempmon_temp_grade: temp-grade@20 { - reg = <0x20 4>; - }; + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,imx6sx-ocotp", "syscon"; + reg = <0x021bc000 0x4000>; + clocks = <&clks IMX6SX_CLK_OCOTP>; + + tempmon_calib: calib@38 { + reg = <0x38 4>; + }; + + tempmon_temp_grade: temp-grade@20 { + reg = <0x20 4>; + }; }; anatop@20c8000 { @@ -103,12 +103,12 @@ examples: <0 127 IRQ_TYPE_LEVEL_HIGH>; tempmon { - compatible = "fsl,imx6sx-tempmon"; - interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; - fsl,tempmon = <&anatop>; - nvmem-cells = <&tempmon_calib>, <&tempmon_temp_grade>; - nvmem-cell-names = "calib", "temp_grade"; - clocks = <&clks IMX6SX_CLK_PLL3_USB_OTG>; - #thermal-sensor-cells = <0>; + compatible = "fsl,imx6sx-tempmon"; + interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; + fsl,tempmon = <&anatop>; + nvmem-cells = <&tempmon_calib>, <&tempmon_temp_grade>; + nvmem-cell-names = "calib", "temp_grade"; + clocks = <&clks IMX6SX_CLK_PLL3_USB_OTG>; + #thermal-sensor-cells = <0>; }; }; diff --git a/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml b/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml index bef0e95e7416..df6c7c5d519f 100644 --- a/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml @@ -63,10 +63,10 @@ examples: #include <dt-bindings/clock/imx8mm-clock.h> thermal-sensor@30260000 { - compatible = "fsl,imx8mm-tmu"; - reg = <0x30260000 0x10000>; - clocks = <&clk IMX8MM_CLK_TMU_ROOT>; - #thermal-sensor-cells = <0>; + compatible = "fsl,imx8mm-tmu"; + reg = <0x30260000 0x10000>; + clocks = <&clk IMX8MM_CLK_TMU_ROOT>; + #thermal-sensor-cells = <0>; }; ... diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index b9829bb22cc0..f9d8012c8cf5 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -75,6 +75,8 @@ properties: - description: v2 of TSENS with combined interrupt enum: + - qcom,ipq5332-tsens + - qcom,ipq5424-tsens - qcom,ipq8074-tsens - description: v2 of TSENS with combined interrupt @@ -212,6 +214,18 @@ properties: - const: s9_p2_backup - const: s10_p1_backup - const: s10_p2_backup + - minItems: 8 + items: + - const: mode + - const: base0 + - const: base1 + - pattern: '^tsens_sens[0-9]+_off$' + - pattern: '^tsens_sens[0-9]+_off$' + - pattern: '^tsens_sens[0-9]+_off$' + - pattern: '^tsens_sens[0-9]+_off$' + - pattern: '^tsens_sens[0-9]+_off$' + - pattern: '^tsens_sens[0-9]+_off$' + - pattern: '^tsens_sens[0-9]+_off$' "#qcom,sensors": description: @@ -271,6 +285,8 @@ allOf: compatible: contains: enum: + - qcom,ipq5332-tsens + - qcom,ipq5424-tsens - qcom,ipq8074-tsens then: properties: @@ -286,6 +302,8 @@ allOf: compatible: contains: enum: + - qcom,ipq5332-tsens + - qcom,ipq5424-tsens - qcom,ipq8074-tsens - qcom,tsens-v0_1 - qcom,tsens-v1 diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml index 0f435be1dbd8..0de0a9757ccc 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml @@ -82,9 +82,8 @@ patternProperties: $ref: /schemas/types.yaml#/definitions/string description: | The action the OS should perform after the critical temperature is reached. - By default the system will shutdown as a safe action to prevent damage - to the hardware, if the property is not set. - The shutdown action should be always the default and preferred one. + If the property is not set, it is up to the system to select the correct + action. The recommended and preferred default is shutdown. Choose 'reboot' with care, as the hardware may be in thermal stress, thus leading to infinite reboots that may cause damage to the hardware. Make sure the firmware/bootloader will act as the last resort and take diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 30e8f89fa032..8da408107e55 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -185,8 +185,16 @@ properties: - maxim,max5484 # PECI-to-I2C translator for PECI-to-SMBus/I2C protocol conversion - maxim,max6621 + # InTune Automatically Compensated Digital PoL Controller with Driver and PMBus Telemetry + - maxim,max15301 + # 6A InTune Automatically Compensated Converter with PMBus Telemetry + - maxim,max15303 + # Multiphase Master with PMBus Interface and Internal Buck Converter + - maxim,max20751 # mCube 3-axis 8-bit digital accelerometer - mcube,mc3230 + # mCube 3-axis 8-bit digital accelerometer + - mcube,mc3510c # Measurement Specialities I2C temperature and humidity sensor - meas,htu21 # Measurement Specialities I2C temperature and humidity sensor @@ -382,6 +390,8 @@ properties: - ti,tps53676 # TI Dual channel DCAP+ multiphase controller TPS53679 - ti,tps53679 + # TI Dual channel DCAP+ multiphase controller TPS53681 + - ti,tps53681 # TI Dual channel DCAP+ multiphase controller TPS53688 - ti,tps53688 # TI DC-DC converters on PMBus @@ -389,6 +399,7 @@ properties: - ti,tps544b25 - ti,tps544c20 - ti,tps544c25 + - ti,tps546b24 - ti,tps546d24 # I2C Touch-Screen Controller - ti,tsc2003 diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml b/Documentation/devicetree/bindings/usb/generic-xhci.yaml index 6ceafa4af292..a2b94a138999 100644 --- a/Documentation/devicetree/bindings/usb/generic-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml @@ -51,6 +51,8 @@ properties: - const: core - const: reg + dma-coherent: true + power-domains: maxItems: 1 diff --git a/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml index b14e6f37b298..4e3901efed3f 100644 --- a/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml +++ b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml @@ -9,16 +9,19 @@ title: Microchip USB2514 Hub Controller maintainers: - Fabio Estevam <festevam@gmail.com> -allOf: - - $ref: usb-device.yaml# - properties: compatible: - enum: - - usb424,2412 - - usb424,2417 - - usb424,2514 - - usb424,2517 + oneOf: + - enum: + - usb424,2412 + - usb424,2417 + - usb424,2514 + - usb424,2517 + - items: + - enum: + - usb424,2512 + - usb424,2513 + - const: usb424,2514 reg: true @@ -28,6 +31,9 @@ properties: vdd-supply: description: 3.3V power supply. + vdda-supply: + description: 3.3V analog power supply. + clocks: description: External 24MHz clock connected to the CLKIN pin. maxItems: 1 @@ -43,6 +49,18 @@ patternProperties: $ref: /schemas/usb/usb-device.yaml additionalProperties: true +allOf: + - $ref: usb-device.yaml# + - if: + not: + properties: + compatible: + contains: + const: usb424,2514 + then: + properties: + vdda-supply: false + unevaluatedProperties: false examples: @@ -60,6 +78,7 @@ examples: clocks = <&clks IMX6QDL_CLK_CKO>; reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>; vdd-supply = <®_3v3_hub>; + vdda-supply = <®_3v3a_hub>; #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/usb/parade,ps8830.yaml b/Documentation/devicetree/bindings/usb/parade,ps8830.yaml new file mode 100644 index 000000000000..935d57f5d26f --- /dev/null +++ b/Documentation/devicetree/bindings/usb/parade,ps8830.yaml @@ -0,0 +1,140 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/parade,ps8830.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Parade PS883x USB and DisplayPort Retimer + +maintainers: + - Abel Vesa <abel.vesa@linaro.org> + +properties: + compatible: + enum: + - parade,ps8830 + + reg: + maxItems: 1 + + clocks: + items: + - description: XO Clock + + reset-gpios: + maxItems: 1 + + vdd-supply: + description: power supply (1.07V) + + vdd33-supply: + description: power supply (3.3V) + + vdd33-cap-supply: + description: power supply (3.3V) + + vddar-supply: + description: power supply (1.07V) + + vddat-supply: + description: power supply (1.07V) + + vddio-supply: + description: power supply (1.2V or 1.8V) + + orientation-switch: true + retimer-switch: true + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Super Speed (SS) Output endpoint to the Type-C connector + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + description: Super Speed (SS) Input endpoint from the Super-Speed PHY + unevaluatedProperties: false + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: + Sideband Use (SBU) AUX lines endpoint to the Type-C connector for the purpose of + handling altmode muxing and orientation switching. + +required: + - compatible + - reg + - clocks + - reset-gpios + - vdd-supply + - vdd33-supply + - vdd33-cap-supply + - vddat-supply + - vddio-supply + - orientation-switch + - retimer-switch + +allOf: + - $ref: usb-switch.yaml# + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + typec-mux@8 { + compatible = "parade,ps8830"; + reg = <0x8>; + + clocks = <&clk_rtmr_xo>; + + vdd-supply = <&vreg_rtmr_1p15>; + vdd33-supply = <&vreg_rtmr_3p3>; + vdd33-cap-supply = <&vreg_rtmr_3p3>; + vddar-supply = <&vreg_rtmr_1p15>; + vddat-supply = <&vreg_rtmr_1p15>; + vddio-supply = <&vreg_rtmr_1p8>; + + reset-gpios = <&tlmm 10 GPIO_ACTIVE_LOW>; + + retimer-switch; + orientation-switch; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + endpoint { + remote-endpoint = <&typec_con_ss>; + }; + }; + + port@1 { + reg = <1>; + + endpoint { + remote-endpoint = <&usb_phy_ss>; + }; + }; + + port@2 { + reg = <2>; + + endpoint { + remote-endpoint = <&typec_dp_aux>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index a2b3cf625e5b..64137c1619a6 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -404,6 +404,7 @@ allOf: minItems: 2 maxItems: 3 interrupt-names: + minItems: 2 items: - const: pwr_event - const: qusb2_phy @@ -425,6 +426,7 @@ allOf: minItems: 3 maxItems: 4 interrupt-names: + minItems: 3 items: - const: pwr_event - const: qusb2_phy diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml index 8da4d2ad1a91..ae611f7e57ca 100644 --- a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml +++ b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml @@ -30,6 +30,9 @@ properties: interrupts: maxItems: 1 + vbus-supply: + description: VBUS power supply + wakeup-source: type: boolean diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml b/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml index a21cc098542d..fba2cb05ecba 100644 --- a/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml @@ -26,6 +26,7 @@ select: contains: enum: - rockchip,rk3328-dwc3 + - rockchip,rk3562-dwc3 - rockchip,rk3568-dwc3 - rockchip,rk3576-dwc3 - rockchip,rk3588-dwc3 @@ -37,6 +38,7 @@ properties: items: - enum: - rockchip,rk3328-dwc3 + - rockchip,rk3562-dwc3 - rockchip,rk3568-dwc3 - rockchip,rk3576-dwc3 - rockchip,rk3588-dwc3 @@ -72,6 +74,7 @@ properties: - enum: - grf_clk - utmi + - pipe - const: pipe power-domains: @@ -115,6 +118,22 @@ allOf: properties: compatible: contains: + const: rockchip,rk3562-dwc3 + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + clock-names: + items: + - const: ref_clk + - const: suspend_clk + - const: bus_clk + - const: pipe + - if: + properties: + compatible: + contains: enum: - rockchip,rk3568-dwc3 - rockchip,rk3576-dwc3 diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml index 2b3430cebe99..256bee2a03ca 100644 --- a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml @@ -11,12 +11,17 @@ maintainers: properties: compatible: - enum: - - google,gs101-dwusb3 - - samsung,exynos5250-dwusb3 - - samsung,exynos5433-dwusb3 - - samsung,exynos7-dwusb3 - - samsung,exynos850-dwusb3 + oneOf: + - enum: + - google,gs101-dwusb3 + - samsung,exynos5250-dwusb3 + - samsung,exynos5433-dwusb3 + - samsung,exynos7-dwusb3 + - samsung,exynos7870-dwusb3 + - samsung,exynos850-dwusb3 + - items: + - const: samsung,exynos990-dwusb3 + - const: samsung,exynos850-dwusb3 '#address-cells': const: 1 @@ -52,7 +57,6 @@ required: - clock-names - ranges - '#size-cells' - - vdd10-supply - vdd33-supply allOf: @@ -72,6 +76,8 @@ allOf: - const: susp_clk - const: link_aclk - const: link_pclk + required: + - vdd10-supply - if: properties: @@ -86,6 +92,8 @@ allOf: clock-names: items: - const: usbdrd30 + required: + - vdd10-supply - if: properties: @@ -103,6 +111,8 @@ allOf: - const: susp_clk - const: phyclk - const: pipe_pclk + required: + - vdd10-supply - if: properties: @@ -119,6 +129,24 @@ allOf: - const: usbdrd30 - const: usbdrd30_susp_clk - const: usbdrd30_axius_clk + required: + - vdd10-supply + + - if: + properties: + compatible: + contains: + const: samsung,exynos7870-dwusb3 + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: bus_early + - const: ref + - const: ctrl - if: properties: @@ -134,6 +162,8 @@ allOf: items: - const: bus_early - const: ref + required: + - vdd10-supply additionalProperties: false diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml index c956053fd036..71249b6ba616 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3-common.yaml @@ -65,6 +65,17 @@ properties: mode. type: boolean + snps,reserved-endpoints: + description: + Reserve endpoints for other needs, e.g, for tracing control and output. + When set, the driver will avoid using them for the regular USB transfers. + $ref: /schemas/types.yaml#/definitions/uint8-array + minItems: 1 + maxItems: 30 + items: + minimum: 2 + maximum: 31 + snps,dis-start-transfer-quirk: description: When set, disable isoc START TRANSFER command failure SW work-around diff --git a/Documentation/devicetree/bindings/usb/usb-device.yaml b/Documentation/devicetree/bindings/usb/usb-device.yaml index da890ee60ce6..c67695681033 100644 --- a/Documentation/devicetree/bindings/usb/usb-device.yaml +++ b/Documentation/devicetree/bindings/usb/usb-device.yaml @@ -39,8 +39,10 @@ properties: reg: description: the number of the USB hub port or the USB host-controller - port to which this device is attached. The range is 1-255. - maxItems: 1 + port to which this device is attached. + items: + - minimum: 1 + maximum: 255 "#address-cells": description: should be 1 for hub nodes with device nodes, diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 0ef0bc6449ec..86f6a19b28ae 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -18,7 +18,7 @@ patternProperties: # DO NOT ADD NEW PROPERTIES TO THIS LIST "^(at25|bm|devbus|dmacap|dsa|exynos|fsi[ab]|gpio-fan|gpio-key|gpio|gpmc|hdmi|i2c-gpio),.*": true "^(keypad|m25p|max8952|max8997|max8998|mpmc),.*": true - "^(pinctrl-single|#pinctrl-single|PowerPC),.*": true + "^(pciclass|pinctrl-single|#pinctrl-single|PowerPC),.*": true "^(pl022|pxa-mmc|rcar_sound|rotary-encoder|s5m8767|sdhci),.*": true "^(simple-audio-card|st-plgpio|st-spics|ts),.*": true @@ -340,6 +340,8 @@ patternProperties: description: Crystalfontz America, Inc. "^csky,.*": description: Hangzhou C-SKY Microsystems Co., Ltd + "^csot,.*": + description: Guangzhou China Star Optoelectronics Technology Co., Ltd "^csq,.*": description: Shenzen Chuangsiqi Technology Co.,Ltd. "^ctera,.*": diff --git a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml index 64c8f7393809..b35ac03d5172 100644 --- a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml @@ -32,6 +32,7 @@ properties: - items: - const: allwinner,sun20i-d1-wdt-reset - const: allwinner,sun20i-d1-wdt + - const: allwinner,sun55i-a523-wdt reg: maxItems: 1 @@ -60,6 +61,7 @@ if: - allwinner,sun20i-d1-wdt-reset - allwinner,sun50i-r329-wdt - allwinner,sun50i-r329-wdt-reset + - allwinner,sun55i-a523-wdt then: properties: diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml index a09686b3030d..6ec391b9723a 100644 --- a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml @@ -22,6 +22,10 @@ properties: - const: fsl,imx8ulp-wdt - const: fsl,imx7ulp-wdt - const: fsl,imx93-wdt + - items: + - enum: + - fsl,imx94-wdt + - const: fsl,imx93-wdt reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml index 29ada89fdcdc..3e0a8747a357 100644 --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml @@ -75,6 +75,10 @@ properties: - renesas,r8a779h0-wdt # R-Car V4M - const: renesas,rcar-gen4-wdt # R-Car Gen4 + - items: + - const: renesas,r9a09g047-wdt # RZ/G3E + - const: renesas,r9a09g057-wdt # RZ/V2H(P) + - const: renesas,r9a09g057-wdt # RZ/V2H(P) reg: diff --git a/Documentation/devicetree/bindings/xilinx.txt b/Documentation/devicetree/bindings/xilinx.txt index 28199b31fe5e..0ee9de99b3ae 100644 --- a/Documentation/devicetree/bindings/xilinx.txt +++ b/Documentation/devicetree/bindings/xilinx.txt @@ -102,15 +102,6 @@ Default is <d#1024 d#480>. - rotate-display (empty) : rotate display 180 degrees. - ii) Xilinx SystemACE - - The Xilinx SystemACE device is used to program FPGAs from an FPGA - bitstream stored on a CF card. It can also be used as a generic CF - interface device. - - Optional properties: - - 8-bit (empty) : Set this property for SystemACE in 8 bit mode - iii) Xilinx EMAC and Xilinx TEMAC Xilinx Ethernet devices. In addition to general xilinx properties @@ -118,13 +109,6 @@ property, and may include other common network device properties like local-mac-address. - iv) Xilinx Uartlite - - Xilinx uartlite devices are simple fixed speed serial ports. - - Required properties: - - current-speed : Baud rate of uartlite - v) Xilinx hwicap Xilinx hwicap devices provide access to the configuration logic @@ -141,16 +125,6 @@ - compatible : should contain "xlnx,xps-hwicap-1.00.a" or "xlnx,opb-hwicap-1.00.b". - vi) Xilinx Uart 16550 - - Xilinx UART 16550 devices are very similar to the NS16550 but with - different register spacing and an offset from the base address. - - Required properties: - - clock-frequency : Frequency of the clock input - - reg-offset : A value of 3 is required - - reg-shift : A value of 2 is required - vii) Xilinx USB Host controller The Xilinx USB host controller is EHCI compatible but with a different diff --git a/Documentation/driver-api/cxl/maturity-map.rst b/Documentation/driver-api/cxl/maturity-map.rst index df8e2ac2a320..a2288f9df658 100644 --- a/Documentation/driver-api/cxl/maturity-map.rst +++ b/Documentation/driver-api/cxl/maturity-map.rst @@ -130,7 +130,7 @@ Mailbox commands * [0] Switch CCI * [3] Timestamp * [1] PMEM labels -* [0] PMEM GPF / Dirty Shutdown +* [3] PMEM GPF / Dirty Shutdown * [0] Scan Media PMU diff --git a/Documentation/driver-api/phy/phy.rst b/Documentation/driver-api/phy/phy.rst index 81785c084f3e..719a2b3fd2ab 100644 --- a/Documentation/driver-api/phy/phy.rst +++ b/Documentation/driver-api/phy/phy.rst @@ -198,8 +198,7 @@ pm_runtime_get_sync of PHY provider device because of parent-child relationship. It should also be noted that phy_power_on and phy_power_off performs phy_pm_runtime_get_sync and phy_pm_runtime_put respectively. There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync, -phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and -phy_pm_runtime_forbid for performing PM operations. +phy_pm_runtime_put and phy_pm_runtime_put_sync for performing PM operations. PHY Mappings ============ diff --git a/Documentation/driver-api/pps.rst b/Documentation/driver-api/pps.rst index 71ad04c82d6c..598729f9cd27 100644 --- a/Documentation/driver-api/pps.rst +++ b/Documentation/driver-api/pps.rst @@ -206,8 +206,7 @@ To do so the class pps-gen has been added. PPS generators can be registered in the kernel by defining a struct pps_gen_source_info as follows:: - static struct pps_gen_source_info pps_gen_dummy_info = { - .name = "dummy", + static const struct pps_gen_source_info pps_gen_dummy_info = { .use_system_clock = true, .get_time = pps_gen_dummy_get_time, .enable = pps_gen_dummy_enable, @@ -286,3 +285,27 @@ delay between assert and clear edge as small as possible to reduce system latencies. But if it is too small slave won't be able to capture clear edge transition. The default of 30us should be good enough in most situations. The delay can be selected using 'delay' pps_gen_parport module parameter. + + +Intel Timed I/O PPS signal generator +------------------------------------ + +Intel Timed I/O is a high precision device, present on 2019 and newer Intel +CPUs, that can generate PPS signals. + +Timed I/O and system time are both driven by same hardware clock. The signal +is generated with a precision of ~20 nanoseconds. The generated PPS signal +is used to synchronize an external device with system clock. For example, +it can be used to share your clock with a device that receives PPS signal, +generated by Timed I/O device. There are dedicated Timed I/O pins to deliver +the PPS signal to an external device. + +Usage of Intel Timed I/O as PPS generator: + +Start generating PPS signal:: + + $echo 1 > /sys/class/pps-gen/pps-genx/enable + +Stop generating PPS signal:: + + $echo 0 > /sys/class/pps-gen/pps-genx/enable diff --git a/Documentation/driver-api/serial/driver.rst b/Documentation/driver-api/serial/driver.rst index 84b43061c11b..fa1ebfcd4472 100644 --- a/Documentation/driver-api/serial/driver.rst +++ b/Documentation/driver-api/serial/driver.rst @@ -101,6 +101,6 @@ Modem control lines via GPIO Some helpers are provided in order to set/get modem control lines via GPIO. .. kernel-doc:: drivers/tty/serial/serial_mctrl_gpio.c - :identifiers: mctrl_gpio_init mctrl_gpio_free mctrl_gpio_to_gpiod + :identifiers: mctrl_gpio_init mctrl_gpio_to_gpiod mctrl_gpio_set mctrl_gpio_get mctrl_gpio_enable_ms - mctrl_gpio_disable_ms + mctrl_gpio_disable_ms_sync mctrl_gpio_disable_ms_no_sync diff --git a/Documentation/driver-api/soundwire/bra.rst b/Documentation/driver-api/soundwire/bra.rst new file mode 100644 index 000000000000..8500253fa3e8 --- /dev/null +++ b/Documentation/driver-api/soundwire/bra.rst @@ -0,0 +1,336 @@ +========================== +Bulk Register Access (BRA) +========================== + +Conventions +----------- + +Capitalized words used in this documentation are intentional and refer +to concepts of the SoundWire 1.x specification. + +Introduction +------------ + +The SoundWire 1.x specification provides a mechanism to speed-up +command/control transfers by reclaiming parts of the audio +bandwidth. The Bulk Register Access (BRA) protocol is a standard +solution based on the Bulk Payload Transport (BPT) definitions. + +The regular control channel uses Column 0 and can only send/retrieve +one byte per frame with write/read commands. With a typical 48kHz +frame rate, only 48kB/s can be transferred. + +The optional Bulk Register Access capability can transmit up to 12 +Mbits/s and reduce transfer times by several orders of magnitude, but +has multiple design constraints: + + (1) Each frame can only support a read or a write transfer, with a + 10-byte overhead per frame (header and footer response). + + (2) The read/writes SHALL be from/to contiguous register addresses + in the same frame. A fragmented register space decreases the + efficiency of the protocol by requiring multiple BRA transfers + scheduled in different frames. + + (3) The targeted Peripheral device SHALL support the optional Data + Port 0, and likewise the Manager SHALL expose audio-like Ports + to insert BRA packets in the audio payload using the concepts of + Sample Interval, HSTART, HSTOP, etc. + + (4) The BRA transport efficiency depends on the available + bandwidth. If there are no on-going audio transfers, the entire + frame minus Column 0 can be reclaimed for BRA. The frame shape + also impacts efficiency: since Column0 cannot be used for + BTP/BRA, the frame should rely on a large number of columns and + minimize the number of rows. The bus clock should be as high as + possible. + + (5) The number of bits transferred per frame SHALL be a multiple of + 8 bits. Padding bits SHALL be inserted if necessary at the end + of the data. + + (6) The regular read/write commands can be issued in parallel with + BRA transfers. This is convenient to e.g. deal with alerts, jack + detection or change the volume during firmware download, but + accessing the same address with two independent protocols has to + be avoided to avoid undefined behavior. + + (7) Some implementations may not be capable of handling the + bandwidth of the BRA protocol, e.g. in the case of a slow I2C + bus behind the SoundWire IP. In this case, the transfers may + need to be spaced in time or flow-controlled. + + (8) Each BRA packet SHALL be marked as 'Active' when valid data is + to be transmitted. This allows for software to allocate a BRA + stream but not transmit/discard data while processing the + results or preparing the next batch of data, or allowing the + peripheral to deal with the previous transfer. In addition BRA + transfer can be started early on without data being ready. + + (9) Up to 470 bytes may be transmitted per frame. + + (10) The address is represented with 32 bits and does not rely on + the paging registers used for the regular command/control + protocol in Column 0. + + +Error checking +-------------- + +Firmware download is one of the key usages of the Bulk Register Access +protocol. To make sure the binary data integrity is not compromised by +transmission or programming errors, each BRA packet provides: + + (1) A CRC on the 7-byte header. This CRC helps the Peripheral Device + check if it is addressed and set the start address and number of + bytes. The Peripheral Device provides a response in Byte 7. + + (2) A CRC on the data block (header excluded). This CRC is + transmitted as the last-but-one byte in the packet, prior to the + footer response. + +The header response can be one of: + (a) Ack + (b) Nak + (c) Not Ready + +The footer response can be one of: + (1) Ack + (2) Nak (CRC failure) + (3) Good (operation completed) + (4) Bad (operation failed) + +Example frame +------------- + +The example below is not to scale and makes simplifying assumptions +for clarity. The different chunks in the BRA packets are not required +to start on a new SoundWire Row, and the scale of data may vary. + + :: + + +---+--------------------------------------------+ + + | | + + | BRA HEADER | + + | | + + +--------------------------------------------+ + + C | HEADER CRC | + + O +--------------------------------------------+ + + M | HEADER RESPONSE | + + M +--------------------------------------------+ + + A | | + + N | | + + D | DATA | + + | | + + | | + + | | + + +--------------------------------------------+ + + | DATA CRC | + + +--------------------------------------------+ + + | FOOTER RESPONSE | + +---+--------------------------------------------+ + + +Assuming the frame uses N columns, the configuration shown above can +be programmed by setting the DP0 registers as: + + - HSTART = 1 + - HSTOP = N - 1 + - Sampling Interval = N + - WordLength = N - 1 + +Addressing restrictions +----------------------- + +The Device Number specified in the Header follows the SoundWire +definitions, and broadcast and group addressing are permitted. For now +the Linux implementation only allows for a single BPT transfer to a +single device at a time. This might be revisited at a later point as +an optimization to send the same firmware to multiple devices, but +this would only be beneficial for single-link solutions. + +In the case of multiple Peripheral devices attached to different +Managers, the broadcast and group addressing is not supported by the +SoundWire specification. Each device must be handled with separate BRA +streams, possibly in parallel - the links are really independent. + +Unsupported features +-------------------- + +The Bulk Register Access specification provides a number of +capabilities that are not supported in known implementations, such as: + + (1) Transfers initiated by a Peripheral Device. The BRA Initiator is + always the Manager Device. + + (2) Flow-control capabilities and retransmission based on the + 'NotReady' header response require extra buffering in the + SoundWire IP and are not implemented. + +Bi-directional handling +----------------------- + +The BRA protocol can handle writes as well as reads, and in each +packet the header and footer response are provided by the Peripheral +Target device. On the Peripheral device, the BRA protocol is handled +by a single DP0 data port, and at the low-level the bus ownership can +will change for header/footer response as well as the data transmitted +during a read. + +On the host side, most implementations rely on a Port-like concept, +with two FIFOs consuming/generating data transfers in parallel +(Host->Peripheral and Peripheral->Host). The amount of data +consumed/produced by these FIFOs is not symmetrical, as a result +hardware typically inserts markers to help software and hardware +interpret raw data + +Each packet will typically have: + + (1) a 'Start of Packet' indicator. + + (2) an 'End of Packet' indicator. + + (3) a packet identifier to correlate the data requested and + transmitted, and the error status for each frame + +Hardware implementations can check errors at the frame level, and +retry a transfer in case of errors. However, as for the flow-control +case, this requires extra buffering and intelligence in the +hardware. The Linux support assumes that the entire transfer is +cancelled if a single error is detected in one of the responses. + +Abstraction required +~~~~~~~~~~~~~~~~~~~~ + +There are no standard registers or mandatory implementation at the +Manager level, so the low-level BPT/BRA details must be hidden in +Manager-specific code. For example the Cadence IP format above is not +known to the codec drivers. + +Likewise, codec drivers should not have to know the frame size. The +computation of CRC and handling of responses is handled in helpers and +Manager-specific code. + +The host BRA driver may also have restrictions on pages allocated for +DMA, or other host-DSP communication protocols. The codec driver +should not be aware of any of these restrictions, since it might be +reused in combination with different implementations of Manager IPs. + +Concurrency between BRA and regular read/write +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The existing 'nread/nwrite' API already relies on a notion of start +address and number of bytes, so it would be possible to extend this +API with a 'hint' requesting BPT/BRA be used. + +However BRA transfers could be quite long, and the use of a single +mutex for regular read/write and BRA is a show-stopper. Independent +operation of the control/command and BRA transfers is a fundamental +requirement, e.g. to change the volume level with the existing regmap +interface while downloading firmware. The integration must however +ensure that there are no concurrent access to the same address with +the command/control protocol and the BRA protocol. + +In addition, the 'sdw_msg' structure hard-codes support for 16-bit +addresses and paging registers which are irrelevant for BPT/BRA +support based on native 32-bit addresses. A separate API with +'sdw_bpt_msg' makes more sense. + +One possible strategy to speed-up all initialization tasks would be to +start a BRA transfer for firmware download, then deal with all the +"regular" read/writes in parallel with the command channel, and last +to wait for the BRA transfers to complete. This would allow for a +degree of overlap instead of a purely sequential solution. As such, +the BRA API must support async transfers and expose a separate wait +function. + + +Peripheral/bus interface +------------------------ + +The bus interface for BPT/BRA is made of two functions: + + - sdw_bpt_send_async(bpt_message) + + This function sends the data using the Manager + implementation-defined capabilities (typically DMA or IPC + protocol). + + Queueing is currently not supported, the caller + needs to wait for completion of the requested transfer. + + - sdw_bpt_wait() + + This function waits for the entire message provided by the + codec driver in the 'send_async' stage. Intermediate status for + smaller chunks will not be provided back to the codec driver, + only a return code will be provided. + +Regmap use +~~~~~~~~~~ + +Existing codec drivers rely on regmap to download firmware to +Peripherals. regmap exposes an async interface similar to the +send/wait API suggested above, so at a high-level it would seem +natural to combine BRA and regmap. The regmap layer could check if BRA +is available or not, and use a regular read-write command channel in +the latter case. + +The regmap integration will be handled in a second step. + +BRA stream model +---------------- + +For regular audio transfers, the machine driver exposes a dailink +connecting CPU DAI(s) and Codec DAI(s). + +This model is not required BRA support: + + (1) The SoundWire DAIs are mainly wrappers for SoundWire Data + Ports, with possibly some analog or audio conversion + capabilities bolted behind the Data Port. In the context of + BRA, the DP0 is the destination. DP0 registers are standard and + can be programmed blindly without knowing what Peripheral is + connected to each link. In addition, if there are multiple + Peripherals on a link and some of them do not support DP0, the + write commands to program DP0 registers will generate harmless + COMMAND_IGNORED responses that will be wired-ORed with + responses from Peripherals which support DP0. In other words, + the DP0 programming can be done with broadcast commands, and + the information on the Target device can be added only in the + BRA Header. + + (2) At the CPU level, the DAI concept is not useful for BRA; the + machine driver will not create a dailink relying on DP0. The + only concept that is needed is the notion of port. + + (3) The stream concept relies on a set of master_rt and slave_rt + concepts. All of these entities represent ports and not DAIs. + + (4) With the assumption that a single BRA stream is used per link, + that stream can connect master ports as well as all peripheral + DP0 ports. + + (5) BRA transfers only make sense in the context of one + Manager/Link, so the BRA stream handling does not rely on the + concept of multi-link aggregation allowed by regular DAI links. + +Audio DMA support +----------------- + +Some DMAs, such as HDaudio, require an audio format field to be +set. This format is in turn used to define acceptable bursts. BPT/BRA +support is not fully compatible with these definitions in that the +format and bandwidth may vary between read and write commands. + +In addition, on Intel HDaudio Intel platforms the DMAs need to be +programmed with a PCM format matching the bandwidth of the BPT/BRA +transfer. The format is based on 192kHz 32-bit samples, and the number +of channels varies to adjust the bandwidth. The notion of channel is +completely notional since the data is not typical audio +PCM. Programming such channels helps reserve enough bandwidth and adjust +FIFO sizes to avoid xruns. + +Alignment requirements are currently not enforced at the core level +but at the platform-level, e.g. for Intel the data sizes must be +multiples of 32 bytes. diff --git a/Documentation/driver-api/soundwire/bra_cadence.rst b/Documentation/driver-api/soundwire/bra_cadence.rst new file mode 100644 index 000000000000..4560752e8f47 --- /dev/null +++ b/Documentation/driver-api/soundwire/bra_cadence.rst @@ -0,0 +1,66 @@ +Cadence IP BRA support +---------------------- + +Format requirements +~~~~~~~~~~~~~~~~~~~ + +The Cadence IP relies on PDI0 for TX and PDI1 for RX. The data needs +to be formatted with the following conventions: + + (1) all Data is stored in bits 15..0 of the 32-bit PDI FIFOs. + + (2) the start of packet is BIT(31). + + (3) the end of packet is BIT(30). + + (4) A packet ID is stored in bits 19..16. This packet ID is + determined by software and is typically a rolling counter. + + (5) Padding shall be inserted as needed so that the Header CRC, + Header response, Footer CRC, Footer response are always in + Byte0. Padding is inserted by software for writes, and on reads + software shall discard the padding added by the hardware. + +Example format +~~~~~~~~~~~~~~ + +The following table represents the sequence provided to PDI0 for a +write command followed by a read command. + +:: + + +---+---+--------+---------------+---------------+ + + 1 | 0 | ID = 0 | WR HDR[1] | WR HDR[0] | + + | | | WR HDR[3] | WR HDR[2] | + + | | | WR HDR[5] | WR HDR[4] | + + | | | pad | WR HDR CRC | + + | | | WR Data[1] | WR Data[0] | + + | | | WR Data[3] | WR Data[2] | + + | | | WR Data[n-2] | WR Data[n-3] | + + | | | pad | WR Data[n-1] | + + 0 | 1 | | pad | WR Data CRC | + +---+---+--------+---------------+---------------+ + + 1 | 0 | ID = 1 | RD HDR[1] | RD HDR[0] | + + | | | RD HDR[3] | RD HDR[2] | + + | | | RD HDR[5] | RD HDR[4] | + + 0 | 1 | | pad | RD HDR CRC | + +---+---+--------+---------------+---------------+ + + +The table below represents the data received on PDI1 for the same +write command followed by a read command. + +:: + + +---+---+--------+---------------+---------------+ + + 1 | 0 | ID = 0 | pad | WR Hdr Rsp | + + 0 | 1 | | pad | WR Ftr Rsp | + +---+---+--------+---------------+---------------+ + + 1 | 0 | ID = 0 | pad | Rd Hdr Rsp | + + | | | RD Data[1] | RD Data[0] | + + | | | RD Data[3] | RD Data[2] | + + | | | RD HDR[n-2] | RD Data[n-3] | + + | | | pad | RD Data[n-1] | + + | | | pad | RD Data CRC | + + 0 | 1 | | pad | RD Ftr Rsp | + +---+---+--------+---------------+---------------+ diff --git a/Documentation/driver-api/soundwire/index.rst b/Documentation/driver-api/soundwire/index.rst index 234911a0db99..ef8d90dfbdde 100644 --- a/Documentation/driver-api/soundwire/index.rst +++ b/Documentation/driver-api/soundwire/index.rst @@ -9,6 +9,8 @@ SoundWire Documentation stream error_handling locking + bra + bra_cadence .. only:: subproject and html diff --git a/Documentation/driver-api/soundwire/stream.rst b/Documentation/driver-api/soundwire/stream.rst index 2a794484f62c..d66201299633 100644 --- a/Documentation/driver-api/soundwire/stream.rst +++ b/Documentation/driver-api/soundwire/stream.rst @@ -291,7 +291,7 @@ per stream. From ASoC DPCM framework, this stream state maybe linked to .. code-block:: c - int sdw_alloc_stream(char * stream_name); + int sdw_alloc_stream(char * stream_name, enum sdw_stream_type type); The SoundWire core provides a sdw_startup_stream() helper function, typically called during a dailink .startup() callback, which performs diff --git a/Documentation/driver-api/soundwire/summary.rst b/Documentation/driver-api/soundwire/summary.rst index 01dcb954f6d7..df78053743b5 100644 --- a/Documentation/driver-api/soundwire/summary.rst +++ b/Documentation/driver-api/soundwire/summary.rst @@ -184,14 +184,6 @@ function that provides capabilities information. Bus needs to know a set of Slave capabilities to program Slave registers and to control the Bus reconfigurations. -Future enhancements to be done -============================== - - (1) Bulk Register Access (BRA) transfers. - - - (2) Multiple data lane support. - Links ===== diff --git a/Documentation/driver-api/thermal/sysfs-api.rst b/Documentation/driver-api/thermal/sysfs-api.rst index c803b89b7248..f73de211bdce 100644 --- a/Documentation/driver-api/thermal/sysfs-api.rst +++ b/Documentation/driver-api/thermal/sysfs-api.rst @@ -413,18 +413,21 @@ This function serves as an arbitrator to set the state of a cooling device. It sets the cooling device to the deepest cooling state if possible. -5. thermal_emergency_poweroff -============================= +5. Critical Events +================== + +On an event of critical trip temperature crossing, the thermal framework +will trigger a hardware protection power-off (shutdown) or reboot, +depending on configuration. -On an event of critical trip temperature crossing the thermal framework -shuts down the system by calling hw_protection_shutdown(). The -hw_protection_shutdown() first attempts to perform an orderly shutdown -but accepts a delay after which it proceeds doing a forced power-off -or as last resort an emergency_restart. +At first, the kernel will attempt an orderly power-off or reboot, but +accepts a delay after which it proceeds to do a forced power-off or +reboot, respectively. If this fails, ``emergency_restart()`` is invoked +as last resort. The delay should be carefully profiled so as to give adequate time for -orderly poweroff. +orderly power-off or reboot. -If the delay is set to 0 emergency poweroff will not be supported. So a -carefully profiled non-zero positive value is a must for emergency -poweroff to be triggered. +If the delay is set to 0, the emergency action will not be supported. So a +carefully profiled non-zero positive value is a must for the emergency +action to be triggered. diff --git a/Documentation/driver-api/tty/tty_driver.rst b/Documentation/driver-api/tty/tty_driver.rst index cc529f863406..7138222a70f2 100644 --- a/Documentation/driver-api/tty/tty_driver.rst +++ b/Documentation/driver-api/tty/tty_driver.rst @@ -25,6 +25,8 @@ freed. For reference, both allocation and deallocation functions are explained here in detail: +.. kernel-doc:: include/linux/tty_driver.h + :identifiers: tty_alloc_driver .. kernel-doc:: drivers/tty/tty_io.c :identifiers: __tty_alloc_driver tty_driver_kref_put @@ -35,7 +37,7 @@ Here comes the documentation of flags accepted by tty_alloc_driver() (or __tty_alloc_driver()): .. kernel-doc:: include/linux/tty_driver.h - :doc: TTY Driver Flags + :identifiers: tty_driver_flag ---- diff --git a/Documentation/driver-api/tty/tty_struct.rst b/Documentation/driver-api/tty/tty_struct.rst index c72f5a4293b2..29caf1c1ca5f 100644 --- a/Documentation/driver-api/tty/tty_struct.rst +++ b/Documentation/driver-api/tty/tty_struct.rst @@ -72,7 +72,7 @@ TTY Struct Flags ================ .. kernel-doc:: include/linux/tty.h - :doc: TTY Struct Flags + :identifiers: tty_struct_flags TTY Struct Reference ==================== diff --git a/Documentation/driver-api/usb/writing_musb_glue_layer.rst b/Documentation/driver-api/usb/writing_musb_glue_layer.rst index e755c8551bba..0bb96ecdf527 100644 --- a/Documentation/driver-api/usb/writing_musb_glue_layer.rst +++ b/Documentation/driver-api/usb/writing_musb_glue_layer.rst @@ -613,7 +613,7 @@ endpoints configuration from the hardware, so we use line 12 instruction to bypass reading the configuration from silicon, and rely on a hard-coded table that describes the endpoints configuration instead:: - static struct musb_fifo_cfg jz4740_musb_fifo_cfg[] = { + static const struct musb_fifo_cfg jz4740_musb_fifo_cfg[] = { { .hw_ep_num = 1, .style = FIFO_TX, .maxpacket = 512, }, { .hw_ep_num = 1, .style = FIFO_RX, .maxpacket = 512, }, { .hw_ep_num = 2, .style = FIFO_TX, .maxpacket = 64, }, diff --git a/Documentation/features/core/mseal_sys_mappings/arch-support.txt b/Documentation/features/core/mseal_sys_mappings/arch-support.txt new file mode 100644 index 000000000000..c6cab9760d57 --- /dev/null +++ b/Documentation/features/core/mseal_sys_mappings/arch-support.txt @@ -0,0 +1,30 @@ +# +# Feature name: mseal-system-mappings +# Kconfig: ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS +# description: arch supports mseal system mappings +# + ----------------------- + | arch |status| + ----------------------- + | alpha: | TODO | + | arc: | N/A | + | arm: | N/A | + | arm64: | ok | + | csky: | N/A | + | hexagon: | N/A | + | loongarch: | TODO | + | m68k: | N/A | + | microblaze: | N/A | + | mips: | TODO | + | nios2: | N/A | + | openrisc: | N/A | + | parisc: | TODO | + | powerpc: | TODO | + | riscv: | TODO | + | s390: | ok | + | sh: | N/A | + | sparc: | TODO | + | um: | TODO | + | x86: | ok | + | xtensa: | N/A | + ----------------------- diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/9p.rst index 3078f3c9256a..be3504ca034a 100644 --- a/Documentation/filesystems/9p.rst +++ b/Documentation/filesystems/9p.rst @@ -40,7 +40,7 @@ For remote file server:: mount -t 9p 10.10.1.2 /mnt/9 -For Plan 9 From User Space applications (http://swtch.com/plan9):: +For Plan 9 From User Space applications (https://9fans.github.io/plan9port/):: mount -t 9p `namespace`/acme /mnt/9 -o trans=unix,uname=$USER @@ -165,8 +165,8 @@ Options do not necessarily validate cached values on the server. In other words changes on the server are not guaranteed to be reflected on the client system. Only use this mode of operation if you - have an exclusive mount and the server will modify the filesystem - underneath you. + have an exclusive mount and the server will not modify the + filesystem underneath you. debug=n specifies debug level. The debug level is a bitmask. diff --git a/Documentation/filesystems/dax.rst b/Documentation/filesystems/dax.rst index 719e90f1988e..08dd5e254cc5 100644 --- a/Documentation/filesystems/dax.rst +++ b/Documentation/filesystems/dax.rst @@ -207,7 +207,6 @@ implement direct_access. These block devices may be used for inspiration: - brd: RAM backed block device driver -- dcssblk: s390 dcss block device driver - pmem: NVDIMM persistent memory driver diff --git a/Documentation/filesystems/ext4/super.rst b/Documentation/filesystems/ext4/super.rst index a1eb4a11a1d0..1b240661bfa3 100644 --- a/Documentation/filesystems/ext4/super.rst +++ b/Documentation/filesystems/ext4/super.rst @@ -328,9 +328,13 @@ The ext4 superblock is laid out as follows in - s_checksum_type - Metadata checksum algorithm type. The only valid value is 1 (crc32c). * - 0x176 - - __le16 - - s_reserved_pad - - + - \_\_u8 + - s\_encryption\_level + - Versioning level for encryption. + * - 0x177 + - \_\_u8 + - s\_reserved\_pad + - Padding to next 32bits. * - 0x178 - __le64 - s_kbytes_written @@ -466,9 +470,13 @@ The ext4 superblock is laid out as follows in - s_last_error_time_hi - Upper 8 bits of the s_last_error_time field. * - 0x27A - - __u8 - - s_pad[2] - - Zero padding. + - \_\_u8 + - s\_first\_error\_errcode + - + * - 0x27B + - \_\_u8 + - s\_last\_error\_errcode + - * - 0x27C - __le16 - s_encoding diff --git a/Documentation/filesystems/nfs/reexport.rst b/Documentation/filesystems/nfs/reexport.rst index ff9ae4a46530..044be965d75e 100644 --- a/Documentation/filesystems/nfs/reexport.rst +++ b/Documentation/filesystems/nfs/reexport.rst @@ -26,9 +26,13 @@ Reboot recovery --------------- The NFS protocol's normal reboot recovery mechanisms don't work for the -case when the reexport server reboots. Clients will lose any locks -they held before the reboot, and further IO will result in errors. -Closing and reopening files should clear the errors. +case when the reexport server reboots because the source server has not +rebooted, and so it is not in grace. Since the source server is not in +grace, it cannot offer any guarantees that the file won't have been +changed between the locks getting lost and any attempt to recover them. +The same applies to delegations and any associated locks. Clients are +not allowed to get file locks or delegations from a reexport server, any +attempts will fail with operation not supported. Filehandle limits ----------------- diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 09f0aed5a08b..2a17865dfe39 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -128,6 +128,16 @@ process running on the system, which is named after the process ID (PID). The link 'self' points to the process reading the file system. Each process subdirectory has the entries listed in Table 1-1. +A process can read its own information from /proc/PID/* with no extra +permissions. When reading /proc/PID/* information for other processes, reading +process is required to have either CAP_SYS_PTRACE capability with +PTRACE_MODE_READ access permissions, or, alternatively, CAP_PERFMON +capability. This applies to all read-only information like `maps`, `environ`, +`pagemap`, etc. The only exception is `mem` file due to its read-write nature, +which requires CAP_SYS_PTRACE capabilities with more elevated +PTRACE_MODE_ATTACH permissions; CAP_PERFMON capability does not grant access +to /proc/PID/mem for other processes. + Note that an open file descriptor to /proc/<pid> or to any of its contained files or subdirectories does not prevent <pid> being reused for some other process in the event that <pid> exits. Operations on @@ -502,9 +512,25 @@ process, its PSS will be 1500. "Pss_Dirty" is the portion of PSS which consists of dirty pages. ("Pss_Clean" is not included, but it can be calculated by subtracting "Pss_Dirty" from "Pss".) -Note that even a page which is part of a MAP_SHARED mapping, but has only -a single pte mapped, i.e. is currently used by only one process, is accounted -as private and not as shared. +Traditionally, a page is accounted as "private" if it is mapped exactly once, +and a page is accounted as "shared" when mapped multiple times, even when +mapped in the same process multiple times. Note that this accounting is +independent of MAP_SHARED. + +In some kernel configurations, the semantics of pages part of a larger +allocation (e.g., THP) can differ: a page is accounted as "private" 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. A +page is accounted as "shared" if 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. + +Some kernel configurations do not track the precise number of times a page part +of a larger allocation is mapped. In this case, when calculating the PSS, the +average number of mappings per page in this larger allocation might be used +as an approximation for the number of mappings of a page. The PSS calculation +will be imprecise in this case. "Referenced" indicates the amount of memory currently marked as referenced or accessed. @@ -686,6 +712,11 @@ Where: node locality page counters (N0 == node0, N1 == node1, ...) and the kernel page size, in KB, that is backing the mapping up. +Note that 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, "mapmax" might corresponds to the average number of mappings +per page in such a larger allocation instead. + 1.2 Kernel data --------------- @@ -1060,6 +1091,8 @@ Example output. You may not have all of these fields. FilePmdMapped: 0 kB CmaTotal: 0 kB CmaFree: 0 kB + Unaccepted: 0 kB + Balloon: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 @@ -1132,9 +1165,15 @@ Dirty Writeback Memory which is actively being written back to the disk AnonPages - Non-file backed pages mapped into userspace page tables + Non-file backed pages mapped into userspace page tables. Note that + some kernel configurations might consider all pages part of a + larger allocation (e.g., THP) as "mapped", as soon as a single + page is mapped. Mapped - files which have been mmapped, such as libraries + files which have been mmapped, such as libraries. Note that some + kernel configurations might consider all pages part of a larger + allocation (e.g., THP) as "mapped", as soon as a single page is + mapped. Shmem Total memory used by shared memory (shmem) and tmpfs KReclaimable @@ -1228,6 +1267,10 @@ CmaTotal Memory reserved for the Contiguous Memory Allocator (CMA) CmaFree Free remaining memory in the CMA reserves +Unaccepted + Memory that has not been accepted by the guest +Balloon + Memory returned to Host by VM Balloon Drivers HugePages_Total, HugePages_Free, HugePages_Rsvd, HugePages_Surp, Hugepagesize, Hugetlb See Documentation/admin-guide/mm/hugetlbpage.rst. DirectMap4k, DirectMap2M, DirectMap1G diff --git a/Documentation/gpu/amdgpu/amdgpu-glossary.rst b/Documentation/gpu/amdgpu/amdgpu-glossary.rst index 00a47ebb0b0f..1e9283e076ba 100644 --- a/Documentation/gpu/amdgpu/amdgpu-glossary.rst +++ b/Documentation/gpu/amdgpu/amdgpu-glossary.rst @@ -12,6 +12,9 @@ we have a dedicated glossary for Display Core at The number of CUs that are active on the system. The number of active CUs may be less than SE * SH * CU depending on the board configuration. + CE + Constant Engine + CP Command Processor @@ -68,6 +71,9 @@ we have a dedicated glossary for Display Core at IB Indirect Buffer + IMU + Integrated Management Unit (Power Management support) + IP Intellectual Property blocks @@ -80,6 +86,12 @@ we have a dedicated glossary for Display Core at KIQ Kernel Interface Queue + MC + Memory Controller + + ME + MicroEngine (Graphics) + MEC MicroEngine Compute @@ -92,6 +104,9 @@ we have a dedicated glossary for Display Core at MQD Memory Queue Descriptor + PFP + Pre-Fetch Parser (Graphics) + PPLib PowerPlay Library - PowerPlay is the power management component. @@ -99,7 +114,10 @@ we have a dedicated glossary for Display Core at Platform Security Processor RLC - RunList Controller + RunList Controller. This name is a remnant of past ages and doesn't have + much meaning today. It's a group of general-purpose helper engines for + the GFX block. It's involved in GFX power management and SR-IOV, among + other things. SDMA System DMA @@ -110,14 +128,35 @@ we have a dedicated glossary for Display Core at SH SHader array - SMU - System Management Unit + SMU/SMC + System Management Unit / System Management Controller + + SRLC + Save/Restore List Control + + SRLG + Save/Restore List GPM_MEM + + SRLS + Save/Restore List SRM_MEM SS Spread Spectrum + TA + Trusted Application + + TOC + Table of Contents + + UVD + Unified Video Decoder + VCE Video Compression Engine VCN Video Codec Next + + VPE + Video Processing Engine diff --git a/Documentation/gpu/amdgpu/display/dc-glossary.rst b/Documentation/gpu/amdgpu/display/dc-glossary.rst index 0b0ffd428dd2..7dc034e9e586 100644 --- a/Documentation/gpu/amdgpu/display/dc-glossary.rst +++ b/Documentation/gpu/amdgpu/display/dc-glossary.rst @@ -167,9 +167,6 @@ consider asking in the amdgfx and update this page. MALL Memory Access at Last Level - MC - Memory Controller - MPC/MPCC Multiple pipes and plane combine @@ -232,6 +229,3 @@ consider asking in the amdgfx and update this page. VRR Variable Refresh Rate - - UVD - Unified Video Decoder diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index 1f17ad0790d7..78b80be17f21 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -10,6 +10,7 @@ GPU Driver Documentation imagination/index mcde meson + nouveau pl111 tegra tve200 @@ -24,6 +25,7 @@ GPU Driver Documentation panfrost panthor zynqmp + nova/index .. only:: subproject and html diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index cb9ae282771c..94f93fd3b8a0 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -208,6 +208,13 @@ follows: ``CONFIG_VIRTIO_UML`` and ``CONFIG_UML_PCI_OVER_VIRTIO`` are not included in it because they are only required for User Mode Linux. +KUnit Coverage Rules +~~~~~~~~~~~~~~~~~~~~ + +KUnit support is gradually added to the DRM framework and helpers. There's no +general requirement for the framework and helpers to have KUnit tests at the +moment. However, patches that are affecting a function or helper already +covered by KUnit tests must provide tests if the change calls for one. Legacy Support Code =================== diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index b75cc9a70d1f..69f72e71a96e 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -371,9 +371,119 @@ Reporting causes of resets Apart from propagating the reset through the stack so apps can recover, it's really useful for driver developers to learn more about what caused the reset in -the first place. DRM devices should make use of devcoredump to store relevant -information about the reset, so this information can be added to user bug -reports. +the first place. For this, drivers can make use of devcoredump to store relevant +information about the reset and send device wedged event with ``none`` recovery +method (as explained in "Device Wedging" chapter) to notify userspace, so this +information can be collected and added to user bug reports. + +Device Wedging +============== + +Drivers can optionally make use of device wedged event (implemented as +drm_dev_wedged_event() in DRM subsystem), which notifies userspace of 'wedged' +(hanged/unusable) state of the DRM device through a uevent. This is useful +especially in cases where the device is no longer operating as expected and has +become unrecoverable from driver context. Purpose of this implementation is to +provide drivers a generic way to recover the device with the help of userspace +intervention, without taking any drastic measures (like resetting or +re-enumerating the full bus, on which the underlying physical device is sitting) +in the driver. + +A 'wedged' device is basically a device that is declared dead by the driver +after exhausting all possible attempts to recover it from driver context. The +uevent is the notification that is sent to userspace along with a hint about +what could possibly be attempted to recover the device from userspace and bring +it back to usable state. Different drivers may have different ideas of a +'wedged' device depending on hardware implementation of the underlying physical +device, and hence the vendor agnostic nature of the event. It is up to the +drivers to decide when they see the need for device recovery and how they want +to recover from the available methods. + +Driver prerequisites +-------------------- + +The driver, before opting for recovery, needs to make sure that the 'wedged' +device doesn't harm the system as a whole by taking care of the prerequisites. +Necessary actions must include disabling DMA to system memory as well as any +communication channels with other devices. Further, the driver must ensure +that all dma_fences are signalled and any device state that the core kernel +might depend on is cleaned up. All existing mmaps should be invalidated and +page faults should be redirected to a dummy page. Once the event is sent, the +device must be kept in 'wedged' state until the recovery is performed. New +accesses to the device (IOCTLs) should be rejected, preferably with an error +code that resembles the type of failure the device has encountered. This will +signify the reason for wedging, which can be reported to the application if +needed. + +Recovery +-------- + +Current implementation defines three recovery methods, out of which, drivers +can use any one, multiple or none. Method(s) of choice will be sent in the +uevent environment as ``WEDGED=<method1>[,..,<methodN>]`` in order of less to +more side-effects. If driver is unsure about recovery or method is unknown +(like soft/hard system reboot, firmware flashing, physical device replacement +or any other procedure which can't be attempted on the fly), ``WEDGED=unknown`` +will be sent instead. + +Userspace consumers can parse this event and attempt recovery as per the +following expectations. + + =============== ======================================== + Recovery method Consumer expectations + =============== ======================================== + none optional telemetry collection + rebind unbind + bind driver + bus-reset unbind + bus reset/re-enumeration + bind + unknown consumer policy + =============== ======================================== + +The only exception to this is ``WEDGED=none``, which signifies that the device +was temporarily 'wedged' at some point but was recovered from driver context +using device specific methods like reset. No explicit recovery is expected from +the consumer in this case, but it can still take additional steps like gathering +telemetry information (devcoredump, syslog). This is useful because the first +hang is usually the most critical one which can result in consequential hangs or +complete wedging. + +Consumer prerequisites +---------------------- + +It is the responsibility of the consumer to make sure that the device or its +resources are not in use by any process before attempting recovery. With IOCTLs +erroring out, all device memory should be unmapped and file descriptors should +be closed to prevent leaks or undefined behaviour. The idea here is to clear the +device of all user context beforehand and set the stage for a clean recovery. + +Example +------- + +Udev rule:: + + SUBSYSTEM=="drm", ENV{WEDGED}=="rebind", DEVPATH=="*/drm/card[0-9]", + RUN+="/path/to/rebind.sh $env{DEVPATH}" + +Recovery script:: + + #!/bin/sh + + DEVPATH=$(readlink -f /sys/$1/device) + DEVICE=$(basename $DEVPATH) + DRIVER=$(readlink -f $DEVPATH/driver) + + echo -n $DEVICE > $DRIVER/unbind + echo -n $DEVICE > $DRIVER/bind + +Customization +------------- + +Although basic recovery is possible with a simple script, consumers can define +custom policies around recovery. For example, if the driver supports multiple +recovery methods, consumers can opt for the suitable one depending on scenarios +like repeat offences or vendor specific failures. Consumers can also choose to +have the device available for debugging or telemetry collection and base their +recovery decision on the findings. This is useful especially when the driver is +unsure about recovery or method is unknown. .. _drm_driver_ioctl: diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index b7fc106dad99..63d6b2abe5ad 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -21,7 +21,10 @@ File format specification - File shall contain one key value pair per one line of text. - Colon character (`:`) must be used to delimit keys and values. -- All keys shall be prefixed with `drm-`. +- All standardised keys shall be prefixed with `drm-`. +- Driver-specific keys shall be prefixed with `driver_name-`, where + driver_name should ideally be the same as the `name` field in + `struct drm_driver`, although this is not mandatory. - Whitespace between the delimiter and first non-whitespace character shall be ignored when parsing. - Keys are not allowed to contain whitespace characters. diff --git a/Documentation/gpu/nouveau.rst b/Documentation/gpu/nouveau.rst new file mode 100644 index 000000000000..0f34131ccc27 --- /dev/null +++ b/Documentation/gpu/nouveau.rst @@ -0,0 +1,29 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +=============================== + drm/nouveau NVIDIA GPU Driver +=============================== + +The drm/nouveau driver provides support for a wide range of NVIDIA GPUs, +covering GeForce, Quadro, and Tesla series, from the NV04 architecture up +to the latest Turing, Ampere, Ada families. + +NVKM: NVIDIA Kernel Manager +=========================== + +The NVKM component serves as the core abstraction layer within the nouveau +driver, responsible for managing NVIDIA GPU hardware at the kernel level. +NVKM provides a unified interface for handling various GPU architectures. + +It enables resource management, power control, memory handling, and command +submission required for the proper functioning of NVIDIA GPUs under the +nouveau driver. + +NVKM plays a critical role in abstracting hardware complexities and +providing a consistent API to upper layers of the driver stack. + +GSP Support +------------------------ + +.. kernel-doc:: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c + :doc: GSP message queue element diff --git a/Documentation/gpu/nova/core/guidelines.rst b/Documentation/gpu/nova/core/guidelines.rst new file mode 100644 index 000000000000..a389d65d7982 --- /dev/null +++ b/Documentation/gpu/nova/core/guidelines.rst @@ -0,0 +1,24 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +========== +Guidelines +========== + +This documents contains the guidelines for nova-core. Additionally, all common +guidelines of the Nova project do apply. + +Driver API +========== + +One main purpose of nova-core is to implement the abstraction around the +firmware interface of GSP and provide a firmware (version) independent API for +2nd level drivers, such as nova-drm or the vGPU manager VFIO driver. + +Therefore, it is not permitted to leak firmware (version) specifics, through the +driver API, to 2nd level drivers. + +Acceptance Criteria +=================== + +- To the extend possible, patches submitted to nova-core must be tested for + regressions with all 2nd level drivers. diff --git a/Documentation/gpu/nova/core/todo.rst b/Documentation/gpu/nova/core/todo.rst new file mode 100644 index 000000000000..ca08377d3b73 --- /dev/null +++ b/Documentation/gpu/nova/core/todo.rst @@ -0,0 +1,446 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +========= +Task List +========= + +Tasks may have the following fields: + +- ``Complexity``: Describes the required familiarity with Rust and / or the + corresponding kernel APIs or subsystems. There are four different complexities, + ``Beginner``, ``Intermediate``, ``Advanced`` and ``Expert``. +- ``Reference``: References to other tasks. +- ``Link``: Links to external resources. +- ``Contact``: The person that can be contacted for further information about + the task. + +Enablement (Rust) +================= + +Tasks that are not directly related to nova-core, but are preconditions in terms +of required APIs. + +FromPrimitive API +----------------- + +Sometimes the need arises to convert a number to a value of an enum or a +structure. + +A good example from nova-core would be the ``Chipset`` enum type, which defines +the value ``AD102``. When probing the GPU the value ``0x192`` can be read from a +certain register indication the chipset AD102. Hence, the enum value ``AD102`` +should be derived from the number ``0x192``. Currently, nova-core uses a custom +implementation (``Chipset::from_u32`` for this. + +Instead, it would be desirable to have something like the ``FromPrimitive`` +trait [1] from the num crate. + +Having this generalization also helps with implementing a generic macro that +automatically generates the corresponding mappings between a value and a number. + +| Complexity: Beginner +| Link: https://docs.rs/num/latest/num/trait.FromPrimitive.html + +Generic register abstraction +---------------------------- + +Work out how register constants and structures can be automatically generated +through generalized macros. + +Example: + +.. code-block:: rust + + register!(BOOT0, 0x0, u32, pci::Bar<SIZE>, Fields [ + MINOR_REVISION(3:0, RO), + MAJOR_REVISION(7:4, RO), + REVISION(7:0, RO), // Virtual register combining major and minor rev. + ]) + +This could expand to something like: + +.. code-block:: rust + + const BOOT0_OFFSET: usize = 0x00000000; + const BOOT0_MINOR_REVISION_SHIFT: u8 = 0; + const BOOT0_MINOR_REVISION_MASK: u32 = 0x0000000f; + const BOOT0_MAJOR_REVISION_SHIFT: u8 = 4; + const BOOT0_MAJOR_REVISION_MASK: u32 = 0x000000f0; + const BOOT0_REVISION_SHIFT: u8 = BOOT0_MINOR_REVISION_SHIFT; + const BOOT0_REVISION_MASK: u32 = BOOT0_MINOR_REVISION_MASK | BOOT0_MAJOR_REVISION_MASK; + + struct Boot0(u32); + + impl Boot0 { + #[inline] + fn read(bar: &RevocableGuard<'_, pci::Bar<SIZE>>) -> Self { + Self(bar.readl(BOOT0_OFFSET)) + } + + #[inline] + fn minor_revision(&self) -> u32 { + (self.0 & BOOT0_MINOR_REVISION_MASK) >> BOOT0_MINOR_REVISION_SHIFT + } + + #[inline] + fn major_revision(&self) -> u32 { + (self.0 & BOOT0_MAJOR_REVISION_MASK) >> BOOT0_MAJOR_REVISION_SHIFT + } + + #[inline] + fn revision(&self) -> u32 { + (self.0 & BOOT0_REVISION_MASK) >> BOOT0_REVISION_SHIFT + } + } + +Usage: + +.. code-block:: rust + + let bar = bar.try_access().ok_or(ENXIO)?; + + let boot0 = Boot0::read(&bar); + pr_info!("Revision: {}\n", boot0.revision()); + +| Complexity: Advanced + +Delay / Sleep abstractions +-------------------------- + +Rust abstractions for the kernel's delay() and sleep() functions. + +FUJITA Tomonori plans to work on abstractions for read_poll_timeout_atomic() +(and friends) [1]. + +| Complexity: Beginner +| Link: https://lore.kernel.org/netdev/20250228.080550.354359820929821928.fujita.tomonori@gmail.com/ [1] + +IRQ abstractions +---------------- + +Rust abstractions for IRQ handling. + +There is active ongoing work from Daniel Almeida [1] for the "core" abstractions +to request IRQs. + +Besides optional review and testing work, the required ``pci::Device`` code +around those core abstractions needs to be worked out. + +| Complexity: Intermediate +| Link: https://lore.kernel.org/lkml/20250122163932.46697-1-daniel.almeida@collabora.com/ [1] +| Contact: Daniel Almeida + +Page abstraction for foreign pages +---------------------------------- + +Rust abstractions for pages not created by the Rust page abstraction without +direct ownership. + +There is active onging work from Abdiel Janulgue [1] and Lina [2]. + +| Complexity: Advanced +| Link: https://lore.kernel.org/linux-mm/20241119112408.779243-1-abdiel.janulgue@gmail.com/ [1] +| Link: https://lore.kernel.org/rust-for-linux/20250202-rust-page-v1-0-e3170d7fe55e@asahilina.net/ [2] + +Scatterlist / sg_table abstractions +----------------------------------- + +Rust abstractions for scatterlist / sg_table. + +There is preceding work from Abdiel Janulgue, which hasn't made it to the +mailing list yet. + +| Complexity: Intermediate +| Contact: Abdiel Janulgue + +ELF utils +--------- + +Rust implementation of ELF header representation to retrieve section header +tables, names, and data from an ELF-formatted images. + +There is preceding work from Abdiel Janulgue, which hasn't made it to the +mailing list yet. + +| Complexity: Beginner +| Contact: Abdiel Janulgue + +PCI MISC APIs +------------- + +Extend the existing PCI device / driver abstractions by SR-IOV, config space, +capability, MSI API abstractions. + +| Complexity: Beginner + +Auxiliary bus abstractions +-------------------------- + +Rust abstraction for the auxiliary bus APIs. + +This is needed to connect nova-core to the nova-drm driver. + +| Complexity: Intermediate + +Debugfs abstractions +-------------------- + +Rust abstraction for debugfs APIs. + +| Reference: Export GSP log buffers +| Complexity: Intermediate + +Vec extensions +-------------- + +Implement ``Vec::truncate`` and ``Vec::resize``. + +Currently this is used for some experimental code to parse the vBIOS. + +| Reference vBIOS support +| Complexity: Beginner + +GPU (general) +============= + +Parse firmware headers +---------------------- + +Parse ELF headers from the firmware files loaded from the filesystem. + +| Reference: ELF utils +| Complexity: Beginner +| Contact: Abdiel Janulgue + +Build radix3 page table +----------------------- + +Build the radix3 page table to map the firmware. + +| Complexity: Intermediate +| Contact: Abdiel Janulgue + +vBIOS support +------------- + +Parse the vBIOS and probe the structures required for driver initialization. + +| Contact: Dave Airlie +| Reference: Vec extensions +| Complexity: Intermediate + +Initial Devinit support +----------------------- + +Implement BIOS Device Initialization, i.e. memory sizing, waiting, PLL +configuration. + +| Contact: Dave Airlie +| Complexity: Beginner + +Boot Falcon controller +---------------------- + +Infrastructure to load and execute falcon (sec2) firmware images; handle the +GSP falcon processor and fwsec loading. + +| Complexity: Advanced +| Contact: Dave Airlie + +GPU Timer support +----------------- + +Support for the GPU's internal timer peripheral. + +| Complexity: Beginner +| Contact: Dave Airlie + +MMU / PT management +------------------- + +Work out the architecture for MMU / page table management. + +We need to consider that nova-drm will need rather fine-grained control, +especially in terms of locking, in order to be able to implement asynchronous +Vulkan queues. + +While generally sharing the corresponding code is desirable, it needs to be +evaluated how (and if at all) sharing the corresponding code is expedient. + +| Complexity: Expert + +VRAM memory allocator +--------------------- + +Investigate options for a VRAM memory allocator. + +Some possible options: + - Rust abstractions for + - RB tree (interval tree) / drm_mm + - maple_tree + - native Rust collections + +| Complexity: Advanced + +Instance Memory +--------------- + +Implement support for instmem (bar2) used to store page tables. + +| Complexity: Intermediate +| Contact: Dave Airlie + +GPU System Processor (GSP) +========================== + +Export GSP log buffers +---------------------- + +Recent patches from Timur Tabi [1] added support to expose GSP-RM log buffers +(even after failure to probe the driver) through debugfs. + +This is also an interesting feature for nova-core, especially in the early days. + +| Link: https://lore.kernel.org/nouveau/20241030202952.694055-2-ttabi@nvidia.com/ [1] +| Reference: Debugfs abstractions +| Complexity: Intermediate + +GSP firmware abstraction +------------------------ + +The GSP-RM firmware API is unstable and may incompatibly change from version to +version, in terms of data structures and semantics. + +This problem is one of the big motivations for using Rust for nova-core, since +it turns out that Rust's procedural macro feature provides a rather elegant way +to address this issue: + +1. generate Rust structures from the C headers in a separate namespace per version +2. build abstraction structures (within a generic namespace) that implement the + firmware interfaces; annotate the differences in implementation with version + identifiers +3. use a procedural macro to generate the actual per version implementation out + of this abstraction +4. instantiate the correct version type one on runtime (can be sure that all + have the same interface because it's defined by a common trait) + +There is a PoC implementation of this pattern, in the context of the nova-core +PoC driver. + +This task aims at refining the feature and ideally generalize it, to be usable +by other drivers as well. + +| Complexity: Expert + +GSP message queue +----------------- + +Implement low level GSP message queue (command, status) for communication +between the kernel driver and GSP. + +| Complexity: Advanced +| Contact: Dave Airlie + +Bootstrap GSP +------------- + +Call the boot firmware to boot the GSP processor; execute initial control +messages. + +| Complexity: Intermediate +| Contact: Dave Airlie + +Client / Device APIs +-------------------- + +Implement the GSP message interface for client / device allocation and the +corresponding client and device allocation APIs. + +| Complexity: Intermediate +| Contact: Dave Airlie + +Bar PDE handling +---------------- + +Synchronize page table handling for BARs between the kernel driver and GSP. + +| Complexity: Beginner +| Contact: Dave Airlie + +FIFO engine +----------- + +Implement support for the FIFO engine, i.e. the corresponding GSP message +interface and provide an API for chid allocation and channel handling. + +| Complexity: Advanced +| Contact: Dave Airlie + +GR engine +--------- + +Implement support for the graphics engine, i.e. the corresponding GSP message +interface and provide an API for (golden) context creation and promotion. + +| Complexity: Advanced +| Contact: Dave Airlie + +CE engine +--------- + +Implement support for the copy engine, i.e. the corresponding GSP message +interface. + +| Complexity: Intermediate +| Contact: Dave Airlie + +VFN IRQ controller +------------------ + +Support for the VFN interrupt controller. + +| Complexity: Intermediate +| Contact: Dave Airlie + +External APIs +============= + +nova-core base API +------------------ + +Work out the common pieces of the API to connect 2nd level drivers, i.e. vGPU +manager and nova-drm. + +| Complexity: Advanced + +vGPU manager API +---------------- + +Work out the API parts required by the vGPU manager, which are not covered by +the base API. + +| Complexity: Advanced + +nova-core C API +--------------- + +Implement a C wrapper for the APIs required by the vGPU manager driver. + +| Complexity: Intermediate + +Testing +======= + +CI pipeline +----------- + +Investigate option for continuous integration testing. + +This can go from as simple as running KUnit tests over running (graphics) CTS to +booting up (multiple) guest VMs to test VFIO use-cases. + +It might also be worth to consider the introduction of a new test suite directly +sitting on top of the uAPI for more targeted testing and debugging. There may be +options for collaboration / shared code with the Mesa project. + +| Complexity: Advanced diff --git a/Documentation/gpu/nova/guidelines.rst b/Documentation/gpu/nova/guidelines.rst new file mode 100644 index 000000000000..13ab13984a18 --- /dev/null +++ b/Documentation/gpu/nova/guidelines.rst @@ -0,0 +1,69 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +========== +Guidelines +========== + +This document describes the general project guidelines that apply to nova-core +and nova-drm. + +Language +======== + +The Nova project uses the Rust programming language. In this context, all rules +of the Rust for Linux project as documented in +:doc:`../../rust/general-information` apply. Additionally, the following rules +apply. + +- Unless technically necessary otherwise (e.g. uAPI), any driver code is written + in Rust. + +- Unless technically necessary, unsafe Rust code must be avoided. In case of + technical necessity, unsafe code should be isolated in a separate component + providing a safe API for other driver code to use. + +Style +----- + +All rules of the Rust for Linux project as documented in +:doc:`../../rust/coding-guidelines` apply. + +For a submit checklist, please also see the `Rust for Linux Submit checklist +addendum <https://rust-for-linux.com/contributing#submit-checklist-addendum>`_. + +Documentation +============= + +The availability of proper documentation is essential in terms of scalability, +accessibility for new contributors and maintainability of a project in general, +but especially for a driver running as complex hardware as Nova is targeting. + +Hence, adding documentation of any kind is very much encouraged by the project. + +Besides that, there are some minimum requirements. + +- Every non-private structure needs at least a brief doc comment explaining the + semantical sense of the structure, as well as potential locking and lifetime + requirements. It is encouraged to have the same minimum documentation for + non-trivial private structures. + +- uAPIs must be fully documented with kernel-doc comments; additionally, the + semantical behavior must be explained including potential special or corner + cases. + +- The APIs connecting the 1st level driver (nova-core) with 2nd level drivers + must be fully documented. This includes doc comments, potential locking and + lifetime requirements, as well as example code if applicable. + +- Abbreviations must be explained when introduced; terminology must be uniquely + defined. + +- Register addresses, layouts, shift values and masks must be defined properly; + unless obvious, the semantical sense must be documented. This only applies if + the author is able to obtain the corresponding information. + +Acceptance Criteria +=================== + +- Patches must only be applied if reviewed by at least one other person on the + mailing list; this also applies for maintainers. diff --git a/Documentation/gpu/nova/index.rst b/Documentation/gpu/nova/index.rst new file mode 100644 index 000000000000..2701b3f4af35 --- /dev/null +++ b/Documentation/gpu/nova/index.rst @@ -0,0 +1,30 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +======================= +nova NVIDIA GPU drivers +======================= + +The nova driver project consists out of two separate drivers nova-core and +nova-drm and intends to supersede the nouveau driver for NVIDIA GPUs based on +the GPU System Processor (GSP). + +The following documents apply to both nova-core and nova-drm. + +.. toctree:: + :titlesonly: + + guidelines + +nova-core +========= + +The nova-core driver is the core driver for NVIDIA GPUs based on GSP. nova-core, +as the 1st level driver, provides an abstraction around the GPUs hard- and +firmware interfaces providing a common base for 2nd level drivers, such as the +vGPU manager VFIO driver and the nova-drm driver. + +.. toctree:: + :titlesonly: + + core/guidelines + core/todo diff --git a/Documentation/gpu/panthor.rst b/Documentation/gpu/panthor.rst index 3f8979fa2b86..7a841741278f 100644 --- a/Documentation/gpu/panthor.rst +++ b/Documentation/gpu/panthor.rst @@ -26,6 +26,8 @@ the currently possible format options: drm-cycles-panthor: 94439687187 drm-maxfreq-panthor: 1000000000 Hz drm-curfreq-panthor: 1000000000 Hz + panthor-resident-memory: 10396 KiB + panthor-active-memory: 10396 KiB drm-total-memory: 16480 KiB drm-shared-memory: 0 drm-active-memory: 16200 KiB @@ -44,3 +46,11 @@ driver by writing into the appropriate sysfs node:: Where `N` is a bit mask where cycle and timestamp sampling are respectively enabled by the first and second bits. + +Possible `panthor-*-memory` keys are: `active` and `resident`. +These values convey the sizes of the internal driver-owned shmem BO's that +aren't exposed to user-space through a DRM handle, like queue ring buffers, +sync object arrays and heap chunks. Because they are all allocated and pinned +at creation time, only `panthor-resident-memory` is necessary to tell us their +size. `panthor-active-memory` shows the size of kernel BO's associated with +VM's and groups currently being scheduled for execution by the GPU. diff --git a/Documentation/gpu/rfc/gpusvm.rst b/Documentation/gpu/rfc/gpusvm.rst new file mode 100644 index 000000000000..bcf66a8137a6 --- /dev/null +++ b/Documentation/gpu/rfc/gpusvm.rst @@ -0,0 +1,112 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +=============== +GPU SVM Section +=============== + +Agreed upon design principles +============================= + +* migrate_to_ram path + * Rely only on core MM concepts (migration PTEs, page references, and + page locking). + * No driver specific locks other than locks for hardware interaction in + this path. These are not required and generally a bad idea to + invent driver defined locks to seal core MM races. + * An example of a driver-specific lock causing issues occurred before + fixing do_swap_page to lock the faulting page. A driver-exclusive lock + in migrate_to_ram produced a stable livelock if enough threads read + the faulting page. + * Partial migration is supported (i.e., a subset of pages attempting to + migrate can actually migrate, with only the faulting page guaranteed + to migrate). + * Driver handles mixed migrations via retry loops rather than locking. +* Eviction + * Eviction is defined as migrating data from the GPU back to the + CPU without a virtual address to free up GPU memory. + * Only looking at physical memory data structures and locks as opposed to + looking at virtual memory data structures and locks. + * No looking at mm/vma structs or relying on those being locked. + * The rationale for the above two points is that CPU virtual addresses + can change at any moment, while the physical pages remain stable. + * GPU page table invalidation, which requires a GPU virtual address, is + handled via the notifier that has access to the GPU virtual address. +* GPU fault side + * mmap_read only used around core MM functions which require this lock + and should strive to take mmap_read lock only in GPU SVM layer. + * Big retry loop to handle all races with the mmu notifier under the gpu + pagetable locks/mmu notifier range lock/whatever we end up calling + those. + * Races (especially against concurrent eviction or migrate_to_ram) + should not be handled on the fault side by trying to hold locks; + rather, they should be handled using retry loops. One possible + exception is holding a BO's dma-resv lock during the initial migration + to VRAM, as this is a well-defined lock that can be taken underneath + the mmap_read lock. + * One possible issue with the above approach is if a driver has a strict + migration policy requiring GPU access to occur in GPU memory. + Concurrent CPU access could cause a livelock due to endless retries. + While no current user (Xe) of GPU SVM has such a policy, it is likely + to be added in the future. Ideally, this should be resolved on the + core-MM side rather than through a driver-side lock. +* Physical memory to virtual backpointer + * This does not work, as no pointers from physical memory to virtual + memory should exist. mremap() is an example of the core MM updating + the virtual address without notifying the driver of address + change rather the driver only receiving the invalidation notifier. + * The physical memory backpointer (page->zone_device_data) should remain + stable from allocation to page free. Safely updating this against a + concurrent user would be very difficult unless the page is free. +* GPU pagetable locking + * Notifier lock only protects range tree, pages valid state for a range + (rather than seqno due to wider notifiers), pagetable entries, and + mmu notifier seqno tracking, it is not a global lock to protect + against races. + * All races handled with big retry as mentioned above. + +Overview of baseline design +=========================== + +.. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c + :doc: Overview + +.. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c + :doc: Locking + +.. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c + :doc: Migration + +.. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c + :doc: Partial Unmapping of Ranges + +.. kernel-doc:: drivers/gpu/drm/drm_gpusvm.c + :doc: Examples + +Possible future design features +=============================== + +* Concurrent GPU faults + * CPU faults are concurrent so makes sense to have concurrent GPU + faults. + * Should be possible with fined grained locking in the driver GPU + fault handler. + * No expected GPU SVM changes required. +* Ranges with mixed system and device pages + * Can be added if required to drm_gpusvm_get_pages fairly easily. +* Multi-GPU support + * Work in progress and patches expected after initially landing on GPU + SVM. + * Ideally can be done with little to no changes to GPU SVM. +* Drop ranges in favor of radix tree + * May be desirable for faster notifiers. +* Compound device pages + * Nvidia, AMD, and Intel all have agreed expensive core MM functions in + migrate device layer are a performance bottleneck, having compound + device pages should help increase performance by reducing the number + of these expensive calls. +* Higher order dma mapping for migration + * 4k dma mapping adversely affects migration performance on Intel + hardware, higher order (2M) dma mapping should help here. +* Build common userptr implementation on top of GPU SVM +* Driver side madvise implementation and migration policies +* Pull in pending dma-mapping API changes from Leon / Nvidia when these land diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index 476719771eef..396e535377fb 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -18,6 +18,10 @@ host such documentation: .. toctree:: + gpusvm.rst + +.. toctree:: + i915_gem_lmem.rst .. toctree:: diff --git a/Documentation/iio/ad4030.rst b/Documentation/iio/ad4030.rst new file mode 100644 index 000000000000..b57424b650a8 --- /dev/null +++ b/Documentation/iio/ad4030.rst @@ -0,0 +1,180 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +============= +AD4030 driver +============= + +ADC driver for Analog Devices Inc. AD4030 and similar devices. The module name +is ``ad4030``. + + +Supported devices +================= + +The following chips are supported by this driver: + +* `AD4030-24 <https://www.analog.com/AD4030-24>`_ +* `AD4032-24 <https://www.analog.com/AD4032-24>`_ +* `AD4630-16 <https://www.analog.com/AD4630-16>`_ +* `AD4630-24 <https://www.analog.com/AD4630-24>`_ +* `AD4632-16 <https://www.analog.com/AD4632-16>`_ +* `AD4632-24 <https://www.analog.com/AD4632-24>`_ + +IIO channels +============ + +Each "hardware" channel as described in the datasheet is split in 2 IIO +channels: + +- One channel for the differential data +- One channel for the common byte. + +The possible IIO channels depending on the numbers of "hardware" channel are: + ++------------------------------------+------------------------------------+ +| 1 channel ADC | 2 channels ADC | ++====================================+====================================+ +| - voltage0-voltage1 (differential) | - voltage0-voltage1 (differential) | +| - voltage2 (common-mode) | - voltage2-voltage3 (differential) | +| | - voltage4 (common-mode) | +| | - voltage5 (common-mode) | ++------------------------------------+------------------------------------+ + +Labels +------ + +For ease of use, the IIO channels provide a label. For a differential channel, +the label is ``differentialN`` where ``N`` is the "hardware" channel id. For a +common-mode channel, the label is ``common-modeN`` where ``N`` is the +"hardware" channel id. + +The possible labels are: + ++-----------------+-----------------+ +| 1 channel ADC | 2 channels ADC | ++=================+=================+ +| - differential0 | - differential0 | +| - common-mode0 | - differential1 | +| | - common-mode0 | +| | - common-mode1 | ++-----------------+-----------------+ + +Supported features +================== + +SPI wiring modes +---------------- + +The driver currently supports the following SPI wiring configurations: + +One lane mode +^^^^^^^^^^^^^ + +In this mode, each channel has its own SDO line to send the conversion results. +At the moment this mode can only be used on AD4030 which has one channel so only +one SDO line is used. + +.. code-block:: + + +-------------+ +-------------+ + | ADC | | HOST | + | | | | + | CNV |<--------| CNV | + | CS |<--------| CS | + | SDI |<--------| SDO | + | SDO0 |-------->| SDI | + | SCLK |<--------| SCLK | + +-------------+ +-------------+ + +Interleaved mode +^^^^^^^^^^^^^^^^ + +In this mode, both channels conversion results are bit interleaved one SDO line. +As such the wiring is the same as `One lane mode`_. + +SPI Clock mode +-------------- + +Only the SPI clocking mode is supported. + +Output modes +------------ + +There are more exposed IIO channels than channels as describe in the devices +datasheet. This is due to the `Differential data + common-mode`_ encoding +2 types of information in one conversion result. As such a "device" channel +provides 2 IIO channels, one for the differential data and one for the common +byte. + +Differential data +^^^^^^^^^^^^^^^^^ + +This mode is selected when: + +- Only differential channels are enabled in a buffered read +- Oversampling attribute is set to 1 + +Differential data + common-mode +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This mode is selected when: + +- Differential and common-mode channels are enabled in a buffered read +- Oversampling attribute is set to 1 + +For the 24-bits chips, this mode is also available with 16-bits differential +data but is not selectable yet. + +Averaged differential data +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This mode is selected when: + +- Only differential channels are selected enabled in a buffered read +- Oversampling attribute is greater than 1 + +Digital Gain and Offset +----------------------- + +Each differential data channel has a 16-bits unsigned configurable hardware +gain applied to it. By default it's equal to 1. Note that applying gain can +cause numerical saturation. + +Each differential data channel has a signed configurable hardware offset. +For the ADCs ending in ``-24``, the gain is encoded on 24-bits. +Likewise, the ADCs ending in ``-16`` have a gain encoded on 16-bits. Note that +applying an offset can cause numerical saturation. + +The final differential data returned by the ADC is computed by first applying +the gain, then the offset. + +The gain is controlled by the ``calibscale`` IIO attribute while the offset is +controlled by the ``calibbias`` attribute. + +Reference voltage +----------------- + +The chip supports an external reference voltage via the ``REF`` input or an +internal buffered reference voltage via the ``REFIN`` input. The driver looks +at the device tree to determine which is being used. If ``ref-supply`` is +present, then the external reference voltage is used and the internal buffer is +disabled. If ``refin-supply`` is present, then the internal buffered reference +voltage is used. + +Reset +----- + +Both hardware and software reset are supported. The driver looks first at the +device tree to see if the ``reset-gpio`` is populated. +If not present, the driver will fallback to a software reset by wiring to the +device's registers. + +Unimplemented features +---------------------- + +- ``BUSY`` indication +- Additional wiring modes +- Additional clock modes +- Differential data 16-bits + common-mode for 24-bits chips +- Overrange events +- Test patterns diff --git a/Documentation/iio/ad4695.rst b/Documentation/iio/ad4695.rst index 9ec8bf466c15..f40593bcc37d 100644 --- a/Documentation/iio/ad4695.rst +++ b/Documentation/iio/ad4695.rst @@ -47,6 +47,36 @@ In this mode, CNV and CS are tied together and there is a single SDO line. To use this mode, in the device tree, omit the ``cnv-gpios`` and ``spi-rx-bus-width`` properties. +SPI offload wiring +^^^^^^^^^^^^^^^^^^ + +When used with a SPI offload, the supported wiring configuration is: + +.. code-block:: + + +-------------+ +-------------+ + | GP0/BUSY |-------->| TRIGGER | + | CS |<--------| CS | + | | | | + | ADC | | SPI | + | | | | + | SDI |<--------| SDO | + | SDO |-------->| SDI | + | SCLK |<--------| SCLK | + | | | | + | | +-------------+ + | CNV |<-----+--| PWM | + | | +--| GPIO | + +-------------+ +-------------+ + +In this case, both the ``cnv-gpios`` and ``pwms`` properties are required. +The ``#trigger-source-cells = <2>`` property is also required to connect back +to the SPI offload. The SPI offload will have ``trigger-sources`` property +with cells to indicate the busy signal and which GPx pin is used, e.g +``<&ad4695 AD4695_TRIGGER_EVENT_BUSY AD4695_TRIGGER_PIN_GP0>``. + +.. seealso:: `SPI offload support`_ + Channel configuration --------------------- @@ -149,15 +179,62 @@ Gain/offset calibration System calibration is supported using the channel gain and offset registers via the ``calibscale`` and ``calibbias`` attributes respectively. +Oversampling +------------ + +The chip supports per-channel oversampling when SPI offload is being used, with +available oversampling ratios (OSR) of 1 (default), 4, 16, and 64. Enabling +oversampling on a channel raises the effective number of bits of sampled data to +17 (OSR == 4), 18 (16), or 19 (64), respectively. This can be set via the +``oversampling_ratio`` attribute. + +Setting the oversampling ratio for a channel also changes the sample rate for +that channel, since it requires multiple conversions per 1 sample. Specifically, +the new sampling frequency is the PWM sampling frequency divided by the +particular OSR. This is set automatically by the driver when setting the +``oversampling_ratio`` attribute. For example, if the device's current +``sampling_frequency`` is 10000 and an OSR of 4 is set on channel ``voltage0``, +the new reported sampling rate for that channel will be 2500 (ignoring PWM API +rounding), while all others will remain at 10000. Subsequently setting the +sampling frequency to a higher value on that channel will adjust the CNV trigger +period for all channels, e.g. if ``voltage0``'s sampling frequency is adjusted +from 2500 (with an OSR of 4) to 10000, the value reported by +``in_voltage0_sampling_frequency`` will be 10000, but all other channels will +now report 40000. + +For simplicity, the sampling frequency of the device should be set (considering +the highest desired OSR value to be used) first, before configuring oversampling +for specific channels. + Unimplemented features ---------------------- - Additional wiring modes - Threshold events -- Oversampling - GPIO support - CRC support +SPI offload support +=================== + +To be able to achieve the maximum sample rate, the driver can be used with the +`AXI SPI Engine`_ to provide SPI offload support. + +.. _AXI SPI Engine: http://analogdevicesinc.github.io/hdl/projects/ad469x_fmc/index.html + +.. seealso:: `SPI offload wiring`_ + +When SPI offload is being used, some attributes will be different. + +* ``trigger`` directory is removed. +* ``in_voltage0_sampling_frequency`` attributes are added for setting the sample + rate. +* ``in_voltage0_sampling_frequency_available`` attributes are added for querying + the max sample rate. +* ``timestamp`` channel is removed. +* Buffer data format may be different compared to when offload is not used, + e.g. the ``buffer0/in_voltage0_type`` attribute. + Device buffers ============== @@ -165,3 +242,28 @@ This driver supports hardware triggered buffers. This uses the "advanced sequencer" feature of the chip to trigger a burst of conversions. Also see :doc:`iio_devbuf` for more general information. + +Effective sample rate for buffered reads +---------------------------------------- + +When SPI offload is not used, the sample rate is determined by the trigger that +is manually configured in userspace. All enabled channels will be read in a +burst when the trigger is received. + +When SPI offload is used, the sample rate is configured per channel. All +channels will have the same rate, so only one ``in_voltageY_sampling_frequency`` +attribute needs to be set. Since this rate determines the delay between each +individual conversion, the effective sample rate for each sample is actually +the sum of the periods of each enabled channel in a buffered read. In other +words, it is the value of the ``in_voltageY_sampling_frequency`` attribute +divided by the number of enabled channels. So if 4 channels are enabled, with +the ``in_voltageY_sampling_frequency`` attributes set to 1 MHz, the effective +sample rate is 250 kHz. + +With oversampling enabled, the effective sample rate also depends on the OSR +assigned to each channel. For example, if one of the 4 channels mentioned in the +previous case is configured with an OSR of 4, the effective sample rate for that +channel becomes (1 MHz / 4 ) = 250 kHz. The effective sample rate for all +four channels is then 1 / ( (3 / 1 MHz) + ( 1 / 250 kHz) ) ~= 142.9 kHz. Note +that in this case "sample" refers to one read of all enabled channels (i.e. one +full cycle through the auto-sequencer). diff --git a/Documentation/iio/ad7191.rst b/Documentation/iio/ad7191.rst new file mode 100644 index 000000000000..977d4fea14b0 --- /dev/null +++ b/Documentation/iio/ad7191.rst @@ -0,0 +1,119 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +============= +AD7191 driver +============= + +Device driver for Analog Devices AD7191 ADC. + +Supported devices +================= + +* `AD7191 <https://www.analog.com/AD7191>`_ + +The AD7191 is a high precision, low noise, 24-bit Σ-Δ ADC with integrated PGA. +It features two differential input channels, an internal temperature sensor, and +configurable sampling rates. + +Devicetree +========== + +Pin Configuration +----------------- + +The driver supports both pin-strapped and GPIO-controlled configurations for ODR +(Output Data Rate) and PGA (Programmable Gain Amplifier) settings. These +configurations are mutually exclusive - you must use either pin-strapped or GPIO +control for each setting, not both. + +ODR Configuration +^^^^^^^^^^^^^^^^^ + +The ODR can be configured either through GPIO control or pin-strapping: + +- When using GPIO control, specify the "odr-gpios" property in the device tree +- For pin-strapped configuration, specify the "adi,odr-value" property in the + device tree + +Available ODR settings: + + - 120 Hz (ODR1=0, ODR2=0) + - 60 Hz (ODR1=0, ODR2=1) + - 50 Hz (ODR1=1, ODR2=0) + - 10 Hz (ODR1=1, ODR2=1) + +PGA Configuration +^^^^^^^^^^^^^^^^^ + +The PGA can be configured either through GPIO control or pin-strapping: + +- When using GPIO control, specify the "pga-gpios" property in the device tree +- For pin-strapped configuration, specify the "adi,pga-value" property in the + device tree + +Available PGA gain settings: + + - 1x (PGA1=0, PGA2=0) + - 8x (PGA1=0, PGA2=1) + - 64x (PGA1=1, PGA2=0) + - 128x (PGA1=1, PGA2=1) + +Clock Configuration +------------------- + +The AD7191 supports both internal and external clock sources: + +- When CLKSEL pin is tied LOW: Uses internal 4.92MHz clock (no clock property + needed) +- When CLKSEL pin is tied HIGH: Requires external clock source + - Can be a crystal between MCLK1 and MCLK2 pins + - Or a CMOS-compatible clock driving MCLK2 pin + - Must specify the "clocks" property in device tree when using external clock + +SPI Interface Requirements +-------------------------- + +The AD7191 has specific SPI interface requirements: + +- The DOUT/RDY output is dual-purpose and requires SPI bus locking +- DOUT/RDY must be connected to an interrupt-capable GPIO +- The SPI controller's chip select must be connected to the PDOWN pin of the ADC +- When CS (PDOWN) is high, the device powers down and resets internal circuitry +- SPI mode 3 operation (CPOL=1, CPHA=1) is required + +Power Supply Requirements +------------------------- + +The device requires the following power supplies: + +- AVdd: Analog power supply +- DVdd: Digital power supply +- Vref: Reference voltage supply (external) + +All power supplies must be specified in the device tree. + +Channel Configuration +===================== + +The device provides three channels: + +1. Temperature Sensor + - 24-bit unsigned + - Internal temperature measurement + - Temperature in millidegrees Celsius + +2. Differential Input (AIN1-AIN2) + - 24-bit unsigned + - Differential voltage measurement + - Configurable gain via PGA + +3. Differential Input (AIN3-AIN4) + - 24-bit unsigned + - Differential voltage measurement + - Configurable gain via PGA + +Buffer Support +============== + +This driver supports IIO triggered buffers. See Documentation/iio/iio_devbuf.rst +for more information about IIO triggered buffers. diff --git a/Documentation/iio/ad7380.rst b/Documentation/iio/ad7380.rst index c46127700e14..24a92a1c4371 100644 --- a/Documentation/iio/ad7380.rst +++ b/Documentation/iio/ad7380.rst @@ -29,6 +29,7 @@ The following chips are supported by this driver: * `AD7388-4 <https://www.analog.com/en/products/ad7388-4.html>`_ * `ADAQ4370-4 <https://www.analog.com/en/products/adaq4370-4.html>`_ * `ADAQ4380-4 <https://www.analog.com/en/products/adaq4380-4.html>`_ +* `ADAQ4381-4 <https://www.analog.com/en/products/adaq4381-4.html>`_ Supported features @@ -52,8 +53,8 @@ declared in the device tree as ``refin-supply``. ADAQ devices ~~~~~~~~~~~~ -adaq4370-4 and adaq4380-4 don't have an external reference, but use a 3.3V -internal reference derived from one of its supplies (``refin-supply``) +ADAQ devices don't have an external reference, but use a 3.3V internal reference +derived from one of its supplies (``refin-supply``) All other devices from ad738x family ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -92,6 +93,38 @@ must restart iiod using the following command: root:~# systemctl restart iiod +Alert +----- + +2 channels variants of the ad738x family, can use the SDOB line as an alert pin +when configured in 1 SDO line mode. 4 channels variants, can use SDOD as an +alert pin when configured in 1 or 2 SDO line(s) mode, although only 1 SDO line +mode is currently supported by the driver (see `SPI wiring modes`_). + +At the end of a conversion the active-low alert pin gets asserted if the +conversion result exceeds the alert high limit or falls below the alert low +limit. It is cleared, on a falling edge of CS. The alert pin is common to all +channels. + +User can enable alert using the regular iio events attribute: + +.. code-block:: bash + + events/thresh_either_en + +The high and low thresholds are common to all channels and can also be set using +regular iio events attributes: + +.. code-block:: bash + + events/in_thresh_falling_value + events/in_thresh_rising_value + +If debugfs is available, user can read the ALERT register to determine the +faulty channel and direction. + +In most use cases, user will hardwire the alert pin to trigger a shutdown. + Channel selection and sequencer (single-end chips only) ------------------------------------------------------- @@ -144,8 +177,25 @@ Unimplemented features - Rolling average oversampling - Power down mode - CRC indication -- Alert +SPI offload support +=================== + +To be able to achieve the maximum sample rate, the driver can be used with the +`AXI SPI Engine`_ to provide SPI offload support. + +.. _AXI SPI Engine: http://analogdevicesinc.github.io/hdl/projects/pulsar_adc/index.html + +When SPI offload is being used, some attributes will be different. + +* ``trigger`` directory is removed. +* ``in_voltage0_sampling_frequency`` attribute is added for setting the sample + rate. +* ``in_voltage0_sampling_frequency_available`` attribute is added for querying + the max sample rate. +* ``timestamp`` channel is removed. +* Buffer data format may be different compared to when offload is not used, + e.g. the ``in_voltage0_type`` attribute. Device buffers ============== diff --git a/Documentation/iio/ad7944.rst b/Documentation/iio/ad7944.rst index 0d26e56aba88..e6dbe4d7f58c 100644 --- a/Documentation/iio/ad7944.rst +++ b/Documentation/iio/ad7944.rst @@ -46,6 +46,8 @@ CS mode, 3-wire, without busy indicator To select this mode in the device tree, set the ``adi,spi-mode`` property to ``"single"`` and omit the ``cnv-gpios`` property. +This is the only wiring configuration supported when using `SPI offload support`_. + CS mode, 4-wire, without busy indicator ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -106,7 +108,6 @@ Unimplemented features ---------------------- - ``BUSY`` indication -- ``TURBO`` mode Device attributes @@ -147,6 +148,27 @@ AD7986 is a fully-differential ADC and has the following attributes: In "chain" mode, additional chips will appear as additional voltage input channels, e.g. ``in_voltage2-voltage3_raw``. +SPI offload support +=================== + +To be able to achieve the maximum sample rate, the driver can be used with the +`AXI SPI Engine`_ to provide SPI offload support. + +.. _AXI SPI Engine: http://analogdevicesinc.github.io/hdl/projects/pulsar_adc/index.html + +When SPI offload is being used, some attributes will be different. + +* ``trigger`` directory is removed. +* ``in_voltage0_sampling_frequency`` attribute is added for setting the sample + rate. +* ``in_voltage0_sampling_frequency_available`` attribute is added for querying + the max sample rate. +* ``timestamp`` channel is removed. +* Buffer data format may be different compared to when offload is not used, + e.g. the ``in_voltage0_type`` attribute. + +If the ``turbo-gpios`` property is present in the device tree, the driver will +turn on TURBO during buffered reads and turn it off otherwise. Device buffers ============== diff --git a/Documentation/iio/adis16550.rst b/Documentation/iio/adis16550.rst new file mode 100644 index 000000000000..25db7b8060c4 --- /dev/null +++ b/Documentation/iio/adis16550.rst @@ -0,0 +1,376 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================ +ADIS16550 driver +================ + +This driver supports Analog Device's IMUs on SPI bus. + +1. Supported devices +==================== + +* `ADIS16550 <https://www.analog.com/ADIS16550>`_ + +The ADIS16550 is a complete inertial system that includes a triaxis gyroscope +and a triaxis accelerometer. The factory calibration characterizes each sensor for +sensitivity, bias, and alignment. As a result, each sensor has its own dynamic +compensation formulas that provide accurate sensor measurements. + +2. Device attributes +==================== + +Accelerometer, gyroscope measurements are always provided. Furthermore, the +driver offers the capability to retrieve the delta angle and the delta velocity +measurements computed by the device. + +The delta angle measurements represent a calculation of angular displacement +between each sample update, while the delta velocity measurements represent a +calculation of linear velocity change between each sample update. + +Finally, temperature data are provided which show a coarse measurement of +the temperature inside of the IMU device. This data is most useful for +monitoring relative changes in the thermal environment. + +Each IIO device, has a device folder under ``/sys/bus/iio/devices/iio:deviceX``, +where X is the IIO index of the device. Under these folders reside a set of +device files, depending on the characteristics and features of the hardware +device in questions. These files are consistently generalized and documented in +the IIO ABI documentation. + +The following tables show the adis16550 related device files, found in the +specific device folder path ``/sys/bus/iio/devices/iio:deviceX``. + ++-------------------------------------------+----------------------------------------------------------+ +| 3-Axis Accelerometer related device files | Description | ++-------------------------------------------+----------------------------------------------------------+ +| in_accel_scale | Scale for the accelerometer channels. | ++-------------------------------------------+----------------------------------------------------------+ +| in_accel_filter_low_pass_3db_frequency | Bandwidth for the accelerometer channels. | ++-------------------------------------------+----------------------------------------------------------+ +| in_accel_x_calibbias | Calibration offset for the X-axis accelerometer channel. | ++-------------------------------------------+----------------------------------------------------------+ +| in_accel_x_calibscale | Calibration scale for the X-axis accelerometer channel. | ++-------------------------------------------+----------------------------------------------------------+ +| in_accel_x_raw | Raw X-axis accelerometer channel value. | ++-------------------------------------------+----------------------------------------------------------+ +| in_accel_y_calibbias | Calibration offset for the Y-axis accelerometer channel. | ++-------------------------------------------+----------------------------------------------------------+ +| in_accel_y_calibscale | Calibration scale for the Y-axis accelerometer channel. | ++-------------------------------------------+----------------------------------------------------------+ +| in_accel_y_raw | Raw Y-axis accelerometer channel value. | ++-------------------------------------------+----------------------------------------------------------+ +| in_accel_z_calibbias | Calibration offset for the Z-axis accelerometer channel. | ++-------------------------------------------+----------------------------------------------------------+ +| in_accel_z_calibscale | Calibration scale for the Z-axis accelerometer channel. | ++-------------------------------------------+----------------------------------------------------------+ +| in_accel_z_raw | Raw Z-axis accelerometer channel value. | ++-------------------------------------------+----------------------------------------------------------+ +| in_deltavelocity_scale | Scale for delta velocity channels. | ++-------------------------------------------+----------------------------------------------------------+ +| in_deltavelocity_x_raw | Raw X-axis delta velocity channel value. | ++-------------------------------------------+----------------------------------------------------------+ +| in_deltavelocity_y_raw | Raw Y-axis delta velocity channel value. | ++-------------------------------------------+----------------------------------------------------------+ +| in_deltavelocity_z_raw | Raw Z-axis delta velocity channel value. | ++-------------------------------------------+----------------------------------------------------------+ + ++--------------------------------------------+------------------------------------------------------+ +| 3-Axis Gyroscope related device files | Description | ++--------------------------------------------+------------------------------------------------------+ +| in_anglvel_scale | Scale for the gyroscope channels. | ++--------------------------------------------+------------------------------------------------------+ +| in_anglvel_filter_low_pass_3db_frequency | Scale for the gyroscope channels. | ++--------------------------------------------+------------------------------------------------------+ +| in_anglvel_x_calibbias | Calibration offset for the X-axis gyroscope channel. | ++--------------------------------------------+------------------------------------------------------+ +| in_anglvel_x_calibscale | Calibration scale for the X-axis gyroscope channel. | ++--------------------------------------------+------------------------------------------------------+ +| in_anglvel_x_raw | Raw X-axis gyroscope channel value. | ++--------------------------------------------+------------------------------------------------------+ +| in_anglvel_y_calibbias | Calibration offset for the Y-axis gyroscope channel. | ++--------------------------------------------+------------------------------------------------------+ +| in_anglvel_y_calibscale | Calibration scale for the Y-axis gyroscope channel. | ++--------------------------------------------+------------------------------------------------------+ +| in_anglvel_y_raw | Raw Y-axis gyroscope channel value. | ++--------------------------------------------+------------------------------------------------------+ +| in_anglvel_z_calibbias | Calibration offset for the Z-axis gyroscope channel. | ++--------------------------------------------+------------------------------------------------------+ +| in_anglvel_z_calibscale | Calibration scale for the Z-axis gyroscope channel. | ++--------------------------------------------+------------------------------------------------------+ +| in_anglvel_z_raw | Raw Z-axis gyroscope channel value. | ++--------------------------------------------+------------------------------------------------------+ +| in_deltaangl_scale | Scale for delta angle channels. | ++--------------------------------------------+------------------------------------------------------+ +| in_deltaangl_x_raw | Raw X-axis delta angle channel value. | ++--------------------------------------------+------------------------------------------------------+ +| in_deltaangl_y_raw | Raw Y-axis delta angle channel value. | ++--------------------------------------------+------------------------------------------------------+ +| in_deltaangl_z_raw | Raw Z-axis delta angle channel value. | ++--------------------------------------------+------------------------------------------------------+ + ++----------------------------------+-------------------------------------------+ +| Temperature sensor related files | Description | ++----------------------------------+-------------------------------------------+ +| in_temp0_raw | Raw temperature channel value. | ++----------------------------------+-------------------------------------------+ +| in_temp0_offset | Offset for the temperature sensor channel.| ++----------------------------------+-------------------------------------------+ +| in_temp0_scale | Scale for the temperature sensor channel. | ++----------------------------------+-------------------------------------------+ + ++----------------------------+--------------------------------------------------------------------------------+ +| Miscellaneous device files | Description | ++----------------------------+--------------------------------------------------------------------------------+ +| name | Name of the IIO device. | ++----------------------------+--------------------------------------------------------------------------------+ +| sampling_frequency | Currently selected sample rate. | ++----------------------------+--------------------------------------------------------------------------------+ + +The following table shows the adis16550 related device debug files, found in the +specific device debug folder path ``/sys/kernel/debug/iio/iio:deviceX``. + ++----------------------+-------------------------------------------------------------------------+ +| Debugfs device files | Description | ++----------------------+-------------------------------------------------------------------------+ +| serial_number | The serial number of the chip in hexadecimal format. | ++----------------------+-------------------------------------------------------------------------+ +| product_id | Chip specific product id (16550). | ++----------------------+-------------------------------------------------------------------------+ +| flash_count | The number of flash writes performed on the device. | ++----------------------+-------------------------------------------------------------------------+ +| firmware_revision | String containing the firmware revision in the following format ##.##. | ++----------------------+-------------------------------------------------------------------------+ +| firmware_date | String containing the firmware date in the following format mm-dd-yyyy. | ++----------------------+-------------------------------------------------------------------------+ + +Channels processed values +------------------------- + +A channel value can be read from its _raw attribute. The value returned is the +raw value as reported by the devices. To get the processed value of the channel, +apply the following formula: + +.. code-block:: bash + + processed value = (_raw + _offset) * _scale + +Where _offset and _scale are device attributes. If no _offset attribute is +present, simply assume its value is 0. + +The adis16550 driver offers data for 5 types of channels, the table below shows +the measurement units for the processed value, which are defined by the IIO +framework: + ++--------------------------------------+---------------------------+ +| Channel type | Measurement unit | ++--------------------------------------+---------------------------+ +| Acceleration on X, Y, and Z axis | Meters per Second squared | ++--------------------------------------+---------------------------+ +| Angular velocity on X, Y and Z axis | Radians per second | ++--------------------------------------+---------------------------+ +| Delta velocity on X. Y, and Z axis | Meters per Second | ++--------------------------------------+---------------------------+ +| Delta angle on X, Y, and Z axis | Radians | ++--------------------------------------+---------------------------+ +| Temperature | Millidegrees Celsius | ++--------------------------------------+---------------------------+ + +Usage examples +-------------- + +Show device name: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> cat name + adis16550 + +Show accelerometer channels value: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_raw + 6903851 + root:/sys/bus/iio/devices/iio:device0> cat in_accel_y_raw + 5650550 + root:/sys/bus/iio/devices/iio:device0> cat in_accel_z_raw + 104873530 + root:/sys/bus/iio/devices/iio:device0> cat in_accel_scale + 0.000000095 + +- X-axis acceleration = in_accel_x_raw * in_accel_scale = 0.655865845 m/s^2 +- Y-axis acceleration = in_accel_y_raw * in_accel_scale = 0.53680225 m/s^2 +- Z-axis acceleration = in_accel_z_raw * in_accel_scale = 9.96298535 m/s^2 + +Show gyroscope channels value: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_x_raw + 193309 + root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_y_raw + -763676 + root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_z_raw + -358108 + root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_scale + 0.000000003 + +- X-axis angular velocity = in_anglvel_x_raw * in_anglvel_scale = 0.000579927 rad/s +- Y-axis angular velocity = in_anglvel_y_raw * in_anglvel_scale = −0.002291028 rad/s +- Z-axis angular velocity = in_anglvel_z_raw * in_anglvel_scale = −0.001074324 rad/s + +Set calibration offset for accelerometer channels: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias + 0 + + root:/sys/bus/iio/devices/iio:device0> echo 5000 > in_accel_x_calibbias + root:/sys/bus/iio/devices/iio:device0> cat in_accel_x_calibbias + 5000 + +Set calibration offset for gyroscope channels: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_y_calibbias + 0 + + root:/sys/bus/iio/devices/iio:device0> echo -5000 > in_anglvel_y_calibbias + root:/sys/bus/iio/devices/iio:device0> cat in_anglvel_y_calibbias + -5000 + +Set sampling frequency: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> cat sampling_frequency + 4000.000000 + + root:/sys/bus/iio/devices/iio:device0> echo 1000 > sampling_frequency + 1000.000000 + +Set bandwidth for accelerometer channels: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> cat in_accel_filter_low_pass_3db_frequency + 0 + + root:/sys/bus/iio/devices/iio:device0> echo 100 > in_accel_filter_low_pass_3db_frequency + root:/sys/bus/iio/devices/iio:device0> cat in_accel_filter_low_pass_3db_frequency + 100 + +Show serial number: + +.. code-block:: bash + + root:/sys/kernel/debug/iio/iio:device0> cat serial_number + 0x000000b6 + +Show product id: + +.. code-block:: bash + + root:/sys/kernel/debug/iio/iio:device0> cat product_id + 16550 + +Show flash count: + +.. code-block:: bash + + root:/sys/kernel/debug/iio/iio:device0> cat flash_count + 13 + +Show firmware revision: + +.. code-block:: bash + + root:/sys/kernel/debug/iio/iio:device0> cat firmware_revision + 1.5 + +Show firmware date: + +.. code-block:: bash + + root:/sys/kernel/debug/iio/iio:device0> cat firmware_date + 28-04-2021 + +3. Device buffers +================= + +This driver supports IIO buffers. + +The device supports retrieving the raw acceleration, gyroscope, delta velocity, +delta angle and temperature measurements using buffers. + +However, when retrieving acceleration or gyroscope data using buffers, delta +readings will not be available and vice versa. This is because the device only +allows to read either acceleration and gyroscope data or delta velocity and +delta angle data at a time and switching between these two burst data selection +modes is time consuming. + +Usage examples +-------------- + +Set device trigger in current_trigger, if not already set: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> cat trigger/current_trigger + + root:/sys/bus/iio/devices/iio:device0> echo adis16550-dev0 > trigger/current_trigger + root:/sys/bus/iio/devices/iio:device0> cat trigger/current_trigger + adis16550-dev0 + +Select channels for buffer read: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_x_en + root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_y_en + root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_deltavelocity_z_en + root:/sys/bus/iio/devices/iio:device0> echo 1 > scan_elements/in_temp0_en + +Set the number of samples to be stored in the buffer: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> echo 10 > buffer/length + +Enable buffer readings: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> echo 1 > buffer/enable + +Obtain buffered data: + +.. code-block:: bash + + root:/sys/bus/iio/devices/iio:device0> hexdump -C /dev/iio\:device0 + ... + 0000cdf0 00 00 0d 2f 00 00 08 43 00 00 09 09 00 00 a4 5f |.../...C......._| + 0000ce00 00 00 0d 2f 00 00 07 de 00 00 08 db 00 00 a4 4b |.../...........K| + 0000ce10 00 00 0d 2f 00 00 07 58 00 00 08 a3 00 00 a4 55 |.../...X.......U| + 0000ce20 00 00 0d 2f 00 00 06 d6 00 00 08 5c 00 00 a4 62 |.../.......\...b| + 0000ce30 00 00 0d 2f 00 00 06 45 00 00 08 37 00 00 a4 47 |.../...E...7...G| + 0000ce40 00 00 0d 2f 00 00 05 d4 00 00 08 30 00 00 a3 fa |.../.......0....| + 0000ce50 00 00 0d 2f 00 00 05 d0 00 00 08 12 00 00 a3 d3 |.../............| + 0000ce60 00 00 0d 2f 00 00 05 dd 00 00 08 2e 00 00 a3 e9 |.../............| + 0000ce70 00 00 0d 2f 00 00 05 cc 00 00 08 51 00 00 a3 d5 |.../.......Q....| + 0000ce80 00 00 0d 2f 00 00 05 ba 00 00 08 22 00 00 a3 9a |.../......."....| + 0000ce90 00 00 0d 2f 00 00 05 9c 00 00 07 d9 00 00 a3 40 |.../...........@| + 0000cea0 00 00 0d 2f 00 00 05 68 00 00 07 94 00 00 a2 e4 |.../...h........| + 0000ceb0 00 00 0d 2f 00 00 05 25 00 00 07 8d 00 00 a2 ce |.../...%........| + ... + +See ``Documentation/iio/iio_devbuf.rst`` for more information about how buffered +data is structured. + +4. IIO Interfacing Tools +======================== + +See ``Documentation/iio/iio_tools.rst`` for the description of the available IIO +interfacing tools. diff --git a/Documentation/iio/adxl380.rst b/Documentation/iio/adxl380.rst index 376dee5fe1dd..66c8a4d4f767 100644 --- a/Documentation/iio/adxl380.rst +++ b/Documentation/iio/adxl380.rst @@ -94,7 +94,7 @@ apply the following formula: Where _offset and _scale are device attributes. If no _offset attribute is present, simply assume its value is 0. -The adis16475 driver offers data for 2 types of channels, the table below shows +The ADXL380 driver offers data for 2 types of channels, the table below shows the measurement units for the processed value, which are defined by the IIO framework: diff --git a/Documentation/iio/iio_adc.rst b/Documentation/iio/iio_adc.rst new file mode 100644 index 000000000000..f2f19a691907 --- /dev/null +++ b/Documentation/iio/iio_adc.rst @@ -0,0 +1,305 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +========================= +IIO Abstractions for ADCs +========================= + +1. Overview +=========== + +The IIO subsystem supports many Analog to Digital Converters (ADCs). Some ADCs +have features and characteristics that are supported in specific ways by IIO +device drivers. This documentation describes common ADC features and explains +how they are supported by the IIO subsystem. + +1. ADC Channel Types +==================== + +ADCs can have distinct types of inputs, each of them measuring analog voltages +in a slightly different way. An ADC digitizes the analog input voltage over a +span that is often given by the provided voltage reference, the input type, and +the input polarity. The input range allowed to an ADC channel is needed to +determine the scale factor and offset needed to obtain the measured value in +real-world units (millivolts for voltage measurement, milliamps for current +measurement, etc.). + +Elaborate designs may have nonlinear characteristics or integrated components +(such as amplifiers and reference buffers) that might also have to be considered +to derive the allowed input range for an ADC. For clarity, the sections below +assume the input range only depends on the provided voltage references, input +type, and input polarity. + +There are three general types of ADC inputs (single-ended, differential, +pseudo-differential) and two possible polarities (unipolar, bipolar). The input +type (single-ended, differential, pseudo-differential) is one channel +characteristic, and is completely independent of the polarity (unipolar, +bipolar) aspect. A comprehensive article about ADC input types (on which this +doc is heavily based on) can be found at +https://www.analog.com/en/resources/technical-articles/sar-adc-input-types.html. + +1.1 Single-ended channels +------------------------- + +Single-ended channels digitize the analog input voltage relative to ground and +can be either unipolar or bipolar. + +1.1.1 Single-ended Unipolar Channels +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +:: + + ---------- VREF ------------- + ´ ` ´ ` _____________ + / \ / \ / | + / \ / \ --- < IN ADC | + \ / \ / \ | + `-´ `-´ \ VREF | + -------- GND (0V) ----------- +-----------+ + ^ + | + External VREF + +The input voltage to a **single-ended unipolar** channel is allowed to swing +from GND to VREF (where VREF is a voltage reference with electrical potential +higher than system ground). The maximum input voltage is also called VFS +(Voltage input Full-Scale), with VFS being determined by VREF. The voltage +reference may be provided from an external supply or derived from the chip power +source. + +A single-ended unipolar channel could be described in device tree like the +following example:: + + adc@0 { + ... + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0>; + }; + }; + +One is always allowed to include ADC channel nodes in the device tree. Though, +if the device has a uniform set of inputs (e.g. all inputs are single-ended), +then declaring the channel nodes is optional. + +One caveat for devices that support mixed single-ended and differential channels +is that single-ended channel nodes also need to provide a ``single-channel`` +property when ``reg`` is an arbitrary number that doesn't match the input pin +number. + +See ``Documentation/devicetree/bindings/iio/adc/adc.yaml`` for the complete +documentation of ADC specific device tree properties. + + +1.1.2 Single-ended Bipolar Channels +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +:: + + ---------- +VREF ------------ + ´ ` ´ ` _____________________ + / \ / \ / | + / \ / \ --- < IN ADC | + \ / \ / \ | + `-´ `-´ \ +VREF -VREF | + ---------- -VREF ------------ +-------------------+ + ^ ^ + | | + External +VREF ------+ External -VREF + +For a **single-ended bipolar** channel, the analog voltage input can go from +-VREF to +VREF (where -VREF is the voltage reference that has the lower +electrical potential while +VREF is the reference with the higher one). Some ADC +chips derive the lower reference from +VREF, others get it from a separate +input. Often, +VREF and -VREF are symmetric but they don't need to be so. When +-VREF is lower than system ground, these inputs are also called single-ended +true bipolar. Also, while there is a relevant difference between bipolar and +true bipolar from the electrical perspective, IIO makes no explicit distinction +between them. + +Here's an example device tree description of a single-ended bipolar channel:: + + adc@0 { + ... + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0>; + bipolar; + }; + }; + +1.2 Differential channels +------------------------- + +A differential voltage measurement digitizes the voltage level at the positive +input (IN+) relative to the negative input (IN-) over the -VREF to +VREF span. +In other words, a differential channel measures the potential difference between +IN+ and IN-, which is often denoted by the IN+ - IN- formula. + +1.2.1 Differential Bipolar Channels +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +:: + + -------- +VREF ------ +-------------------+ + ´ ` ´ ` / | + / \ / \ / --- < IN+ | + `-´ `-´ | | + -------- -VREF ------ | | + | ADC | + -------- +VREF ------ | | + ´ ` ´ ` | | + \ / \ / \ --- < IN- | + `-´ `-´ \ +VREF -VREF | + -------- -VREF ------ +-------------------+ + ^ ^ + | +---- External -VREF + External +VREF + +The analog signals to **differential bipolar** inputs are also allowed to swing +from -VREF to +VREF. The bipolar part of the name means that the resulting value +of the difference (IN+ - IN-) can be positive or negative. If -VREF is below +system GND, these are also called differential true bipolar inputs. + +Device tree example of a differential bipolar channel:: + + adc@0 { + ... + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0>; + bipolar; + diff-channels = <0 1>; + }; + }; + +In the ADC driver, ``differential = 1`` is set into ``struct iio_chan_spec`` for +the channel. Even though, there are three general input types, ``differential`` +is only used to distinguish between differential and non-differential (either +single-ended or pseudo-differential) input types. See +``include/linux/iio/iio.h`` for more information. + +1.2.2 Differential Unipolar Channels +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For **differential unipolar** channels, the analog voltage at the positive input +must also be higher than the voltage at the negative input. Thus, the actual +input range allowed to a differential unipolar channel is IN- to +VREF. Because +IN+ is allowed to swing with the measured analog signal and the input setup must +guarantee IN+ will not go below IN- (nor IN- will raise above IN+), most +differential unipolar channel setups have IN- fixed to a known voltage that does +not fall within the voltage range expected for the measured signal. That leads +to a setup that is equivalent to a pseudo-differential channel. Thus, +differential unipolar setups can often be supported as pseudo-differential +unipolar channels. + +1.3 Pseudo-differential Channels +-------------------------------- + +There is a third ADC input type which is called pseudo-differential or +single-ended to differential configuration. A pseudo-differential channel is +similar to a differential channel in that it also measures IN+ relative to IN-. +However, unlike bipolar differential channels, the negative input is limited to +a narrow voltage range (taken as a constant voltage) while only IN+ is allowed +to swing. A pseudo-differential channel can be made out from a differential pair +of inputs by restricting the negative input to a known voltage while allowing +only the positive input to swing. Sometimes, the input provided to IN- is called +common-mode voltage. Besides, some parts have a COM pin that allows single-ended +inputs to be referenced to a common-mode voltage, making them +pseudo-differential channels. Often, the common mode input voltage can be +described in the device tree as a voltage regulator (e.g. ``com-supply``) since +it is basically a constant voltage source. + +1.3.1 Pseudo-differential Unipolar Channels +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +:: + + -------- +VREF ------ +-------------------+ + ´ ` ´ ` / | + / \ / \ / --- < IN+ | + `-´ `-´ | | + --------- IN- ------- | ADC | + | | + Common-mode voltage --> --- < IN- | + \ +VREF -VREF | + +-------------------+ + ^ ^ + | +---- External -VREF + External +VREF + +A **pseudo-differential unipolar** input has the limitations a differential +unipolar channel would have, meaning the analog voltage to the positive input +IN+ must stay within IN- to +VREF. The fixed voltage to IN- is often called +common-mode voltage and it must be within -VREF to +VREF as would be expected +from the signal to any differential channel negative input. + +The voltage measured from IN+ is relative to IN- but, unlike differential +channels, pseudo-differential setups are intended to gauge single-ended input +signals. To enable applications to calculate IN+ voltage with respect to system +ground, the IIO channel may provide an ``_offset`` sysfs attribute to be added +to ADC output when converting raw data to voltage units. In many setups, the +common-mode voltage input is at GND level and the ``_offset`` attribute is +omitted due to being always zero. + +Device tree example for pseudo-differential unipolar channel:: + + adc@0 { + ... + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0>; + single-channel = <0>; + common-mode-channel = <1>; + }; + }; + +Do not set ``differential`` in the channel ``iio_chan_spec`` struct of +pseudo-differential channels. + +1.3.2 Pseudo-differential Bipolar Channels +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +:: + + -------- +VREF ------ +-------------------+ + ´ ` ´ ` / | + / \ / \ / --- < IN+ | + `-´ `-´ | | + -------- -VREF ------ | ADC | + | | + Common-mode voltage --> --- < IN- | + \ +VREF -VREF | + +-------------------+ + ^ ^ + | +---- External -VREF + External +VREF + +A **pseudo-differential bipolar** input is not limited by the level at IN- but +it will be limited to -VREF or to GND on the lower end of the input range +depending on the particular ADC. Similar to their unipolar counter parts, +pseudo-differential bipolar channels ought to declare an ``_offset`` attribute +to enable the conversion of raw ADC data to voltage units. For the setup with +IN- connected to GND, ``_offset`` is often omitted. + +Device tree example for pseudo-differential bipolar channel:: + + adc@0 { + ... + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0>; + bipolar; + single-channel = <0>; + common-mode-channel = <1>; + }; + }; diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst index 5710f5b9e958..bbb2edce8272 100644 --- a/Documentation/iio/index.rst +++ b/Documentation/iio/index.rst @@ -7,6 +7,7 @@ Industrial I/O .. toctree:: :maxdepth: 1 + iio_adc iio_configfs iio_devbuf iio_dmabuf_api @@ -19,13 +20,16 @@ Industrial I/O Kernel Drivers :maxdepth: 1 ad4000 + ad4030 ad4695 + ad7191 ad7380 ad7606 ad7625 ad7944 adis16475 adis16480 + adis16550 adxl380 bno055 ep93xx_adc diff --git a/Documentation/infiniband/index.rst b/Documentation/infiniband/index.rst index 9cd7615438b9..5b4c24125f66 100644 --- a/Documentation/infiniband/index.rst +++ b/Documentation/infiniband/index.rst @@ -12,6 +12,7 @@ InfiniBand opa_vnic sysfs tag_matching + ucaps user_mad user_verbs diff --git a/Documentation/infiniband/ucaps.rst b/Documentation/infiniband/ucaps.rst new file mode 100644 index 000000000000..b8b6927742f4 --- /dev/null +++ b/Documentation/infiniband/ucaps.rst @@ -0,0 +1,71 @@ +================================= +Infiniband Userspace Capabilities +================================= + + User CAPabilities (UCAPs) provide fine-grained control over specific + firmware features in Infiniband (IB) devices. This approach offers + more granular capabilities than the existing Linux capabilities, + which may be too generic for certain FW features. + + Each user capability is represented as a character device with root + read-write access. Root processes can grant users special privileges + by allowing access to these character devices (e.g., using chown). + +Usage +===== + + UCAPs allow control over specific features of an IB device using file + descriptors of UCAP character devices. Here is how a user enables + specific features of an IB device: + + * A root process grants the user access to the UCAP files that + represents the capabilities (e.g., using chown). + * The user opens the UCAP files, obtaining file descriptors. + * When opening an IB device, include an array of the UCAP file + descriptors as an attribute. + * The ib_uverbs driver recognizes the UCAP file descriptors and enables + the corresponding capabilities for the IB device. + +Creating UCAPs +============== + + To create a new UCAP, drivers must first define a type in the + rdma_user_cap enum in rdma/ib_ucaps.h. The name of the UCAP character + device should be added to the ucap_names array in + drivers/infiniband/core/ucaps.c. Then, the driver can create the UCAP + character device by calling the ib_create_ucap API with the UCAP + type. + + A reference count is stored for each UCAP to track creations and + removals of the UCAP device. If multiple creation calls are made with + the same type (e.g., for two IB devices), the UCAP character device + is created during the first call and subsequent calls increment the + reference count. + + The UCAP character device is created under /dev/infiniband, and its + permissions are set to allow root read and write access only. + +Removing UCAPs +============== + + Each removal decrements the reference count of the UCAP. The UCAP + character device is removed from the filesystem only when the + reference count is decreased to 0. + +/dev and /sys/class files +========================= + + The class:: + + /sys/class/infiniband_ucaps + + is created when the first UCAP character device is created. + + The UCAP character device is created under /dev/infiniband. + + For example, if mlx5_ib adds the rdma_user_cap + RDMA_UCAP_MLX5_CTRL_LOCAL with name "mlx5_perm_ctrl_local", this will + create the device node:: + + /dev/infiniband/mlx5_perm_ctrl_local + diff --git a/Documentation/kbuild/bash-completion.rst b/Documentation/kbuild/bash-completion.rst new file mode 100644 index 000000000000..2b52dbcd0933 --- /dev/null +++ b/Documentation/kbuild/bash-completion.rst @@ -0,0 +1,65 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +========================== +Bash completion for Kbuild +========================== + +The kernel build system is written using Makefiles, and Bash completion +for the `make` command is available through the `bash-completion`_ project. + +However, the Makefiles for the kernel build are complex. The generic completion +rules for the `make` command do not provide meaningful suggestions for the +kernel build system, except for the options of the `make` command itself. + +To enhance completion for various variables and targets, the kernel source +includes its own completion script at `scripts/bash-completion/make`. + +This script provides additional completions when working within the kernel tree. +Outside the kernel tree, it defaults to the generic completion rules for the +`make` command. + +Prerequisites +============= + +The script relies on helper functions provided by `bash-completion`_ project. +Please ensure it is installed on your system. On most distributions, you can +install the `bash-completion` package through the standard package manager. + +How to use +========== + +You can source the script directly:: + + $ source scripts/bash-completion/make + +Or, you can copy it into the search path for Bash completion scripts. +For example:: + + $ mkdir -p ~/.local/share/bash-completion/completions + $ cp scripts/bash-completion/make ~/.local/share/bash-completion/completions/ + +Details +======= + +The additional completion for Kbuild is enabled in the following cases: + + - You are in the root directory of the kernel source. + - You are in the top-level build directory created by the O= option + (checked via the `source` symlink pointing to the kernel source). + - The -C make option specifies the kernel source or build directory. + - The -f make option specifies a file in the kernel source or build directory. + +If none of the above are met, it falls back to the generic completion rules. + +The completion supports: + + - Commonly used targets, such as `all`, `menuconfig`, `dtbs`, etc. + - Make (or environment) variables, such as `ARCH`, `LLVM`, etc. + - Single-target builds (`foo/bar/baz.o`) + - Configuration files (`*_defconfig` and `*.config`) + +Some variables offer intelligent behavior. For instance, `CROSS_COMPILE=` +followed by a TAB displays installed toolchains. The list of defconfig files +shown depends on the value of the `ARCH=` variable. + +.. _bash-completion: https://github.com/scop/bash-completion/ diff --git a/Documentation/kbuild/index.rst b/Documentation/kbuild/index.rst index e82af05cd652..3731ab22bfe7 100644 --- a/Documentation/kbuild/index.rst +++ b/Documentation/kbuild/index.rst @@ -23,6 +23,8 @@ Kernel Build System llvm gendwarfksyms + bash-completion + .. only:: subproject and html Indices diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index 2619fdf56e68..a91abb8f6840 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -194,16 +194,6 @@ applicable everywhere (see syntax). ability to hook into a secondary subsystem while allowing the user to configure that subsystem out without also having to unset these drivers. - Note: If the combination of FOO=y and BAZ=m causes a link error, - you can guard the function call with IS_REACHABLE():: - - foo_init() - { - if (IS_REACHABLE(CONFIG_BAZ)) - baz_register(&foo); - ... - } - Note: If the feature provided by BAZ is highly desirable for FOO, FOO should imply not only BAZ, but also its dependency BAR:: @@ -588,7 +578,9 @@ uses the slightly counterintuitive:: depends on BAR || !BAR This means that there is either a dependency on BAR that disallows -the combination of FOO=y with BAR=m, or BAR is completely disabled. +the combination of FOO=y with BAR=m, or BAR is completely disabled. The BAR +module must provide all the stubs for !BAR case. + For a more formalized approach if there are multiple drivers that have the same dependency, a helper symbol can be used, like:: @@ -599,6 +591,21 @@ the same dependency, a helper symbol can be used, like:: config BAR_OPTIONAL def_tristate BAR || !BAR +Much less favorable way to express optional dependency is IS_REACHABLE() within +the module code, useful for example when the module BAR does not provide +!BAR stubs:: + + foo_init() + { + if (IS_REACHABLE(CONFIG_BAR)) + bar_register(&foo); + ... + } + +IS_REACHABLE() is generally discouraged, because the code will be silently +discarded, when CONFIG_BAR=m and this code is built-in. This is not what users +usually expect when enabling BAR as module. + Kconfig recursive dependency limitations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index d36519f194dc..3b9a8bc671e2 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -318,9 +318,6 @@ ccflags-y, asflags-y and ldflags-y These three flags apply only to the kbuild makefile in which they are assigned. They are used for all the normal cc, as and ld invocations happening during a recursive build. - Note: Flags with the same behaviour were previously named: - EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. - They are still supported but their usage is deprecated. ccflags-y specifies options for compiling with $(CC). @@ -670,6 +667,20 @@ cc-cross-prefix endif endif +$(RUSTC) support functions +-------------------------- + +rustc-min-version + rustc-min-version tests if the value of $(CONFIG_RUSTC_VERSION) is greater + than or equal to the provided value and evaluates to y if so. + + Example:: + + rustflags-$(call rustc-min-version, 108500) := -Cfoo + + In this example, rustflags-y will be assigned the value -Cfoo if + $(CONFIG_RUSTC_VERSION) is >= 1.85.0. + $(LD) support functions ----------------------- diff --git a/Documentation/kbuild/modules.rst b/Documentation/kbuild/modules.rst index a42f00d8cb90..d0703605bfa4 100644 --- a/Documentation/kbuild/modules.rst +++ b/Documentation/kbuild/modules.rst @@ -318,7 +318,7 @@ Several Subdirectories | |__ include | |__ hardwareif.h |__ include - |__ complex.h + |__ complex.h To build the module complex.ko, we then need the following kbuild file:: diff --git a/Documentation/kbuild/reproducible-builds.rst b/Documentation/kbuild/reproducible-builds.rst index f2dcc39044e6..a7762486c93f 100644 --- a/Documentation/kbuild/reproducible-builds.rst +++ b/Documentation/kbuild/reproducible-builds.rst @@ -46,21 +46,6 @@ The kernel embeds the building user and host names in `KBUILD_BUILD_USER and KBUILD_BUILD_HOST`_ variables. If you are building from a git commit, you could use its committer address. -Absolute filenames ------------------- - -When the kernel is built out-of-tree, debug information may include -absolute filenames for the source files. This must be overridden by -including the ``-fdebug-prefix-map`` option in the `KCFLAGS`_ variable. - -Depending on the compiler used, the ``__FILE__`` macro may also expand -to an absolute filename in an out-of-tree build. Kbuild automatically -uses the ``-fmacro-prefix-map`` option to prevent this, if it is -supported. - -The Reproducible Builds web site has more information about these -`prefix-map options`_. - Generated files in source packages ---------------------------------- @@ -131,7 +116,5 @@ See ``scripts/setlocalversion`` for details. .. _KBUILD_BUILD_TIMESTAMP: kbuild.html#kbuild-build-timestamp .. _KBUILD_BUILD_USER and KBUILD_BUILD_HOST: kbuild.html#kbuild-build-user-kbuild-build-host -.. _KCFLAGS: kbuild.html#kcflags -.. _prefix-map options: https://reproducible-builds.org/docs/build-path/ .. _Reproducible Builds project: https://reproducible-builds.org/ .. _SOURCE_DATE_EPOCH: https://reproducible-builds.org/docs/source-date-epoch/ diff --git a/Documentation/locking/hwspinlock.rst b/Documentation/locking/hwspinlock.rst index 2ffaa3cbd63f..a737c702a7d1 100644 --- a/Documentation/locking/hwspinlock.rst +++ b/Documentation/locking/hwspinlock.rst @@ -40,17 +40,6 @@ User API :: - struct hwspinlock *hwspin_lock_request(void); - -Dynamically assign an hwspinlock and return its address, or NULL -in case an unused hwspinlock isn't available. Users of this -API will usually want to communicate the lock's id to the remote core -before it can be used to achieve synchronization. - -Should be called from a process context (might sleep). - -:: - struct hwspinlock *hwspin_lock_request_specific(unsigned int id); Assign a specific hwspinlock id and return its address, or NULL @@ -312,17 +301,6 @@ The caller should **never** unlock an hwspinlock which is already unlocked. Doing so is considered a bug (there is no protection against this). This function will never sleep. -:: - - int hwspin_lock_get_id(struct hwspinlock *hwlock); - -Retrieve id number of a given hwspinlock. This is needed when an -hwspinlock is dynamically assigned: before it can be used to achieve -mutual exclusion with a remote cpu, the id number should be communicated -to the remote task with which we want to synchronize. - -Returns the hwspinlock id number, or -EINVAL if hwlock is null. - Typical usage ============= @@ -331,40 +309,7 @@ Typical usage #include <linux/hwspinlock.h> #include <linux/err.h> - int hwspinlock_example1(void) - { - struct hwspinlock *hwlock; - int ret; - - /* dynamically assign a hwspinlock */ - hwlock = hwspin_lock_request(); - if (!hwlock) - ... - - id = hwspin_lock_get_id(hwlock); - /* probably need to communicate id to a remote processor now */ - - /* take the lock, spin for 1 sec if it's already taken */ - ret = hwspin_lock_timeout(hwlock, 1000); - if (ret) - ... - - /* - * we took the lock, do our thing now, but do NOT sleep - */ - - /* release the lock */ - hwspin_unlock(hwlock); - - /* free the lock */ - ret = hwspin_lock_free(hwlock); - if (ret) - ... - - return ret; - } - - int hwspinlock_example2(void) + int hwspinlock_example(void) { struct hwspinlock *hwlock; int ret; diff --git a/Documentation/mm/balance.rst b/Documentation/mm/balance.rst index abaa78561c31..c4962c89a7f5 100644 --- a/Documentation/mm/balance.rst +++ b/Documentation/mm/balance.rst @@ -81,7 +81,7 @@ Page stealing from process memory and shm is done if stealing the page would alleviate memory pressure on any zone in the page's node that has fallen below its watermark. -watemark[WMARK_MIN/WMARK_LOW/WMARK_HIGH]/low_on_memory/zone_wake_kswapd: These +watermark[WMARK_MIN/WMARK_LOW/WMARK_HIGH]/low_on_memory/zone_wake_kswapd: These are per-zone fields, used to determine when a zone needs to be balanced. When the number of pages falls below watermark[WMARK_MIN], the hysteric field low_on_memory gets set. This stays set till the number of free pages becomes diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst index e28c6a1b40ae..f12d33749329 100644 --- a/Documentation/mm/damon/design.rst +++ b/Documentation/mm/damon/design.rst @@ -313,6 +313,10 @@ sufficient for the given purpose, it shouldn't be unnecessarily further lowered. It is recommended to be set proportional to ``aggregation interval``. By default, the ratio is set as ``1/20``, and it is still recommended. +Based on the manual tuning guide, DAMON provides more intuitive knob-based +intervals auto tuning mechanism. Please refer to :ref:`the design document of +the feature <damon_design_monitoring_intervals_autotuning>` for detail. + Refer to below documents for an example tuning based on the above guide. .. toctree:: @@ -321,6 +325,52 @@ Refer to below documents for an example tuning based on the above guide. monitoring_intervals_tuning_example +.. _damon_design_monitoring_intervals_autotuning: + +Monitoring Intervals Auto-tuning +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +DAMON provides automatic tuning of the ``sampling interval`` and ``aggregation +interval`` based on the :ref:`the tuning guide idea +<damon_design_monitoring_params_tuning_guide>`. The tuning mechanism allows +users to set the aimed amount of access events to observe via DAMON within +given time interval. The target can be specified by the user as a ratio of +DAMON-observed access events to the theoretical maximum amount of the events +(``access_bp``) that measured within a given number of aggregations +(``aggrs``). + +The DAMON-observed access events are calculated in byte granularity based on +DAMON :ref:`region assumption <damon_design_region_based_sampling>`. For +example, if a region of size ``X`` bytes of ``Y`` ``nr_accesses`` is found, it +means ``X * Y`` access events are observed by DAMON. Theoretical maximum +access events for the region is calculated in same way, but replacing ``Y`` +with theoretical maximum ``nr_accesses``, which can be calculated as +``aggregation interval / sampling interval``. + +The mechanism calculates the ratio of access events for ``aggrs`` aggregations, +and increases or decrease the ``sampleing interval`` and ``aggregation +interval`` in same ratio, if the observed access ratio is lower or higher than +the target, respectively. The ratio of the intervals change is decided in +proportion to the distance between current samples ratio and the target ratio. + +The user can further set the minimum and maximum ``sampling interval`` that can +be set by the tuning mechanism using two parameters (``min_sample_us`` and +``max_sample_us``). Because the tuning mechanism changes ``sampling interval`` +and ``aggregation interval`` in same ratio always, the minimum and maximum +``aggregation interval`` after each of the tuning changes can automatically set +together. + +The tuning is turned off by default, and need to be set explicitly by the user. +As a rule of thumbs and the Parreto principle, 4% access samples ratio target +is recommended. Note that Parreto principle (80/20 rule) has applied twice. +That is, assumes 4% (20% of 20%) DAMON-observed access events ratio (source) +to capture 64% (80% multipled by 80%) real access events (outcomes). + +To know how user-space can use this feature via :ref:`DAMON sysfs interface +<sysfs_interface>`, refer to :ref:`intervals_goal <sysfs_scheme>` part of +the documentation. + + .. _damon_design_damos: Operation Schemes @@ -569,11 +619,22 @@ number of filters for each scheme. Each filter specifies - whether it is to allow (include) or reject (exclude) applying the scheme's action to the memory (``allow``). -When multiple filters are installed, each filter is evaluated in the installed -order. If a part of memory is matched to one of the filter, next filters are -ignored. If the memory passes through the filters evaluation stage because it -is not matched to any of the filters, applying the scheme's action to it is -allowed, same to the behavior when no filter exists. +For efficient handling of filters, some types of filters are handled by the +core layer, while others are handled by operations set. In the latter case, +hence, support of the filter types depends on the DAMON operations set. In +case of the core layer-handled filters, the memory regions that excluded by the +filter are not counted as the scheme has tried to the region. In contrast, if +a memory regions is filtered by an operations set layer-handled filter, it is +counted as the scheme has tried. This difference affects the statistics. + +When multiple filters are installed, the group of filters that handled by the +core layer are evaluated first. After that, the group of filters that handled +by the operations layer are evaluated. Filters in each of the groups are +evaluated in the installed order. If a part of memory is matched to one of the +filter, next filters are ignored. If the part passes through the filters +evaluation stage because it is not matched to any of the filters, applying the +scheme's action to it depends on the last filter's allowance type. If the last +filter was for allowing, the part of memory will be rejected, and vice versa. For example, let's assume 1) a filter for allowing anonymous pages and 2) another filter for rejecting young pages are installed in the order. If a page @@ -585,39 +646,29 @@ second reject-filter blocks it. If the page is neither anonymous nor young, the page will pass through the filters evaluation stage since there is no matching filter, and the action will be applied to the page. -Note that the action can equally be applied to memory that either explicitly -filter-allowed or filters evaluation stage passed. It means that installing -allow-filters at the end of the list makes no practical change but only -filters-checking overhead. - -For efficient handling of filters, some types of filters are handled by the -core layer, while others are handled by operations set. In the latter case, -hence, support of the filter types depends on the DAMON operations set. In -case of the core layer-handled filters, the memory regions that excluded by the -filter are not counted as the scheme has tried to the region. In contrast, if -a memory regions is filtered by an operations set layer-handled filter, it is -counted as the scheme has tried. This difference affects the statistics. - Below ``type`` of filters are currently supported. -- anonymous page - - Applied to pages that containing data that not stored in files. - - Handled by operations set layer. Supported by only ``paddr`` set. -- memory cgroup - - Applied to pages that belonging to a given cgroup. - - Handled by operations set layer. Supported by only ``paddr`` set. -- young page - - Applied to pages that are accessed after the last access check from the - scheme. - - Handled by operations set layer. Supported by only ``paddr`` set. -- address range - - Applied to pages that belonging to a given address range. - - Handled by the core logic. -- DAMON monitoring target - - Applied to pages that belonging to a given DAMON monitoring target. - - Handled by the core logic. - -To know how user-space can set the watermarks via :ref:`DAMON sysfs interface +- Core layer handled + - addr + - Applied to pages that belonging to a given address range. + - target + - Applied to pages that belonging to a given DAMON monitoring target. +- Operations layer handled, supported by only ``paddr`` operations set. + - anon + - Applied to pages that containing data that not stored in files. + - active + - Applied to active pages. + - memcg + - Applied to pages that belonging to a given cgroup. + - young + - Applied to pages that are accessed after the last access check from the + scheme. + - hugepage_size + - Applied to pages that managed in a given size range. + - unmapped + - Applied to pages that unmapped. + +To know how user-space can set the filters via :ref:`DAMON sysfs interface <sysfs_interface>`, refer to :ref:`filters <sysfs_filters>` part of the documentation. diff --git a/Documentation/mm/damon/monitoring_intervals_tuning_example.rst b/Documentation/mm/damon/monitoring_intervals_tuning_example.rst index 334a854efb40..7207cbed591f 100644 --- a/Documentation/mm/damon/monitoring_intervals_tuning_example.rst +++ b/Documentation/mm/damon/monitoring_intervals_tuning_example.rst @@ -36,7 +36,7 @@ Then, list the DAMON-found regions of different access patterns, sorted by the "access temperature". "Access temperature" is a metric representing the access-hotness of a region. It is calculated as a weighted sum of the access frequency and the age of the region. If the access frequency is 0 %, the -temperature is multipled by minus one. That is, if a region is not accessed, +temperature is multiplied by minus one. That is, if a region is not accessed, it gets minus temperature and it gets lower as not accessed for longer time. The sorting is in temperature-ascendint order, so the region at the top of the list is the coldest, and the one at the bottom is the hottest one. :: @@ -58,11 +58,11 @@ list is the coldest, and the one at the bottom is the hottest one. :: The list shows not seemingly hot regions, and only minimum access pattern diversity. Every region has zero access frequency. The number of region is 10, which is the default ``min_nr_regions value``. Size of each region is also -nearly idential. We can suspect this is because “adaptive regions adjustment” +nearly identical. We can suspect this is because “adaptive regions adjustment” mechanism was not well working. As the guide suggested, we can get relative hotness of regions using ``age`` as the recency information. That would be better than nothing, but given the fact that the longest age is only about 6 -seconds while we waited about ten minuts, it is unclear how useful this will +seconds while we waited about ten minutes, it is unclear how useful this will be. The temperature ranges to total size of regions of each range histogram @@ -190,7 +190,7 @@ for sampling and aggregation intervals, respectively). :: The number of regions having different access patterns has significantly increased. Size of each region is also more varied. Total size of non-zero access frequency regions is also significantly increased. Maybe this is already -good enough to make some meaningful memory management efficieny changes. +good enough to make some meaningful memory management efficiency changes. 800ms/16s intervals: Another bias ================================= diff --git a/Documentation/mm/hmm.rst b/Documentation/mm/hmm.rst index f6d53c37a2ca..7d61b7a8b65b 100644 --- a/Documentation/mm/hmm.rst +++ b/Documentation/mm/hmm.rst @@ -400,7 +400,7 @@ Exclusive access memory Some devices have features such as atomic PTE bits that can be used to implement atomic access to system memory. To support atomic operations to a shared virtual memory page such a device needs access to that page which is exclusive of any -userspace access from the CPU. The ``make_device_exclusive_range()`` function +userspace access from the CPU. The ``make_device_exclusive()`` function can be used to make a memory range inaccessible from userspace. This replaces all mappings for pages in the given range with special swap diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst index 0be1c7503a01..d3ada3e45e10 100644 --- a/Documentation/mm/index.rst +++ b/Documentation/mm/index.rst @@ -62,5 +62,4 @@ documentation, or deleted if it has served its purpose. unevictable-lru vmalloced-kernel-stacks vmemmap_dedup - z3fold zsmalloc diff --git a/Documentation/mm/physical_memory.rst b/Documentation/mm/physical_memory.rst index 71fd4a6acf42..d3ac106e6b14 100644 --- a/Documentation/mm/physical_memory.rst +++ b/Documentation/mm/physical_memory.rst @@ -338,10 +338,272 @@ Statistics Zones ===== +As we have mentioned, each zone in memory is described by a ``struct zone`` +which is an element of the ``node_zones`` array of the node it belongs to. +``struct zone`` is the core data structure of the page allocator. A zone +represents a range of physical memory and may have holes. + +The page allocator uses the GFP flags, see :ref:`mm-api-gfp-flags`, specified by +a memory allocation to determine the highest zone in a node from which the +memory allocation can allocate memory. The page allocator first allocates memory +from that zone, if the page allocator can't allocate the requested amount of +memory from the zone, it will allocate memory from the next lower zone in the +node, the process continues up to and including the lowest zone. For example, if +a node contains ``ZONE_DMA32``, ``ZONE_NORMAL`` and ``ZONE_MOVABLE`` and the +highest zone of a memory allocation is ``ZONE_MOVABLE``, the order of the zones +from which the page allocator allocates memory is ``ZONE_MOVABLE`` > +``ZONE_NORMAL`` > ``ZONE_DMA32``. + +At runtime, free pages in a zone are in the Per-CPU Pagesets (PCP) or free areas +of the zone. The Per-CPU Pagesets are a vital mechanism in the kernel's memory +management system. By handling most frequent allocations and frees locally on +each CPU, the Per-CPU Pagesets improve performance and scalability, especially +on systems with many cores. The page allocator in the kernel employs a two-step +strategy for memory allocation, starting with the Per-CPU Pagesets before +falling back to the buddy allocator. Pages are transferred between the Per-CPU +Pagesets and the global free areas (managed by the buddy allocator) in batches. +This minimizes the overhead of frequent interactions with the global buddy +allocator. + +Architecture specific code calls free_area_init() to initializes zones. + +Zone structure +-------------- +The zones structure ``struct zone`` is defined in ``include/linux/mmzone.h``. +Here we briefly describe fields of this structure: -.. admonition:: Stub +General +~~~~~~~ - This section is incomplete. Please list and describe the appropriate fields. +``_watermark`` + The watermarks for this zone. When the amount of free pages in a zone is below + the min watermark, boosting is ignored, an allocation may trigger direct + reclaim and direct compaction, it is also used to throttle direct reclaim. + When the amount of free pages in a zone is below the low watermark, kswapd is + woken up. When the amount of free pages in a zone is above the high watermark, + kswapd stops reclaiming (a zone is balanced) when the + ``NUMA_BALANCING_MEMORY_TIERING`` bit of ``sysctl_numa_balancing_mode`` is not + set. The promo watermark is used for memory tiering and NUMA balancing. When + the amount of free pages in a zone is above the promo watermark, kswapd stops + reclaiming when the ``NUMA_BALANCING_MEMORY_TIERING`` bit of + ``sysctl_numa_balancing_mode`` is set. The watermarks are set by + ``__setup_per_zone_wmarks()``. The min watermark is calculated according to + ``vm.min_free_kbytes`` sysctl. The other three watermarks are set according + to the distance between two watermarks. The distance itself is calculated + taking ``vm.watermark_scale_factor`` sysctl into account. + +``watermark_boost`` + The number of pages which are used to boost watermarks to increase reclaim + pressure to reduce the likelihood of future fallbacks and wake kswapd now + as the node may be balanced overall and kswapd will not wake naturally. + +``nr_reserved_highatomic`` + The number of pages which are reserved for high-order atomic allocations. + +``nr_free_highatomic`` + The number of free pages in reserved highatomic pageblocks + +``lowmem_reserve`` + The array of the amounts of the memory reserved in this zone for memory + allocations. For example, if the highest zone a memory allocation can + allocate memory from is ``ZONE_MOVABLE``, the amount of memory reserved in + this zone for this allocation is ``lowmem_reserve[ZONE_MOVABLE]`` when + attempting to allocate memory from this zone. This is a mechanism the page + allocator uses to prevent allocations which could use ``highmem`` from using + too much ``lowmem``. For some specialised workloads on ``highmem`` machines, + it is dangerous for the kernel to allow process memory to be allocated from + the ``lowmem`` zone. This is because that memory could then be pinned via the + ``mlock()`` system call, or by unavailability of swapspace. + ``vm.lowmem_reserve_ratio`` sysctl determines how aggressive the kernel is in + defending these lower zones. This array is recalculated by + ``setup_per_zone_lowmem_reserve()`` at runtime if ``vm.lowmem_reserve_ratio`` + sysctl changes. + +``node`` + The index of the node this zone belongs to. Available only when + ``CONFIG_NUMA`` is enabled because there is only one zone in a UMA system. + +``zone_pgdat`` + Pointer to the ``struct pglist_data`` of the node this zone belongs to. + +``per_cpu_pageset`` + Pointer to the Per-CPU Pagesets (PCP) allocated and initialized by + ``setup_zone_pageset()``. By handling most frequent allocations and frees + locally on each CPU, PCP improves performance and scalability on systems with + many cores. + +``pageset_high_min`` + Copied to the ``high_min`` of the Per-CPU Pagesets for faster access. + +``pageset_high_max`` + Copied to the ``high_max`` of the Per-CPU Pagesets for faster access. + +``pageset_batch`` + Copied to the ``batch`` of the Per-CPU Pagesets for faster access. The + ``batch``, ``high_min`` and ``high_max`` of the Per-CPU Pagesets are used to + calculate the number of elements the Per-CPU Pagesets obtain from the buddy + allocator under a single hold of the lock for efficiency. They are also used + to decide if the Per-CPU Pagesets return pages to the buddy allocator in page + free process. + +``pageblock_flags`` + The pointer to the flags for the pageblocks in the zone (see + ``include/linux/pageblock-flags.h`` for flags list). The memory is allocated + in ``setup_usemap()``. Each pageblock occupies ``NR_PAGEBLOCK_BITS`` bits. + Defined only when ``CONFIG_FLATMEM`` is enabled. The flags is stored in + ``mem_section`` when ``CONFIG_SPARSEMEM`` is enabled. + +``zone_start_pfn`` + The start pfn of the zone. It is initialized by + ``calculate_node_totalpages()``. + +``managed_pages`` + The present pages managed by the buddy system, which is calculated as: + ``managed_pages`` = ``present_pages`` - ``reserved_pages``, ``reserved_pages`` + includes pages allocated by the memblock allocator. It should be used by page + allocator and vm scanner to calculate all kinds of watermarks and thresholds. + It is accessed using ``atomic_long_xxx()`` functions. It is initialized in + ``free_area_init_core()`` and then is reinitialized when memblock allocator + frees pages into buddy system. + +``spanned_pages`` + The total pages spanned by the zone, including holes, which is calculated as: + ``spanned_pages`` = ``zone_end_pfn`` - ``zone_start_pfn``. It is initialized + by ``calculate_node_totalpages()``. + +``present_pages`` + The physical pages existing within the zone, which is calculated as: + ``present_pages`` = ``spanned_pages`` - ``absent_pages`` (pages in holes). It + may be used by memory hotplug or memory power management logic to figure out + unmanaged pages by checking (``present_pages`` - ``managed_pages``). Write + access to ``present_pages`` at runtime should be protected by + ``mem_hotplug_begin/done()``. Any reader who can't tolerant drift of + ``present_pages`` should use ``get_online_mems()`` to get a stable value. It + is initialized by ``calculate_node_totalpages()``. + +``present_early_pages`` + The present pages existing within the zone located on memory available since + early boot, excluding hotplugged memory. Defined only when + ``CONFIG_MEMORY_HOTPLUG`` is enabled and initialized by + ``calculate_node_totalpages()``. + +``cma_pages`` + The pages reserved for CMA use. These pages behave like ``ZONE_MOVABLE`` when + they are not used for CMA. Defined only when ``CONFIG_CMA`` is enabled. + +``name`` + The name of the zone. It is a pointer to the corresponding element of + the ``zone_names`` array. + +``nr_isolate_pageblock`` + Number of isolated pageblocks. It is used to solve incorrect freepage counting + problem due to racy retrieving migratetype of pageblock. Protected by + ``zone->lock``. Defined only when ``CONFIG_MEMORY_ISOLATION`` is enabled. + +``span_seqlock`` + The seqlock to protect ``zone_start_pfn`` and ``spanned_pages``. It is a + seqlock because it has to be read outside of ``zone->lock``, and it is done in + the main allocator path. However, the seqlock is written quite infrequently. + Defined only when ``CONFIG_MEMORY_HOTPLUG`` is enabled. + +``initialized`` + The flag indicating if the zone is initialized. Set by + ``init_currently_empty_zone()`` during boot. + +``free_area`` + The array of free areas, where each element corresponds to a specific order + which is a power of two. The buddy allocator uses this structure to manage + free memory efficiently. When allocating, it tries to find the smallest + sufficient block, if the smallest sufficient block is larger than the + requested size, it will be recursively split into the next smaller blocks + until the required size is reached. When a page is freed, it may be merged + with its buddy to form a larger block. It is initialized by + ``zone_init_free_lists()``. + +``unaccepted_pages`` + The list of pages to be accepted. All pages on the list are ``MAX_PAGE_ORDER``. + Defined only when ``CONFIG_UNACCEPTED_MEMORY`` is enabled. + +``flags`` + The zone flags. The least three bits are used and defined by + ``enum zone_flags``. ``ZONE_BOOSTED_WATERMARK`` (bit 0): zone recently boosted + watermarks. Cleared when kswapd is woken. ``ZONE_RECLAIM_ACTIVE`` (bit 1): + kswapd may be scanning the zone. ``ZONE_BELOW_HIGH`` (bit 2): zone is below + high watermark. + +``lock`` + The main lock that protects the internal data structures of the page allocator + specific to the zone, especially protects ``free_area``. + +``percpu_drift_mark`` + When free pages are below this point, additional steps are taken when reading + the number of free pages to avoid per-cpu counter drift allowing watermarks + to be breached. It is updated in ``refresh_zone_stat_thresholds()``. + +Compaction control +~~~~~~~~~~~~~~~~~~ + +``compact_cached_free_pfn`` + The PFN where compaction free scanner should start in the next scan. + +``compact_cached_migrate_pfn`` + The PFNs where compaction migration scanner should start in the next scan. + This array has two elements: the first one is used in ``MIGRATE_ASYNC`` mode, + and the other one is used in ``MIGRATE_SYNC`` mode. + +``compact_init_migrate_pfn`` + The initial migration PFN which is initialized to 0 at boot time, and to the + first pageblock with migratable pages in the zone after a full compaction + finishes. It is used to check if a scan is a whole zone scan or not. + +``compact_init_free_pfn`` + The initial free PFN which is initialized to 0 at boot time and to the last + pageblock with free ``MIGRATE_MOVABLE`` pages in the zone. It is used to check + if it is the start of a scan. + +``compact_considered`` + The number of compactions attempted since last failure. It is reset in + ``defer_compaction()`` when a compaction fails to result in a page allocation + success. It is increased by 1 in ``compaction_deferred()`` when a compaction + should be skipped. ``compaction_deferred()`` is called before + ``compact_zone()`` is called, ``compaction_defer_reset()`` is called when + ``compact_zone()`` returns ``COMPACT_SUCCESS``, ``defer_compaction()`` is + called when ``compact_zone()`` returns ``COMPACT_PARTIAL_SKIPPED`` or + ``COMPACT_COMPLETE``. + +``compact_defer_shift`` + The number of compactions skipped before trying again is + ``1<<compact_defer_shift``. It is increased by 1 in ``defer_compaction()``. + It is reset in ``compaction_defer_reset()`` when a direct compaction results + in a page allocation success. Its maximum value is ``COMPACT_MAX_DEFER_SHIFT``. + +``compact_order_failed`` + The minimum compaction failed order. It is set in ``compaction_defer_reset()`` + when a compaction succeeds and in ``defer_compaction()`` when a compaction + fails to result in a page allocation success. + +``compact_blockskip_flush`` + Set to true when compaction migration scanner and free scanner meet, which + means the ``PB_migrate_skip`` bits should be cleared. + +``contiguous`` + Set to true when the zone is contiguous (in other words, no hole). + +Statistics +~~~~~~~~~~ + +``vm_stat`` + VM statistics for the zone. The items tracked are defined by + ``enum zone_stat_item``. + +``vm_numa_event`` + VM NUMA event statistics for the zone. The items tracked are defined by + ``enum numa_stat_item``. + +``per_cpu_zonestats`` + Per-CPU VM statistics for the zone. It records VM statistics and VM NUMA event + statistics on a per-CPU basis. It reduces updates to the global ``vm_stat`` + and ``vm_numa_event`` fields of the zone to improve performance. .. _pages: diff --git a/Documentation/mm/process_addrs.rst b/Documentation/mm/process_addrs.rst index 81417fa2ed20..e6756e78b476 100644 --- a/Documentation/mm/process_addrs.rst +++ b/Documentation/mm/process_addrs.rst @@ -716,9 +716,14 @@ calls :c:func:`!rcu_read_lock` to ensure that the VMA is looked up in an RCU critical section, then attempts to VMA lock it via :c:func:`!vma_start_read`, before releasing the RCU lock via :c:func:`!rcu_read_unlock`. -VMA read locks hold the read lock on the :c:member:`!vma->vm_lock` semaphore for -their duration and the caller of :c:func:`!lock_vma_under_rcu` must release it -via :c:func:`!vma_end_read`. +In cases when the user already holds mmap read lock, :c:func:`!vma_start_read_locked` +and :c:func:`!vma_start_read_locked_nested` can be used. These functions do not +fail due to lock contention but the caller should still check their return values +in case they fail for other reasons. + +VMA read locks increment :c:member:`!vma.vm_refcnt` reference counter for their +duration and the caller of :c:func:`!lock_vma_under_rcu` must drop it via +:c:func:`!vma_end_read`. VMA **write** locks are acquired via :c:func:`!vma_start_write` in instances where a VMA is about to be modified, unlike :c:func:`!vma_start_read` the lock is always @@ -726,9 +731,9 @@ acquired. An mmap write lock **must** be held for the duration of the VMA write lock, releasing or downgrading the mmap write lock also releases the VMA write lock so there is no :c:func:`!vma_end_write` function. -Note that a semaphore write lock is not held across a VMA lock. Rather, a -sequence number is used for serialisation, and the write semaphore is only -acquired at the point of write lock to update this. +Note that when write-locking a VMA lock, the :c:member:`!vma.vm_refcnt` is temporarily +modified so that readers can detect the presense of a writer. The reference counter is +restored once the vma sequence number used for serialisation is updated. This ensures the semantics we require - VMA write locks provide exclusive write access to the VMA. @@ -738,7 +743,7 @@ Implementation details The VMA lock mechanism is designed to be a lightweight means of avoiding the use of the heavily contended mmap lock. It is implemented using a combination of a -read/write semaphore and sequence numbers belonging to the containing +reference counter and sequence numbers belonging to the containing :c:struct:`!struct mm_struct` and the VMA. Read locks are acquired via :c:func:`!vma_start_read`, which is an optimistic @@ -779,28 +784,31 @@ release of any VMA locks on its release makes sense, as you would never want to keep VMAs locked across entirely separate write operations. It also maintains correct lock ordering. -Each time a VMA read lock is acquired, we acquire a read lock on the -:c:member:`!vma->vm_lock` read/write semaphore and hold it, while checking that -the sequence count of the VMA does not match that of the mm. +Each time a VMA read lock is acquired, we increment :c:member:`!vma.vm_refcnt` +reference counter and check that the sequence count of the VMA does not match +that of the mm. -If it does, the read lock fails. If it does not, we hold the lock, excluding -writers, but permitting other readers, who will also obtain this lock under RCU. +If it does, the read lock fails and :c:member:`!vma.vm_refcnt` is dropped. +If it does not, we keep the reference counter raised, excluding writers, but +permitting other readers, who can also obtain this lock under RCU. Importantly, maple tree operations performed in :c:func:`!lock_vma_under_rcu` are also RCU safe, so the whole read lock operation is guaranteed to function correctly. -On the write side, we acquire a write lock on the :c:member:`!vma->vm_lock` -read/write semaphore, before setting the VMA's sequence number under this lock, -also simultaneously holding the mmap write lock. +On the write side, we set a bit in :c:member:`!vma.vm_refcnt` which can't be +modified by readers and wait for all readers to drop their reference count. +Once there are no readers, the VMA's sequence number is set to match that of +the mm. During this entire operation mmap write lock is held. This way, if any read locks are in effect, :c:func:`!vma_start_write` will sleep until these are finished and mutual exclusion is achieved. -After setting the VMA's sequence number, the lock is released, avoiding -complexity with a long-term held write lock. +After setting the VMA's sequence number, the bit in :c:member:`!vma.vm_refcnt` +indicating a writer is cleared. From this point on, VMA's sequence number will +indicate VMA's write-locked state until mmap write lock is dropped or downgraded. -This clever combination of a read/write semaphore and sequence count allows for +This clever combination of a reference counter and sequence count allows for fast RCU-based per-VMA lock acquisition (especially on page fault, though utilised elsewhere) with minimal complexity around lock ordering. diff --git a/Documentation/mm/transhuge.rst b/Documentation/mm/transhuge.rst index a2cd8800d527..0e7f8e4cd2e3 100644 --- a/Documentation/mm/transhuge.rst +++ b/Documentation/mm/transhuge.rst @@ -116,14 +116,27 @@ pages: succeeds on tail pages. - map/unmap of a PMD entry for the whole THP increment/decrement - folio->_entire_mapcount, increment/decrement folio->_large_mapcount - and also increment/decrement folio->_nr_pages_mapped by ENTIRELY_MAPPED - when _entire_mapcount goes from -1 to 0 or 0 to -1. + folio->_entire_mapcount and folio->_large_mapcount. + + We also maintain the two slots for tracking MM owners (MM ID and + corresponding mapcount), and the current status ("maybe mapped shared" vs. + "mapped exclusively"). + + With CONFIG_PAGE_MAPCOUNT, we also increment/decrement + folio->_nr_pages_mapped by ENTIRELY_MAPPED when _entire_mapcount goes + from -1 to 0 or 0 to -1. - map/unmap of individual pages with PTE entry increment/decrement - page->_mapcount, increment/decrement folio->_large_mapcount and also - increment/decrement folio->_nr_pages_mapped when page->_mapcount goes - from -1 to 0 or 0 to -1 as this counts the number of pages mapped by PTE. + folio->_large_mapcount. + + We also maintain the two slots for tracking MM owners (MM ID and + corresponding mapcount), and the current status ("maybe mapped shared" vs. + "mapped exclusively"). + + With CONFIG_PAGE_MAPCOUNT, we also increment/decrement + page->_mapcount and increment/decrement folio->_nr_pages_mapped when + page->_mapcount goes from -1 to 0 or 0 to -1 as this counts the number + of pages mapped by PTE. split_huge_page internally has to distribute the refcounts in the head page to the tail pages before clearing all PG_head/tail bits from the page @@ -151,8 +164,8 @@ clear where references should go after split: it will stay on the head page. Note that split_huge_pmd() doesn't have any limitations on refcounting: pmd can be split at any point and never fails. -Partial unmap and deferred_split_folio() -======================================== +Partial unmap and deferred_split_folio() (anon THP only) +======================================================== Unmapping part of THP (with munmap() or other way) is not going to free memory immediately. Instead, we detect that a subpage of THP is not in use @@ -167,3 +180,13 @@ a THP crosses a VMA boundary. The function deferred_split_folio() is used to queue a folio for splitting. The splitting itself will happen when we get memory pressure via shrinker interface. + +With CONFIG_PAGE_MAPCOUNT, we reliably detect partial mappings based on +folio->_nr_pages_mapped. + +With CONFIG_NO_PAGE_MAPCOUNT, we detect partial mappings based on the +average per-page mapcount in a THP: if the average is < 1, an anon THP is +certainly partially mapped. As long as only a single process maps a THP, +this detection is reliable. With long-running child processes, there can +be scenarios where partial mappings can currently not be detected, and +might need asynchronous detection during memory reclaim in the future. diff --git a/Documentation/mm/z3fold.rst b/Documentation/mm/z3fold.rst deleted file mode 100644 index 25b5935d06c7..000000000000 --- a/Documentation/mm/z3fold.rst +++ /dev/null @@ -1,28 +0,0 @@ -====== -z3fold -====== - -z3fold is a special purpose allocator for storing compressed pages. -It is designed to store up to three compressed pages per physical page. -It is a zbud derivative which allows for higher compression -ratio keeping the simplicity and determinism of its predecessor. - -The main differences between z3fold and zbud are: - -* unlike zbud, z3fold allows for up to PAGE_SIZE allocations -* z3fold can hold up to 3 compressed pages in its page -* z3fold doesn't export any API itself and is thus intended to be used - via the zpool API. - -To keep the determinism and simplicity, z3fold, just like zbud, always -stores an integral number of compressed pages per page, but it can store -up to 3 pages unlike zbud which can store at most 2. Therefore the -compression ratio goes to around 2.7x while zbud's one is around 1.7x. - -Unlike zbud (but like zsmalloc for that matter) z3fold_alloc() does not -return a dereferenceable pointer. Instead, it returns an unsigned long -handle which encodes actual location of the allocated object. - -Keeping effective compression ratio close to zsmalloc's, z3fold doesn't -depend on MMU enabled and provides more predictable reclaim behavior -which makes it a better fit for small and response-critical systems. diff --git a/Documentation/mm/zsmalloc.rst b/Documentation/mm/zsmalloc.rst index 76902835e68e..d2bbecd78e14 100644 --- a/Documentation/mm/zsmalloc.rst +++ b/Documentation/mm/zsmalloc.rst @@ -27,9 +27,8 @@ Instead, it returns an opaque handle (unsigned long) which encodes actual location of the allocated object. The reason for this indirection is that zsmalloc does not keep zspages permanently mapped since that would cause issues on 32-bit systems where the VA region for kernel space mappings -is very small. So, before using the allocating memory, the object has to -be mapped using zs_map_object() to get a usable pointer and subsequently -unmapped using zs_unmap_object(). +is very small. So, using the allocated memory should be done through the +proper handle-based APIs. stat ==== diff --git a/Documentation/netlink/specs/lockd.yaml b/Documentation/netlink/specs/lockd.yaml new file mode 100644 index 000000000000..bbd4da5fe54b --- /dev/null +++ b/Documentation/netlink/specs/lockd.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + +name: lockd +protocol: genetlink +uapi-header: linux/lockd_netlink.h + +doc: lockd configuration over generic netlink + +attribute-sets: + - + name: server + attributes: + - + name: gracetime + type: u32 + - + name: tcp-port + type: u16 + - + name: udp-port + type: u16 + +operations: + list: + - + name: server-set + doc: set the lockd server parameters + attribute-set: server + flags: [ admin-perm ] + do: + request: + attributes: + - gracetime + - tcp-port + - udp-port + - + name: server-get + doc: get the lockd server parameters + attribute-set: server + do: + reply: + attributes: + - gracetime + - tcp-port + - udp-port diff --git a/Documentation/netlink/specs/rt_addr.yaml b/Documentation/netlink/specs/rt_addr.yaml index 5dd5469044c7..df6b23f06a22 100644 --- a/Documentation/netlink/specs/rt_addr.yaml +++ b/Documentation/netlink/specs/rt_addr.yaml @@ -78,45 +78,46 @@ definitions: attribute-sets: - name: addr-attrs + name-prefix: ifa- attributes: - - name: ifa-address + name: address type: binary display-hint: ipv4 - - name: ifa-local + name: local type: binary display-hint: ipv4 - - name: ifa-label + name: label type: string - - name: ifa-broadcast + name: broadcast type: binary display-hint: ipv4 - - name: ifa-anycast + name: anycast type: binary - - name: ifa-cacheinfo + name: cacheinfo type: binary struct: ifa-cacheinfo - - name: ifa-multicast + name: multicast type: binary - - name: ifa-flags + name: flags type: u32 enum: ifa-flags enum-as-flags: true - - name: ifa-rt-priority + name: rt-priority type: u32 - - name: ifa-target-netnsid + name: target-netnsid type: binary - - name: ifa-proto + name: proto type: u8 @@ -137,10 +138,10 @@ operations: - ifa-prefixlen - ifa-scope - ifa-index - - ifa-address - - ifa-label - - ifa-local - - ifa-cacheinfo + - address + - label + - local + - cacheinfo - name: deladdr doc: Remove address @@ -154,8 +155,8 @@ operations: - ifa-prefixlen - ifa-scope - ifa-index - - ifa-address - - ifa-local + - address + - local - name: getaddr doc: Dump address information. @@ -169,7 +170,7 @@ operations: value: 20 attributes: *ifaddr-all - - name: getmaddrs + name: getmulticast doc: Get / dump IPv4/IPv6 multicast addresses. attribute-set: addr-attrs fixed-header: ifaddrmsg @@ -182,11 +183,12 @@ operations: reply: value: 58 attributes: &mcaddr-attrs - - ifa-multicast - - ifa-cacheinfo + - multicast + - cacheinfo dump: request: value: 58 + attributes: - ifa-family reply: value: 58 diff --git a/Documentation/netlink/specs/rt_route.yaml b/Documentation/netlink/specs/rt_route.yaml index a674103e5bc4..292469c7d4b9 100644 --- a/Documentation/netlink/specs/rt_route.yaml +++ b/Documentation/netlink/specs/rt_route.yaml @@ -80,165 +80,167 @@ definitions: attribute-sets: - name: route-attrs + name-prefix: rta- attributes: - - name: rta-dst + name: dst type: binary display-hint: ipv4 - - name: rta-src + name: src type: binary display-hint: ipv4 - - name: rta-iif + name: iif type: u32 - - name: rta-oif + name: oif type: u32 - - name: rta-gateway + name: gateway type: binary display-hint: ipv4 - - name: rta-priority + name: priority type: u32 - - name: rta-prefsrc + name: prefsrc type: binary display-hint: ipv4 - - name: rta-metrics + name: metrics type: nest - nested-attributes: rta-metrics + nested-attributes: metrics - - name: rta-multipath + name: multipath type: binary - - name: rta-protoinfo # not used + name: protoinfo # not used type: binary - - name: rta-flow + name: flow type: u32 - - name: rta-cacheinfo + name: cacheinfo type: binary struct: rta-cacheinfo - - name: rta-session # not used + name: session # not used type: binary - - name: rta-mp-algo # not used + name: mp-algo # not used type: binary - - name: rta-table + name: table type: u32 - - name: rta-mark + name: mark type: u32 - - name: rta-mfc-stats + name: mfc-stats type: binary - - name: rta-via + name: via type: binary - - name: rta-newdst + name: newdst type: binary - - name: rta-pref + name: pref type: u8 - - name: rta-encap-type + name: encap-type type: u16 - - name: rta-encap + name: encap type: binary # tunnel specific nest - - name: rta-expires + name: expires type: u32 - - name: rta-pad + name: pad type: binary - - name: rta-uid + name: uid type: u32 - - name: rta-ttl-propagate + name: ttl-propagate type: u8 - - name: rta-ip-proto + name: ip-proto type: u8 - - name: rta-sport + name: sport type: u16 - - name: rta-dport + name: dport type: u16 - - name: rta-nh-id + name: nh-id type: u32 - - name: rta-flowlabel + name: flowlabel type: u32 byte-order: big-endian display-hint: hex - - name: rta-metrics + name: metrics + name-prefix: rtax- attributes: - - name: rtax-unspec + name: unspec type: unused value: 0 - - name: rtax-lock + name: lock type: u32 - - name: rtax-mtu + name: mtu type: u32 - - name: rtax-window + name: window type: u32 - - name: rtax-rtt + name: rtt type: u32 - - name: rtax-rttvar + name: rttvar type: u32 - - name: rtax-ssthresh + name: ssthresh type: u32 - - name: rtax-cwnd + name: cwnd type: u32 - - name: rtax-advmss + name: advmss type: u32 - - name: rtax-reordering + name: reordering type: u32 - - name: rtax-hoplimit + name: hoplimit type: u32 - - name: rtax-initcwnd + name: initcwnd type: u32 - - name: rtax-features + name: features type: u32 - - name: rtax-rto-min + name: rto-min type: u32 - - name: rtax-initrwnd + name: initrwnd type: u32 - - name: rtax-quickack + name: quickack type: u32 - - name: rtax-cc-algo + name: cc-algo type: string - - name: rtax-fastopen-no-cookie + name: fastopen-no-cookie type: u32 operations: @@ -254,18 +256,18 @@ operations: value: 26 attributes: - rtm-family - - rta-src + - src - rtm-src-len - - rta-dst + - dst - rtm-dst-len - - rta-iif - - rta-oif - - rta-ip-proto - - rta-sport - - rta-dport - - rta-mark - - rta-uid - - rta-flowlabel + - iif + - oif + - ip-proto + - sport + - dport + - mark + - uid + - flowlabel reply: value: 24 attributes: &all-route-attrs @@ -278,34 +280,34 @@ operations: - rtm-scope - rtm-type - rtm-flags - - rta-dst - - rta-src - - rta-iif - - rta-oif - - rta-gateway - - rta-priority - - rta-prefsrc - - rta-metrics - - rta-multipath - - rta-flow - - rta-cacheinfo - - rta-table - - rta-mark - - rta-mfc-stats - - rta-via - - rta-newdst - - rta-pref - - rta-encap-type - - rta-encap - - rta-expires - - rta-pad - - rta-uid - - rta-ttl-propagate - - rta-ip-proto - - rta-sport - - rta-dport - - rta-nh-id - - rta-flowlabel + - dst + - src + - iif + - oif + - gateway + - priority + - prefsrc + - metrics + - multipath + - flow + - cacheinfo + - table + - mark + - mfc-stats + - via + - newdst + - pref + - encap-type + - encap + - expires + - pad + - uid + - ttl-propagate + - ip-proto + - sport + - dport + - nh-id + - flowlabel dump: request: value: 26 diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 058193ed2eeb..c64133d309bf 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -63,6 +63,7 @@ Contents: gtp ila ioam6-sysctl + iou-zcrx ip_dynaddr ipsec ip-sysctl diff --git a/Documentation/networking/iou-zcrx.rst b/Documentation/networking/iou-zcrx.rst new file mode 100644 index 000000000000..0127319b30bb --- /dev/null +++ b/Documentation/networking/iou-zcrx.rst @@ -0,0 +1,202 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +io_uring zero copy Rx +===================== + +Introduction +============ + +io_uring zero copy Rx (ZC Rx) is a feature that removes kernel-to-user copy on +the network receive path, allowing packet data to be received directly into +userspace memory. This feature is different to TCP_ZEROCOPY_RECEIVE in that +there are no strict alignment requirements and no need to mmap()/munmap(). +Compared to kernel bypass solutions such as e.g. DPDK, the packet headers are +processed by the kernel TCP stack as normal. + +NIC HW Requirements +=================== + +Several NIC HW features are required for io_uring ZC Rx to work. For now the +kernel API does not configure the NIC and it must be done by the user. + +Header/data split +----------------- + +Required to split packets at the L4 boundary into a header and a payload. +Headers are received into kernel memory as normal and processed by the TCP +stack as normal. Payloads are received into userspace memory directly. + +Flow steering +------------- + +Specific HW Rx queues are configured for this feature, but modern NICs +typically distribute flows across all HW Rx queues. Flow steering is required +to ensure that only desired flows are directed towards HW queues that are +configured for io_uring ZC Rx. + +RSS +--- + +In addition to flow steering above, RSS is required to steer all other non-zero +copy flows away from queues that are configured for io_uring ZC Rx. + +Usage +===== + +Setup NIC +--------- + +Must be done out of band for now. + +Ensure there are at least two queues:: + + ethtool -L eth0 combined 2 + +Enable header/data split:: + + ethtool -G eth0 tcp-data-split on + +Carve out half of the HW Rx queues for zero copy using RSS:: + + ethtool -X eth0 equal 1 + +Set up flow steering, bearing in mind that queues are 0-indexed:: + + ethtool -N eth0 flow-type tcp6 ... action 1 + +Setup io_uring +-------------- + +This section describes the low level io_uring kernel API. Please refer to +liburing documentation for how to use the higher level API. + +Create an io_uring instance with the following required setup flags:: + + IORING_SETUP_SINGLE_ISSUER + IORING_SETUP_DEFER_TASKRUN + IORING_SETUP_CQE32 + +Create memory area +------------------ + +Allocate userspace memory area for receiving zero copy data:: + + void *area_ptr = mmap(NULL, area_size, + PROT_READ | PROT_WRITE, + MAP_ANONYMOUS | MAP_PRIVATE, + 0, 0); + +Create refill ring +------------------ + +Allocate memory for a shared ringbuf used for returning consumed buffers:: + + void *ring_ptr = mmap(NULL, ring_size, + PROT_READ | PROT_WRITE, + MAP_ANONYMOUS | MAP_PRIVATE, + 0, 0); + +This refill ring consists of some space for the header, followed by an array of +``struct io_uring_zcrx_rqe``:: + + size_t rq_entries = 4096; + size_t ring_size = rq_entries * sizeof(struct io_uring_zcrx_rqe) + PAGE_SIZE; + /* align to page size */ + ring_size = (ring_size + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1); + +Register ZC Rx +-------------- + +Fill in registration structs:: + + struct io_uring_zcrx_area_reg area_reg = { + .addr = (__u64)(unsigned long)area_ptr, + .len = area_size, + .flags = 0, + }; + + struct io_uring_region_desc region_reg = { + .user_addr = (__u64)(unsigned long)ring_ptr, + .size = ring_size, + .flags = IORING_MEM_REGION_TYPE_USER, + }; + + struct io_uring_zcrx_ifq_reg reg = { + .if_idx = if_nametoindex("eth0"), + /* this is the HW queue with desired flow steered into it */ + .if_rxq = 1, + .rq_entries = rq_entries, + .area_ptr = (__u64)(unsigned long)&area_reg, + .region_ptr = (__u64)(unsigned long)®ion_reg, + }; + +Register with kernel:: + + io_uring_register_ifq(ring, ®); + +Map refill ring +--------------- + +The kernel fills in fields for the refill ring in the registration ``struct +io_uring_zcrx_ifq_reg``. Map it into userspace:: + + struct io_uring_zcrx_rq refill_ring; + + refill_ring.khead = (unsigned *)((char *)ring_ptr + reg.offsets.head); + refill_ring.khead = (unsigned *)((char *)ring_ptr + reg.offsets.tail); + refill_ring.rqes = + (struct io_uring_zcrx_rqe *)((char *)ring_ptr + reg.offsets.rqes); + refill_ring.rq_tail = 0; + refill_ring.ring_ptr = ring_ptr; + +Receiving data +-------------- + +Prepare a zero copy recv request:: + + struct io_uring_sqe *sqe; + + sqe = io_uring_get_sqe(ring); + io_uring_prep_rw(IORING_OP_RECV_ZC, sqe, fd, NULL, 0, 0); + sqe->ioprio |= IORING_RECV_MULTISHOT; + +Now, submit and wait:: + + io_uring_submit_and_wait(ring, 1); + +Finally, process completions:: + + struct io_uring_cqe *cqe; + unsigned int count = 0; + unsigned int head; + + io_uring_for_each_cqe(ring, head, cqe) { + struct io_uring_zcrx_cqe *rcqe = (struct io_uring_zcrx_cqe *)(cqe + 1); + + unsigned long mask = (1ULL << IORING_ZCRX_AREA_SHIFT) - 1; + unsigned char *data = area_ptr + (rcqe->off & mask); + /* do something with the data */ + + count++; + } + io_uring_cq_advance(ring, count); + +Recycling buffers +----------------- + +Return buffers back to the kernel to be used again:: + + struct io_uring_zcrx_rqe *rqe; + unsigned mask = refill_ring.ring_entries - 1; + rqe = &refill_ring.rqes[refill_ring.rq_tail & mask]; + + unsigned long area_offset = rcqe->off & ~IORING_ZCRX_AREA_MASK; + rqe->off = area_offset | area_reg.rq_area_token; + rqe->len = cqe->res; + IO_URING_WRITE_ONCE(*refill_ring.ktail, ++refill_ring.rq_tail); + +Testing +======= + +See ``tools/testing/selftests/drivers/net/hw/iou-zcrx.c`` diff --git a/Documentation/networking/netdevices.rst b/Documentation/networking/netdevices.rst index ebb868f50ac2..eab601ab2db0 100644 --- a/Documentation/networking/netdevices.rst +++ b/Documentation/networking/netdevices.rst @@ -338,10 +338,35 @@ operations directly under the netdev instance lock. Devices drivers are encouraged to rely on the instance lock where possible. For the (mostly software) drivers that need to interact with the core stack, -there are two sets of interfaces: ``dev_xxx`` and ``netif_xxx`` (e.g., -``dev_set_mtu`` and ``netif_set_mtu``). The ``dev_xxx`` functions handle -acquiring the instance lock themselves, while the ``netif_xxx`` functions -assume that the driver has already acquired the instance lock. +there are two sets of interfaces: ``dev_xxx``/``netdev_xxx`` and ``netif_xxx`` +(e.g., ``dev_set_mtu`` and ``netif_set_mtu``). The ``dev_xxx``/``netdev_xxx`` +functions handle acquiring the instance lock themselves, while the +``netif_xxx`` functions assume that the driver has already acquired +the instance lock. + +Notifiers and netdev instance lock +================================== + +For device drivers that implement shaping or queue management APIs, +some of the notifiers (``enum netdev_cmd``) are running under the netdev +instance lock. + +For devices with locked ops, currently only the following notifiers are +running under the lock: +* ``NETDEV_REGISTER`` +* ``NETDEV_UP`` +* ``NETDEV_CHANGE`` + +The following notifiers are running without the lock: +* ``NETDEV_UNREGISTER`` + +There are no clear expectations for the remaining notifiers. Notifiers not on +the list may run with or without the instance lock, potentially even invoking +the same notifier type with and without the lock from different code paths. +The goal is to eventually ensure that all (or most, with a few documented +exceptions) notifiers run under the instance lock. Please extend this +documentation whenever you make explicit assumption about lock being held +from a notifier. NETDEV_INTERNAL symbol namespace ================================ diff --git a/Documentation/process/maintainer-soc-clean-dts.rst b/Documentation/process/maintainer-soc-clean-dts.rst index 1b32430d0cfc..5423fb7d6047 100644 --- a/Documentation/process/maintainer-soc-clean-dts.rst +++ b/Documentation/process/maintainer-soc-clean-dts.rst @@ -17,8 +17,9 @@ Strict DTS DT Schema and dtc Compliance No changes to the SoC platform Devicetree sources (DTS files) should introduce new ``make dtbs_check W=1`` warnings. Warnings in a new board DTS, which are results of issues in an included DTSI file, are considered existing, not new -warnings. The platform maintainers have automation in place which should point -out any new warnings. +warnings. For series split between different trees (DT bindings go via driver +subsystem tree), warnings on linux-next are decisive. The platform maintainers +have automation in place which should point out any new warnings. If a commit introducing new warnings gets accepted somehow, the resulting issues shall be fixed in reasonable time (e.g. within one release) or the diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst index 54be7ddf3e57..6e6a515d0899 100644 --- a/Documentation/rust/arch-support.rst +++ b/Documentation/rust/arch-support.rst @@ -15,6 +15,7 @@ support corresponds to ``S`` values in the ``MAINTAINERS`` file. ============= ================ ============================================== Architecture Level of support Constraints ============= ================ ============================================== +``arm`` Maintained ARMv7 Little Endian only. ``arm64`` Maintained Little Endian only. ``loongarch`` Maintained \- ``riscv`` Maintained ``riscv64`` and LLVM/Clang only. diff --git a/Documentation/rust/coding-guidelines.rst b/Documentation/rust/coding-guidelines.rst index a2e326b42410..27f2a7bb5a4a 100644 --- a/Documentation/rust/coding-guidelines.rst +++ b/Documentation/rust/coding-guidelines.rst @@ -373,3 +373,11 @@ triggered due to non-local changes (such as ``dead_code``). For more information about diagnostics in Rust, please see: https://doc.rust-lang.org/stable/reference/attributes/diagnostics.html + +Error handling +-------------- + +For some background and guidelines about Rust for Linux specific error handling, +please see: + + https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust diff --git a/Documentation/rust/testing.rst b/Documentation/rust/testing.rst index 180b886e0f1e..f692494f7b74 100644 --- a/Documentation/rust/testing.rst +++ b/Documentation/rust/testing.rst @@ -123,6 +123,13 @@ A current limitation is that KUnit does not support assertions in other tasks. Thus, we presently simply print an error to the kernel log if an assertion actually failed. Additionally, doctests are not run for nonpublic functions. +Since these tests are examples, i.e. they are part of the documentation, they +should generally be written like "real code". Thus, for example, instead of +using ``unwrap()`` or ``expect()``, use the ``?`` operator. For more background, +please see: + + https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust + The ``#[test]`` tests --------------------- diff --git a/Documentation/security/landlock.rst b/Documentation/security/landlock.rst index 59ecdb1c0d4d..e0fc54aff09e 100644 --- a/Documentation/security/landlock.rst +++ b/Documentation/security/landlock.rst @@ -7,7 +7,7 @@ Landlock LSM: kernel documentation ================================== :Author: Mickaël Salaün -:Date: December 2022 +:Date: March 2025 Landlock's goal is to create scoped access-control (i.e. sandboxing). To harden a whole system, this feature should be available to any process, @@ -45,6 +45,10 @@ Guiding principles for safe access controls sandboxed process shall retain their scoped accesses (at the time of resource acquisition) whatever process uses them. Cf. `File descriptor access rights`_. +* Access denials shall be logged according to system and Landlock domain + configurations. Log entries must contain information about the cause of the + denial and the owner of the related security policy. Such log generation + should have a negligible performance and memory impact on allowed requests. Design choices ============== @@ -124,6 +128,13 @@ makes the reasoning much easier and helps avoid pitfalls. .. kernel-doc:: security/landlock/ruleset.h :identifiers: +Additional documentation +======================== + +* Documentation/userspace-api/landlock.rst +* Documentation/admin-guide/LSM/landlock.rst +* https://landlock.io + .. Links .. _tools/testing/selftests/landlock/: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/landlock/ diff --git a/Documentation/security/tpm/index.rst b/Documentation/security/tpm/index.rst index fa593d960040..deda952eacbe 100644 --- a/Documentation/security/tpm/index.rst +++ b/Documentation/security/tpm/index.rst @@ -10,3 +10,4 @@ Trusted Platform Module documentation tpm_vtpm_proxy xen-tpmfront tpm_ftpm_tee + tpm_ffa_crb diff --git a/Documentation/security/tpm/tpm_ffa_crb.rst b/Documentation/security/tpm/tpm_ffa_crb.rst new file mode 100644 index 000000000000..0184193da3c7 --- /dev/null +++ b/Documentation/security/tpm/tpm_ffa_crb.rst @@ -0,0 +1,65 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================== +TPM CRB over FF-A Driver +======================== + +The TPM Command Response Buffer (CRB) interface is a standard TPM interface +defined in the TCG PC Client Platform TPM Profile (PTP) Specification [1]_. +The CRB provides a structured set of control registers a client uses when +interacting with a TPM as well as a data buffer for storing TPM commands and +responses. A CRB interface can be implemented in: + +- hardware registers in a discrete TPM chip + +- in memory for a TPM running in isolated environment where shared memory + allows a client to interact with the TPM + +The Firmware Framework for Arm A-profile (FF-A) [2]_ is a specification +that defines interfaces and protocols for the following purposes: + +- Compartmentalize firmware into software partitions that run in the Arm + Secure world environment (also know as TrustZone) + +- Provide a standard interface for software components in the Non-secure + state, for example OS and Hypervisors, to communicate with this firmware. + +A TPM can be implemented as an FF-A secure service. This could be a firmware +TPM or could potentially be a TPM service that acts as a proxy to a discrete +TPM chip. An FF-A based TPM abstracts hardware details (e.g. bus controller +and chip selects) away from the OS and can protect locality 4 from access +by an OS. The TCG-defined CRB interface is used by clients to interact +with the TPM service. + +The Arm TPM Service Command Response Buffer Interface Over FF-A [3]_ +specification defines FF-A messages that can be used by a client to signal +when updates have been made to the CRB. + +How the Linux CRB driver interacts with FF-A is summarized below: + +- The tpm_crb_ffa driver registers with the FF-A subsystem in the kernel + with an architected TPM service UUID defined in the CRB over FF-A spec. + +- If a TPM service is discovered by FF-A, the probe() function in the + tpm_crb_ffa driver runs, and the driver initializes. + +- The probing and initialization of the Linux CRB driver is triggered + by the discovery of a TPM advertised via ACPI. The CRB driver can + detect the type of TPM through the ACPI 'start' method. The start + method for Arm FF-A was defined in TCG ACPI v1.4 [4]_. + +- When the CRB driver performs its normal functions such as signaling 'start' + and locality request/relinquish it invokes the tpm_crb_ffa_start() funnction + in the tpm_crb_ffa driver which handles the FF-A messaging to the TPM. + +References +========== + +.. [1] **TCG PC Client Platform TPM Profile (PTP) Specification** + https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/ +.. [2] **Arm Firmware Framework for Arm A-profile (FF-A)** + https://developer.arm.com/documentation/den0077/latest/ +.. [3] **Arm TPM Service Command Response Buffer Interface Over FF-A** + https://developer.arm.com/documentation/den0138/latest/ +.. [4] **TCG ACPI Specification** + https://trustedcomputinggroup.org/resource/tcg-acpi-specification/ diff --git a/Documentation/subsystem-apis.rst b/Documentation/subsystem-apis.rst index b52ad5b969d4..ff4fe8c936c8 100644 --- a/Documentation/subsystem-apis.rst +++ b/Documentation/subsystem-apis.rst @@ -71,6 +71,7 @@ Other subsystems accounting/index cpu-freq/index + edac/index fpga/index i2c/index iio/index diff --git a/Documentation/tools/rv/index.rst b/Documentation/tools/rv/index.rst index 8fd16d91d639..64ba2efe2e85 100644 --- a/Documentation/tools/rv/index.rst +++ b/Documentation/tools/rv/index.rst @@ -15,6 +15,7 @@ Runtime verification (rv) tool rv-mon rv-mon-wip rv-mon-wwnr + rv-mon-sched .. only:: subproject and html diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst index d4f93d6a2d63..806699871b80 100644 --- a/Documentation/trace/coresight/coresight.rst +++ b/Documentation/trace/coresight/coresight.rst @@ -462,44 +462,35 @@ queried by the perf command line tool: cs_etm// [Kernel PMU event] - linaro@linaro-nano:~$ - Regardless of the number of tracers available in a system (usually equal to the amount of processor cores), the "cs_etm" PMU will be listed only once. A Coresight PMU works the same way as any other PMU, i.e the name of the PMU is -listed along with configuration options within forward slashes '/'. Since a -Coresight system will typically have more than one sink, the name of the sink to -work with needs to be specified as an event option. -On newer kernels the available sinks are listed in sysFS under +provided along with configuration options within forward slashes '/' (see +`Config option formats`_). + +Advanced Perf framework usage +----------------------------- + +Sink selection +~~~~~~~~~~~~~~ + +An appropriate sink will be selected automatically for use with Perf, but since +there will typically be more than one sink, the name of the sink to use may be +specified as a special config option prefixed with '@'. + +The available sinks are listed in sysFS under ($SYSFS)/bus/event_source/devices/cs_etm/sinks/:: root@localhost:/sys/bus/event_source/devices/cs_etm/sinks# ls tmc_etf0 tmc_etr0 tpiu0 -On older kernels, this may need to be found from the list of coresight devices, -available under ($SYSFS)/bus/coresight/devices/:: - - root:~# ls /sys/bus/coresight/devices/ - etm0 etm1 etm2 etm3 etm4 etm5 funnel0 - funnel1 funnel2 replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0 root@linaro-nano:~# perf record -e cs_etm/@tmc_etr0/u --per-thread program -As mentioned above in section "Device Naming scheme", the names of the devices could -look different from what is used in the example above. One must use the device names -as it appears under the sysFS. - -The syntax within the forward slashes '/' is important. The '@' character -tells the parser that a sink is about to be specified and that this is the sink -to use for the trace session. - More information on the above and other example on how to use Coresight with the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub repository [#third]_. -Advanced perf framework usage ------------------------------ - AutoFDO analysis using the perf tools ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -508,7 +499,7 @@ perf can be used to record and analyze trace of programs. Execution can be recorded using 'perf record' with the cs_etm event, specifying the name of the sink to record to, e.g:: - perf record -e cs_etm/@tmc_etr0/u --per-thread + perf record -e cs_etm//u --per-thread The 'perf report' and 'perf script' commands can be used to analyze execution, synthesizing instruction and branch events from the instruction trace. @@ -572,7 +563,7 @@ sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tuto Bubble sorting array of 30000 elements 5910 ms - $ perf record -e cs_etm/@tmc_etr0/u --per-thread taskset -c 2 ./sort + $ perf record -e cs_etm//u --per-thread taskset -c 2 ./sort Bubble sorting array of 30000 elements 12543 ms [ perf record: Woken up 35 times to write data ] diff --git a/Documentation/trace/coresight/panic.rst b/Documentation/trace/coresight/panic.rst new file mode 100644 index 000000000000..a58aa914c241 --- /dev/null +++ b/Documentation/trace/coresight/panic.rst @@ -0,0 +1,362 @@ +=================================================== +Using Coresight for Kernel panic and Watchdog reset +=================================================== + +Introduction +------------ +This documentation is about using Linux coresight trace support to +debug kernel panic and watchdog reset scenarios. + +Coresight trace during Kernel panic +----------------------------------- +From the coresight driver point of view, addressing the kernel panic +situation has four main requirements. + +a. Support for allocation of trace buffer pages from reserved memory area. + Platform can advertise this using a new device tree property added to + relevant coresight nodes. + +b. Support for stopping coresight blocks at the time of panic + +c. Saving required metadata in the specified format + +d. Support for reading trace data captured at the time of panic + +Allocation of trace buffer pages from reserved RAM +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +A new optional device tree property "memory-region" is added to the +Coresight TMC device nodes, that would give the base address and size of trace +buffer. + +Static allocation of trace buffers would ensure that both IOMMU enabled +and disabled cases are handled. Also, platforms that support persistent +RAM will allow users to read trace data in the subsequent boot without +booting the crashdump kernel. + +Note: +For ETR sink devices, this reserved region will be used for both trace +capture and trace data retrieval. +For ETF sink devices, internal SRAM would be used for trace capture, +and they would be synced to reserved region for retrieval. + + +Disabling coresight blocks at the time of panic +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +In order to avoid the situation of losing relevant trace data after a +kernel panic, it would be desirable to stop the coresight blocks at the +time of panic. + +This can be achieved by configuring the comparator, CTI and sink +devices as below:: + + Trigger on panic + Comparator --->External out --->CTI -->External In---->ETR/ETF stop + +Saving metadata at the time of kernel panic +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Coresight metadata involves all additional data that are required for a +successful trace decode in addition to the trace data. This involves +ETR/ETF/ETB register snapshot etc. + +A new optional device property "memory-region" is added to +the ETR/ETF/ETB device nodes for this. + +Reading trace data captured at the time of panic +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Trace data captured at the time of panic, can be read from rebooted kernel +or from crashdump kernel using a special device file /dev/crash_tmc_xxx. +This device file is created only when there is a valid crashdata available. + +General flow of trace capture and decode incase of kernel panic +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +1. Enable source and sink on all the cores using the sysfs interface. + ETR sinks should have trace buffers allocated from reserved memory, + by selecting "resrv" buffer mode from sysfs. + +2. Run relevant tests. + +3. On a kernel panic, all coresight blocks are disabled, necessary + metadata is synced by kernel panic handler. + + System would eventually reboot or boot a crashdump kernel. + +4. For platforms that supports crashdump kernel, raw trace data can be + dumped using the coresight sysfs interface from the crashdump kernel + itself. Persistent RAM is not a requirement in this case. + +5. For platforms that supports persistent RAM, trace data can be dumped + using the coresight sysfs interface in the subsequent Linux boot. + Crashdump kernel is not a requirement in this case. Persistent RAM + ensures that trace data is intact across reboot. + +Coresight trace during Watchdog reset +------------------------------------- +The main difference between addressing the watchdog reset and kernel panic +case are below, + +a. Saving coresight metadata need to be taken care by the + SCP(system control processor) firmware in the specified format, + instead of kernel. + +b. Reserved memory region given by firmware for trace buffer and metadata + has to be in persistent RAM. + Note: This is a requirement for watchdog reset case but optional + in kernel panic case. + +Watchdog reset can be supported only on platforms that meet the above +two requirements. + +Sample commands for testing a Kernel panic case with ETR sink +------------------------------------------------------------- + +1. Boot Linux kernel with "crash_kexec_post_notifiers" added to the kernel + bootargs. This is mandatory if the user would like to read the tracedata + from the crashdump kernel. + +2. Enable the preloaded ETM configuration:: + + #echo 1 > /sys/kernel/config/cs-syscfg/configurations/panicstop/enable + +3. Configure CTI using sysfs interface:: + + #./cti_setup.sh + + #cat cti_setup.sh + + + cd /sys/bus/coresight/devices/ + + ap_cti_config () { + #ETM trig out[0] trigger to Channel 0 + echo 0 4 > channels/trigin_attach + } + + etf_cti_config () { + #ETF Flush in trigger from Channel 0 + echo 0 1 > channels/trigout_attach + echo 1 > channels/trig_filter_enable + } + + etr_cti_config () { + #ETR Flush in from Channel 0 + echo 0 1 > channels/trigout_attach + echo 1 > channels/trig_filter_enable + } + + ctidevs=`find . -name "cti*"` + + for i in $ctidevs + do + cd $i + + connection=`find . -name "ete*"` + if [ ! -z "$connection" ] + then + echo "AP CTI config for $i" + ap_cti_config + fi + + connection=`find . -name "tmc_etf*"` + if [ ! -z "$connection" ] + then + echo "ETF CTI config for $i" + etf_cti_config + fi + + connection=`find . -name "tmc_etr*"` + if [ ! -z "$connection" ] + then + echo "ETR CTI config for $i" + etr_cti_config + fi + + cd .. + done + +Note: CTI connections are SOC specific and hence the above script is +added just for reference. + +4. Choose reserved buffer mode for ETR buffer:: + + #echo "resrv" > /sys/bus/coresight/devices/tmc_etr0/buf_mode_preferred + +5. Enable stop on flush trigger configuration:: + + #echo 1 > /sys/bus/coresight/devices/tmc_etr0/stop_on_flush + +6. Start Coresight tracing on cores 1 and 2 using sysfs interface + +7. Run some application on core 1:: + + #taskset -c 1 dd if=/dev/urandom of=/dev/null & + +8. Invoke kernel panic on core 2:: + + #echo 1 > /proc/sys/kernel/panic + #taskset -c 2 echo c > /proc/sysrq-trigger + +9. From rebooted kernel or crashdump kernel, read crashdata:: + + #dd if=/dev/crash_tmc_etr0 of=/trace/cstrace.bin + +10. Run opencsd decoder tools/scripts to generate the instruction trace. + +Sample instruction trace dump +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Core1 dump:: + + A etm4_enable_hw: ffff800008ae1dd4 + CONTEXT EL2 etm4_enable_hw: ffff800008ae1dd4 + I etm4_enable_hw: ffff800008ae1dd4: + d503201f nop + I etm4_enable_hw: ffff800008ae1dd8: + d503201f nop + I etm4_enable_hw: ffff800008ae1ddc: + d503201f nop + I etm4_enable_hw: ffff800008ae1de0: + d503201f nop + I etm4_enable_hw: ffff800008ae1de4: + d503201f nop + I etm4_enable_hw: ffff800008ae1de8: + d503233f paciasp + I etm4_enable_hw: ffff800008ae1dec: + a9be7bfd stp x29, x30, [sp, #-32]! + I etm4_enable_hw: ffff800008ae1df0: + 910003fd mov x29, sp + I etm4_enable_hw: ffff800008ae1df4: + a90153f3 stp x19, x20, [sp, #16] + I etm4_enable_hw: ffff800008ae1df8: + 2a0003f4 mov w20, w0 + I etm4_enable_hw: ffff800008ae1dfc: + 900085b3 adrp x19, ffff800009b95000 <reserved_mem+0xc48> + I etm4_enable_hw: ffff800008ae1e00: + 910f4273 add x19, x19, #0x3d0 + I etm4_enable_hw: ffff800008ae1e04: + f8747a60 ldr x0, [x19, x20, lsl #3] + E etm4_enable_hw: ffff800008ae1e08: + b4000140 cbz x0, ffff800008ae1e30 <etm4_starting_cpu+0x50> + I 149.039572921 etm4_enable_hw: ffff800008ae1e30: + a94153f3 ldp x19, x20, [sp, #16] + I 149.039572921 etm4_enable_hw: ffff800008ae1e34: + 52800000 mov w0, #0x0 // #0 + I 149.039572921 etm4_enable_hw: ffff800008ae1e38: + a8c27bfd ldp x29, x30, [sp], #32 + + ..snip + + 149.052324811 chacha_block_generic: ffff800008642d80: + 9100a3e0 add x0, + I 149.052324811 chacha_block_generic: ffff800008642d84: + b86178a2 ldr w2, [x5, x1, lsl #2] + I 149.052324811 chacha_block_generic: ffff800008642d88: + 8b010803 add x3, x0, x1, lsl #2 + I 149.052324811 chacha_block_generic: ffff800008642d8c: + b85fc063 ldur w3, [x3, #-4] + I 149.052324811 chacha_block_generic: ffff800008642d90: + 0b030042 add w2, w2, w3 + I 149.052324811 chacha_block_generic: ffff800008642d94: + b8217882 str w2, [x4, x1, lsl #2] + I 149.052324811 chacha_block_generic: ffff800008642d98: + 91000421 add x1, x1, #0x1 + I 149.052324811 chacha_block_generic: ffff800008642d9c: + f100443f cmp x1, #0x11 + + +Core 2 dump:: + + A etm4_enable_hw: ffff800008ae1dd4 + CONTEXT EL2 etm4_enable_hw: ffff800008ae1dd4 + I etm4_enable_hw: ffff800008ae1dd4: + d503201f nop + I etm4_enable_hw: ffff800008ae1dd8: + d503201f nop + I etm4_enable_hw: ffff800008ae1ddc: + d503201f nop + I etm4_enable_hw: ffff800008ae1de0: + d503201f nop + I etm4_enable_hw: ffff800008ae1de4: + d503201f nop + I etm4_enable_hw: ffff800008ae1de8: + d503233f paciasp + I etm4_enable_hw: ffff800008ae1dec: + a9be7bfd stp x29, x30, [sp, #-32]! + I etm4_enable_hw: ffff800008ae1df0: + 910003fd mov x29, sp + I etm4_enable_hw: ffff800008ae1df4: + a90153f3 stp x19, x20, [sp, #16] + I etm4_enable_hw: ffff800008ae1df8: + 2a0003f4 mov w20, w0 + I etm4_enable_hw: ffff800008ae1dfc: + 900085b3 adrp x19, ffff800009b95000 <reserved_mem+0xc48> + I etm4_enable_hw: ffff800008ae1e00: + 910f4273 add x19, x19, #0x3d0 + I etm4_enable_hw: ffff800008ae1e04: + f8747a60 ldr x0, [x19, x20, lsl #3] + E etm4_enable_hw: ffff800008ae1e08: + b4000140 cbz x0, ffff800008ae1e30 <etm4_starting_cpu+0x50> + I 149.046243445 etm4_enable_hw: ffff800008ae1e30: + a94153f3 ldp x19, x20, [sp, #16] + I 149.046243445 etm4_enable_hw: ffff800008ae1e34: + 52800000 mov w0, #0x0 // #0 + I 149.046243445 etm4_enable_hw: ffff800008ae1e38: + a8c27bfd ldp x29, x30, [sp], #32 + I 149.046243445 etm4_enable_hw: ffff800008ae1e3c: + d50323bf autiasp + E 149.046243445 etm4_enable_hw: ffff800008ae1e40: + d65f03c0 ret + A ete_sysreg_write: ffff800008adfa18 + + ..snip + + I 149.05422547 panic: ffff800008096300: + a90363f7 stp x23, x24, [sp, #48] + I 149.05422547 panic: ffff800008096304: + 6b00003f cmp w1, w0 + I 149.05422547 panic: ffff800008096308: + 3a411804 ccmn w0, #0x1, #0x4, ne // ne = any + N 149.05422547 panic: ffff80000809630c: + 540001e0 b.eq ffff800008096348 <panic+0xe0> // b.none + I 149.05422547 panic: ffff800008096310: + f90023f9 str x25, [sp, #64] + E 149.05422547 panic: ffff800008096314: + 97fe44ef bl ffff8000080276d0 <panic_smp_self_stop> + A panic: ffff80000809634c + I 149.05422547 panic: ffff80000809634c: + 910102d5 add x21, x22, #0x40 + I 149.05422547 panic: ffff800008096350: + 52800020 mov w0, #0x1 // #1 + E 149.05422547 panic: ffff800008096354: + 94166b8b bl ffff800008631180 <bust_spinlocks> + N 149.054225518 bust_spinlocks: ffff800008631180: + 340000c0 cbz w0, ffff800008631198 <bust_spinlocks+0x18> + I 149.054225518 bust_spinlocks: ffff800008631184: + f000a321 adrp x1, ffff800009a98000 <pbufs.0+0xbb8> + I 149.054225518 bust_spinlocks: ffff800008631188: + b9405c20 ldr w0, [x1, #92] + I 149.054225518 bust_spinlocks: ffff80000863118c: + 11000400 add w0, w0, #0x1 + I 149.054225518 bust_spinlocks: ffff800008631190: + b9005c20 str w0, [x1, #92] + E 149.054225518 bust_spinlocks: ffff800008631194: + d65f03c0 ret + A panic: ffff800008096358 + +Perf based testing +------------------ + +Starting perf session +~~~~~~~~~~~~~~~~~~~~~ +ETF:: + + perf record -e cs_etm/panicstop,@tmc_etf1/ -C 1 + perf record -e cs_etm/panicstop,@tmc_etf2/ -C 2 + +ETR:: + + perf record -e cs_etm/panicstop,@tmc_etr0/ -C 1,2 + +Reading trace data after panic +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Same sysfs based method explained above can be used to retrieve and +decode the trace data after the reboot on kernel panic. diff --git a/Documentation/trace/debugging.rst b/Documentation/trace/debugging.rst index 54fb16239d70..d54bc500af80 100644 --- a/Documentation/trace/debugging.rst +++ b/Documentation/trace/debugging.rst @@ -136,6 +136,8 @@ kernel, so only the same kernel is guaranteed to work if the mapping is preserved. Switching to a different kernel version may find a different layout and mark the buffer as invalid. +NB: Both the mapped address and size must be page aligned for the architecture. + Using trace_printk() in the boot instance ----------------------------------------- By default, the content of trace_printk() goes into the top level tracing diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index 2b74f96d09d5..c9e88bf65709 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -3077,7 +3077,7 @@ Notice that we lost the sys_nanosleep. # cat set_ftrace_filter hrtimer_run_queues hrtimer_run_pending - hrtimer_init + hrtimer_setup hrtimer_cancel hrtimer_try_to_cancel hrtimer_forward @@ -3115,7 +3115,7 @@ Again, now we want to append. # cat set_ftrace_filter hrtimer_run_queues hrtimer_run_pending - hrtimer_init + hrtimer_setup hrtimer_cancel hrtimer_try_to_cancel hrtimer_forward diff --git a/Documentation/trace/rv/index.rst b/Documentation/trace/rv/index.rst index 15fa966102c0..e80e0057feb4 100644 --- a/Documentation/trace/rv/index.rst +++ b/Documentation/trace/rv/index.rst @@ -12,3 +12,4 @@ Runtime Verification da_monitor_instrumentation.rst monitor_wip.rst monitor_wwnr.rst + monitor_sched.rst diff --git a/Documentation/translations/zh_CN/mm/hmm.rst b/Documentation/translations/zh_CN/mm/hmm.rst index 0669f947d0bc..22c210f4e94f 100644 --- a/Documentation/translations/zh_CN/mm/hmm.rst +++ b/Documentation/translations/zh_CN/mm/hmm.rst @@ -326,7 +326,7 @@ devm_memunmap_pages() 和 devm_release_mem_region() 当资源可以绑定到 ``s 一些设备具有诸如原子PTE位的功能，可以用来实现对系统内存的原子访问。为了支持对一 个共享的虚拟内存页的原子操作，这样的设备需要对该页的访问是排他的，而不是来自CPU -的任何用户空间访问。 ``make_device_exclusive_range()`` 函数可以用来使一 +的任何用户空间访问。 ``make_device_exclusive()`` 函数可以用来使一 个内存范围不能从用户空间访问。 这将用特殊的交换条目替换给定范围内的所有页的映射。任何试图访问交换条目的行为都会 diff --git a/Documentation/translations/zh_CN/mm/index.rst b/Documentation/translations/zh_CN/mm/index.rst index c8726bce8f74..a71116be058f 100644 --- a/Documentation/translations/zh_CN/mm/index.rst +++ b/Documentation/translations/zh_CN/mm/index.rst @@ -58,7 +58,6 @@ Linux内存管理文档 remap_file_pages split_page_table_lock vmalloced-kernel-stacks - z3fold zsmalloc TODOLIST: diff --git a/Documentation/translations/zh_CN/mm/z3fold.rst b/Documentation/translations/zh_CN/mm/z3fold.rst deleted file mode 100644 index 9569a6d88270..000000000000 --- a/Documentation/translations/zh_CN/mm/z3fold.rst +++ /dev/null @@ -1,31 +0,0 @@ -:Original: Documentation/mm/z3fold.rst - -:翻译: - - 司延腾 Yanteng Si <siyanteng@loongson.cn> - -:校译: - - -====== -z3fold -====== - -z3fold是一个专门用于存储压缩页的分配器。它被设计为每个物理页最多可以存储三个压缩页。 -它是zbud的衍生物，允许更高的压缩率，保持其前辈的简单性和确定性。 - -z3fold和zbud的主要区别是: - -* 与zbud不同的是，z3fold允许最大的PAGE_SIZE分配。 -* z3fold在其页面中最多可以容纳3个压缩页面 -* z3fold本身没有输出任何API，因此打算通过zpool的API来使用 - -为了保持确定性和简单性，z3fold，就像zbud一样，总是在每页存储一个整数的压缩页，但是 -它最多可以存储3页，不像zbud最多可以存储2页。因此压缩率达到2.7倍左右，而zbud的压缩 -率是1.7倍左右。 - -不像zbud（但也像zsmalloc），z3fold_alloc()那样不返回一个可重复引用的指针。相反，它 -返回一个无符号长句柄，它编码了被分配对象的实际位置。 - -保持有效的压缩率接近于zsmalloc，z3fold不依赖于MMU的启用，并提供更可预测的回收行 -为，这使得它更适合于小型和反应迅速的系统。 diff --git a/Documentation/usb/CREDITS b/Documentation/usb/CREDITS index 81ea3eb29e96..ce6450a6ed7c 100644 --- a/Documentation/usb/CREDITS +++ b/Documentation/usb/CREDITS @@ -161,7 +161,7 @@ THANKS file in Inaky's driver): - The people at the linux-usb mailing list, for reading so many messages :) Ok, no more kidding; for all your advises! - - All the people at the USB Implementors Forum for their + - All the people at the USB Implementers Forum for their help and assistance. - Nathan Myers <ncm@cantrip.org>, for his advice! (hope you diff --git a/Documentation/userspace-api/fwctl/fwctl-cxl.rst b/Documentation/userspace-api/fwctl/fwctl-cxl.rst new file mode 100644 index 000000000000..670b43b72949 --- /dev/null +++ b/Documentation/userspace-api/fwctl/fwctl-cxl.rst @@ -0,0 +1,142 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================ +fwctl cxl driver +================ + +:Author: Dave Jiang + +Overview +======== + +The CXL spec defines a set of commands that can be issued to the mailbox of a +CXL device or switch. It also left room for vendor specific commands to be +issued to the mailbox as well. fwctl provides a path to issue a set of allowed +mailbox commands from user space to the device moderated by the kernel driver. + +The following 3 commands will be used to support CXL Features: +CXL spec r3.1 8.2.9.6.1 Get Supported Features (Opcode 0500h) +CXL spec r3.1 8.2.9.6.2 Get Feature (Opcode 0501h) +CXL spec r3.1 8.2.9.6.3 Set Feature (Opcode 0502h) + +The "Get Supported Features" return data may be filtered by the kernel driver to +drop any features that are forbidden by the kernel or being exclusively used by +the kernel. The driver will set the "Set Feature Size" of the "Get Supported +Features Supported Feature Entry" to 0 to indicate that the Feature cannot be +modified. The "Get Supported Features" command and the "Get Features" falls +under the fwctl policy of FWCTL_RPC_CONFIGURATION. + +For "Set Feature" command, the access policy currently is broken down into two +categories depending on the Set Feature effects reported by the device. If the +Set Feature will cause immediate change to the device, the fwctl access policy +must be FWCTL_RPC_DEBUG_WRITE_FULL. The effects for this level are +"immediate config change", "immediate data change", "immediate policy change", +or "immediate log change" for the set effects mask. If the effects are "config +change with cold reset" or "config change with conventional reset", then the +fwctl access policy must be FWCTL_RPC_DEBUG_WRITE or higher. + +fwctl cxl User API +================== + +.. kernel-doc:: include/uapi/fwctl/cxl.h + +1. Driver info query +-------------------- + +First step for the app is to issue the ioctl(FWCTL_CMD_INFO). Successful +invocation of the ioctl implies the Features capability is operational and +returns an all zeros 32bit payload. A ``struct fwctl_info`` needs to be filled +out with the ``fwctl_info.out_device_type`` set to ``FWCTL_DEVICE_TYPE_CXL``. +The return data should be ``struct fwctl_info_cxl`` that contains a reserved +32bit field that should be all zeros. + +2. Send hardware commands +------------------------- + +Next step is to send the 'Get Supported Features' command to the driver from +user space via ioctl(FWCTL_RPC). A ``struct fwctl_rpc_cxl`` is pointed to +by ``fwctl_rpc.in``. ``struct fwctl_rpc_cxl.in_payload`` points to +the hardware input structure that is defined by the CXL spec. ``fwctl_rpc.out`` +points to the buffer that contains a ``struct fwctl_rpc_cxl_out`` that includes +the hardware output data inlined as ``fwctl_rpc_cxl_out.payload``. This command +is called twice. First time to retrieve the number of features supported. +A second time to retrieve the specific feature details as the output data. + +After getting the specific feature details, a Get/Set Feature command can be +appropriately programmed and sent. For a "Set Feature" command, the retrieved +feature info contains an effects field that details the resulting +"Set Feature" command will trigger. That will inform the user whether +the system is configured to allowed the "Set Feature" command or not. + +Code example of a Get Feature +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. code-block:: c + + static int cxl_fwctl_rpc_get_test_feature(int fd, struct test_feature *feat_ctx, + const uint32_t expected_data) + { + struct cxl_mbox_get_feat_in *feat_in; + struct fwctl_rpc_cxl_out *out; + struct fwctl_rpc rpc = {0}; + struct fwctl_rpc_cxl *in; + size_t out_size, in_size; + uint32_t val; + void *data; + int rc; + + in_size = sizeof(*in) + sizeof(*feat_in); + rc = posix_memalign((void **)&in, 16, in_size); + if (rc) + return -ENOMEM; + memset(in, 0, in_size); + feat_in = &in->get_feat_in; + + uuid_copy(feat_in->uuid, feat_ctx->uuid); + feat_in->count = feat_ctx->get_size; + + out_size = sizeof(*out) + feat_ctx->get_size; + rc = posix_memalign((void **)&out, 16, out_size); + if (rc) + goto free_in; + memset(out, 0, out_size); + + in->opcode = CXL_MBOX_OPCODE_GET_FEATURE; + in->op_size = sizeof(*feat_in); + + rpc.size = sizeof(rpc); + rpc.scope = FWCTL_RPC_CONFIGURATION; + rpc.in_len = in_size; + rpc.out_len = out_size; + rpc.in = (uint64_t)(uint64_t *)in; + rpc.out = (uint64_t)(uint64_t *)out; + + rc = send_command(fd, &rpc, out); + if (rc) + goto free_all; + + data = out->payload; + val = le32toh(*(__le32 *)data); + if (memcmp(&val, &expected_data, sizeof(val)) != 0) { + rc = -ENXIO; + goto free_all; + } + + free_all: + free(out); + free_in: + free(in); + return rc; + } + +Take a look at CXL CLI test directory +<https://github.com/pmem/ndctl/tree/main/test/fwctl.c> for a detailed user code +for examples on how to exercise this path. + + +fwctl cxl Kernel API +==================== + +.. kernel-doc:: drivers/cxl/core/features.c + :export: +.. kernel-doc:: include/cxl/features.h diff --git a/Documentation/userspace-api/fwctl/fwctl.rst b/Documentation/userspace-api/fwctl/fwctl.rst new file mode 100644 index 000000000000..fdcfe418a83f --- /dev/null +++ b/Documentation/userspace-api/fwctl/fwctl.rst @@ -0,0 +1,286 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +fwctl subsystem +=============== + +:Author: Jason Gunthorpe + +Overview +======== + +Modern devices contain extensive amounts of FW, and in many cases, are largely +software-defined pieces of hardware. The evolution of this approach is largely a +reaction to Moore's Law where a chip tape out is now highly expensive, and the +chip design is extremely large. Replacing fixed HW logic with a flexible and +tightly coupled FW/HW combination is an effective risk mitigation against chip +respin. Problems in the HW design can be counteracted in device FW. This is +especially true for devices which present a stable and backwards compatible +interface to the operating system driver (such as NVMe). + +The FW layer in devices has grown to incredible size and devices frequently +integrate clusters of fast processors to run it. For example, mlx5 devices have +over 30MB of FW code, and big configurations operate with over 1GB of FW managed +runtime state. + +The availability of such a flexible layer has created quite a variety in the +industry where single pieces of silicon are now configurable software-defined +devices and can operate in substantially different ways depending on the need. +Further, we often see cases where specific sites wish to operate devices in ways +that are highly specialized and require applications that have been tailored to +their unique configuration. + +Further, devices have become multi-functional and integrated to the point they +no longer fit neatly into the kernel's division of subsystems. Modern +multi-functional devices have drivers, such as bnxt/ice/mlx5/pds, that span many +subsystems while sharing the underlying hardware using the auxiliary device +system. + +All together this creates a challenge for the operating system, where devices +have an expansive FW environment that needs robust device-specific debugging +support, and FW-driven functionality that is not well suited to “generic” +interfaces. fwctl seeks to allow access to the full device functionality from +user space in the areas of debuggability, management, and first-boot/nth-boot +provisioning. + +fwctl is aimed at the common device design pattern where the OS and FW +communicate via an RPC message layer constructed with a queue or mailbox scheme. +In this case the driver will typically have some layer to deliver RPC messages +and collect RPC responses from device FW. The in-kernel subsystem drivers that +operate the device for its primary purposes will use these RPCs to build their +drivers, but devices also usually have a set of ancillary RPCs that don't really +fit into any specific subsystem. For example, a HW RAID controller is primarily +operated by the block layer but also comes with a set of RPCs to administer the +construction of drives within the HW RAID. + +In the past when devices were more single function, individual subsystems would +grow different approaches to solving some of these common problems. For instance +monitoring device health, manipulating its FLASH, debugging the FW, +provisioning, all have various unique interfaces across the kernel. + +fwctl's purpose is to define a common set of limited rules, described below, +that allow user space to securely construct and execute RPCs inside device FW. +The rules serve as an agreement between the operating system and FW on how to +correctly design the RPC interface. As a uAPI the subsystem provides a thin +layer of discovery and a generic uAPI to deliver the RPCs and collect the +response. It supports a system of user space libraries and tools which will +use this interface to control the device using the device native protocols. + +Scope of Action +--------------- + +fwctl drivers are strictly restricted to being a way to operate the device FW. +It is not an avenue to access random kernel internals, or other operating system +SW states. + +fwctl instances must operate on a well-defined device function, and the device +should have a well-defined security model for what scope within the physical +device the function is permitted to access. For instance, the most complex PCIe +device today may broadly have several function-level scopes: + + 1. A privileged function with full access to the on-device global state and + configuration + + 2. Multiple hypervisor functions with control over itself and child functions + used with VMs + + 3. Multiple VM functions tightly scoped within the VM + +The device may create a logical parent/child relationship between these scopes. +For instance a child VM's FW may be within the scope of the hypervisor FW. It is +quite common in the VFIO world that the hypervisor environment has a complex +provisioning/profiling/configuration responsibility for the function VFIO +assigns to the VM. + +Further, within the function, devices often have RPC commands that fall within +some general scopes of action (see enum fwctl_rpc_scope): + + 1. Access to function & child configuration, FLASH, etc. that becomes live at a + function reset. Access to function & child runtime configuration that is + transparent or non-disruptive to any driver or VM. + + 2. Read-only access to function debug information that may report on FW objects + in the function & child, including FW objects owned by other kernel + subsystems. + + 3. Write access to function & child debug information strictly compatible with + the principles of kernel lockdown and kernel integrity protection. Triggers + a kernel Taint. + + 4. Full debug device access. Triggers a kernel Taint, requires CAP_SYS_RAWIO. + +User space will provide a scope label on each RPC and the kernel must enforce the +above CAPs and taints based on that scope. A combination of kernel and FW can +enforce that RPCs are placed in the correct scope by user space. + +Denied behavior +--------------- + +There are many things this interface must not allow user space to do (without a +Taint or CAP), broadly derived from the principles of kernel lockdown. Some +examples: + + 1. DMA to/from arbitrary memory, hang the system, compromise FW integrity with + untrusted code, or otherwise compromise device or system security and + integrity. + + 2. Provide an abnormal “back door” to kernel drivers. No manipulation of kernel + objects owned by kernel drivers. + + 3. Directly configure or otherwise control kernel drivers. A subsystem kernel + driver can react to the device configuration at function reset/driver load + time, but otherwise must not be coupled to fwctl. + + 4. Operate the HW in a way that overlaps with the core purpose of another + primary kernel subsystem, such as read/write to LBAs, send/receive of + network packets, or operate an accelerator's data plane. + +fwctl is not a replacement for device direct access subsystems like uacce or +VFIO. + +Operations exposed through fwctl's non-taining interfaces should be fully +sharable with other users of the device. For instance exposing a RPC through +fwctl should never prevent a kernel subsystem from also concurrently using that +same RPC or hardware unit down the road. In such cases fwctl will be less +important than proper kernel subsystems that eventually emerge. Mistakes in this +area resulting in clashes will be resolved in favour of a kernel implementation. + +fwctl User API +============== + +.. kernel-doc:: include/uapi/fwctl/fwctl.h +.. kernel-doc:: include/uapi/fwctl/mlx5.h +.. kernel-doc:: include/uapi/fwctl/pds.h + +sysfs Class +----------- + +fwctl has a sysfs class (/sys/class/fwctl/fwctlNN/) and character devices +(/dev/fwctl/fwctlNN) with a simple numbered scheme. The character device +operates the iotcl uAPI described above. + +fwctl devices can be related to driver components in other subsystems through +sysfs:: + + $ ls /sys/class/fwctl/fwctl0/device/infiniband/ + ibp0s10f0 + + $ ls /sys/class/infiniband/ibp0s10f0/device/fwctl/ + fwctl0/ + + $ ls /sys/devices/pci0000:00/0000:00:0a.0/fwctl/fwctl0 + dev device power subsystem uevent + +User space Community +-------------------- + +Drawing inspiration from nvme-cli, participating in the kernel side must come +with a user space in a common TBD git tree, at a minimum to usefully operate the +kernel driver. Providing such an implementation is a pre-condition to merging a +kernel driver. + +The goal is to build user space community around some of the shared problems +we all have, and ideally develop some common user space programs with some +starting themes of: + + - Device in-field debugging + + - HW provisioning + + - VFIO child device profiling before VM boot + + - Confidential Compute topics (attestation, secure provisioning) + +that stretch across all subsystems in the kernel. fwupd is a great example of +how an excellent user space experience can emerge out of kernel-side diversity. + +fwctl Kernel API +================ + +.. kernel-doc:: drivers/fwctl/main.c + :export: +.. kernel-doc:: include/linux/fwctl.h + +fwctl Driver design +------------------- + +In many cases a fwctl driver is going to be part of a larger cross-subsystem +device possibly using the auxiliary_device mechanism. In that case several +subsystems are going to be sharing the same device and FW interface layer so the +device design must already provide for isolation and cooperation between kernel +subsystems. fwctl should fit into that same model. + +Part of the driver should include a description of how its scope restrictions +and security model work. The driver and FW together must ensure that RPCs +provided by user space are mapped to the appropriate scope. If the validation is +done in the driver then the validation can read a 'command effects' report from +the device, or hardwire the enforcement. If the validation is done in the FW, +then the driver should pass the fwctl_rpc_scope to the FW along with the command. + +The driver and FW must cooperate to ensure that either fwctl cannot allocate +any FW resources, or any resources it does allocate are freed on FD closure. A +driver primarily constructed around FW RPCs may find that its core PCI function +and RPC layer belongs under fwctl with auxiliary devices connecting to other +subsystems. + +Each device type must be mindful of Linux's philosophy for stable ABI. The FW +RPC interface does not have to meet a strictly stable ABI, but it does need to +meet an expectation that userspace tools that are deployed and in significant +use don't needlessly break. FW upgrade and kernel upgrade should keep widely +deployed tooling working. + +Development and debugging focused RPCs under more permissive scopes can have +less stabilitiy if the tools using them are only run under exceptional +circumstances and not for every day use of the device. Debugging tools may even +require exact version matching as they may require something similar to DWARF +debug information from the FW binary. + +Security Response +================= + +The kernel remains the gatekeeper for this interface. If violations of the +scopes, security or isolation principles are found, we have options to let +devices fix them with a FW update, push a kernel patch to parse and block RPC +commands or push a kernel patch to block entire firmware versions/devices. + +While the kernel can always directly parse and restrict RPCs, it is expected +that the existing kernel pattern of allowing drivers to delegate validation to +FW to be a useful design. + +Existing Similar Examples +========================= + +The approach described in this document is not a new idea. Direct, or near +direct device access has been offered by the kernel in different areas for +decades. With more devices wanting to follow this design pattern it is becoming +clear that it is not entirely well understood and, more importantly, the +security considerations are not well defined or agreed upon. + +Some examples: + + - HW RAID controllers. This includes RPCs to do things like compose drives into + a RAID volume, configure RAID parameters, monitor the HW and more. + + - Baseboard managers. RPCs for configuring settings in the device and more + + - NVMe vendor command capsules. nvme-cli provides access to some monitoring + functions that different products have defined, but more exist. + + - CXL also has a NVMe-like vendor command system. + + - DRM allows user space drivers to send commands to the device via kernel + mediation + + - RDMA allows user space drivers to directly push commands to the device + without kernel involvement + + - Various “raw” APIs, raw HID (SDL2), raw USB, NVMe Generic Interface, etc. + +The first 4 are examples of areas that fwctl intends to cover. The latter three +are examples of denied behavior as they fully overlap with the primary purpose +of a kernel subsystem. + +Some key lessons learned from these past efforts are the importance of having a +common user space project to use as a pre-condition for obtaining a kernel +driver. Developing good community around useful software in user space is key to +getting companies to fund participation to enable their products. diff --git a/Documentation/userspace-api/fwctl/index.rst b/Documentation/userspace-api/fwctl/index.rst new file mode 100644 index 000000000000..316ac456ad3b --- /dev/null +++ b/Documentation/userspace-api/fwctl/index.rst @@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Firmware Control (FWCTL) Userspace API +====================================== + +A framework that define a common set of limited rules that allows user space +to securely construct and execute RPCs inside device firmware. + +.. toctree:: + :maxdepth: 1 + + fwctl + fwctl-cxl + pds_fwctl diff --git a/Documentation/userspace-api/fwctl/pds_fwctl.rst b/Documentation/userspace-api/fwctl/pds_fwctl.rst new file mode 100644 index 000000000000..b5a31f82c883 --- /dev/null +++ b/Documentation/userspace-api/fwctl/pds_fwctl.rst @@ -0,0 +1,46 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================ +fwctl pds driver +================ + +:Author: Shannon Nelson + +Overview +======== + +The PDS Core device makes a fwctl service available through an +auxiliary_device named pds_core.fwctl.N. The pds_fwctl driver binds to +this device and registers itself with the fwctl subsystem. The resulting +userspace interface is used by an application that is a part of the +AMD Pensando software package for the Distributed Service Card (DSC). + +The pds_fwctl driver has little knowledge of the firmware's internals. +It only knows how to send commands through pds_core's message queue to the +firmware for fwctl requests. The set of fwctl operations available +depends on the firmware in the DSC, and the userspace application +version must match the firmware so that they can talk to each other. + +When a connection is created the pds_fwctl driver requests from the +firmware a list of firmware object endpoints, and for each endpoint the +driver requests a list of operations for that endpoint. + +Each operation description includes a firmware defined command attribute +that maps to the FWCTL scope levels. The driver translates those firmware +values into the FWCTL scope values which can then be used for filtering the +scoped user requests. + +pds_fwctl User API +================== + +Each RPC request includes the target endpoint and the operation id, and in +and out buffer lengths and pointers. The driver verifies the existence +of the requested endpoint and operations, then checks the request scope +against the required scope of the operation. The request is then put +together with the request data and sent through pds_core's message queue +to the firmware, and the results are returned to the caller. + +The RPC endpoints, operations, and buffer contents are defined by the +particular firmware package in the device, which varies across the +available product configurations. The details are available in the +specific product SDK documentation. diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst index 9cbe4390c872..b8c73be4fb11 100644 --- a/Documentation/userspace-api/index.rst +++ b/Documentation/userspace-api/index.rst @@ -46,6 +46,7 @@ Devices and I/O accelerators/ocxl dma-buf-heaps dma-buf-alloc-exchange + fwctl/index gpio/index iommufd media/index diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 949eadb1ca16..7a1409ecc238 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -333,6 +333,7 @@ Code Seq# Include File Comments 0x97 00-7F fs/ceph/ioctl.h Ceph file system 0x99 00-0F 537-Addinboard driver <mailto:buk@buks.ipn.de> +0x9A 00-0F include/uapi/fwctl/fwctl.h 0xA0 all linux/sdp/sdp.h Industrial Device Project <mailto:kenji@bitgate.com> 0xA1 0 linux/vtpm_proxy.h TPM Emulator Proxy Driver diff --git a/Documentation/userspace-api/iommufd.rst b/Documentation/userspace-api/iommufd.rst index 70289d6815d2..b0df15865dec 100644 --- a/Documentation/userspace-api/iommufd.rst +++ b/Documentation/userspace-api/iommufd.rst @@ -63,6 +63,13 @@ Following IOMMUFD objects are exposed to userspace: space usually has mappings from guest-level I/O virtual addresses to guest- level physical addresses. +- IOMMUFD_FAULT, representing a software queue for an HWPT reporting IO page + faults using the IOMMU HW's PRI (Page Request Interface). This queue object + provides user space an FD to poll the page fault events and also to respond + to those events. A FAULT object must be created first to get a fault_id that + could be then used to allocate a fault-enabled HWPT via the IOMMU_HWPT_ALLOC + command by setting the IOMMU_HWPT_FAULT_ID_VALID bit in its flags field. + - IOMMUFD_OBJ_VIOMMU, representing a slice of the physical IOMMU instance, passed to or shared with a VM. It may be some HW-accelerated virtualization features and some SW resources used by the VM. For examples: @@ -109,6 +116,14 @@ Following IOMMUFD objects are exposed to userspace: vIOMMU, which is a separate ioctl call from attaching the same device to an HWPT_PAGING that the vIOMMU holds. +- IOMMUFD_OBJ_VEVENTQ, representing a software queue for a vIOMMU to report its + events such as translation faults occurred to a nested stage-1 (excluding I/O + page faults that should go through IOMMUFD_OBJ_FAULT) and HW-specific events. + This queue object provides user space an FD to poll/read the vIOMMU events. A + vIOMMU object must be created first to get its viommu_id, which could be then + used to allocate a vEVENTQ. Each vIOMMU can support multiple types of vEVENTS, + but is confined to one vEVENTQ per vEVENTQ type. + All user-visible objects are destroyed via the IOMMU_DESTROY uAPI. The diagrams below show relationships between user-visible objects and kernel @@ -251,8 +266,10 @@ User visible objects are backed by following datastructures: - iommufd_device for IOMMUFD_OBJ_DEVICE. - iommufd_hwpt_paging for IOMMUFD_OBJ_HWPT_PAGING. - iommufd_hwpt_nested for IOMMUFD_OBJ_HWPT_NESTED. +- iommufd_fault for IOMMUFD_OBJ_FAULT. - iommufd_viommu for IOMMUFD_OBJ_VIOMMU. - iommufd_vdevice for IOMMUFD_OBJ_VDEVICE. +- iommufd_veventq for IOMMUFD_OBJ_VEVENTQ. Several terminologies when looking at these datastructures: diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst index ad587f53fe41..1d0c2c15c22e 100644 --- a/Documentation/userspace-api/landlock.rst +++ b/Documentation/userspace-api/landlock.rst @@ -8,7 +8,7 @@ Landlock: unprivileged access control ===================================== :Author: Mickaël Salaün -:Date: January 2025 +:Date: March 2025 The goal of Landlock is to enable restriction of ambient rights (e.g. global filesystem or network access) for a set of processes. Because Landlock @@ -317,33 +317,32 @@ IPC scoping ----------- Similar to the implicit `Ptrace restrictions`_, we may want to further restrict -interactions between sandboxes. Each Landlock domain can be explicitly scoped -for a set of actions by specifying it on a ruleset. For example, if a -sandboxed process should not be able to :manpage:`connect(2)` to a -non-sandboxed process through abstract :manpage:`unix(7)` sockets, we can -specify such a restriction with ``LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET``. -Moreover, if a sandboxed process should not be able to send a signal to a -non-sandboxed process, we can specify this restriction with -``LANDLOCK_SCOPE_SIGNAL``. - -A sandboxed process can connect to a non-sandboxed process when its domain is -not scoped. If a process's domain is scoped, it can only connect to sockets -created by processes in the same scope. -Moreover, if a process is scoped to send signal to a non-scoped process, it can -only send signals to processes in the same scope. - -A connected datagram socket behaves like a stream socket when its domain is -scoped, meaning if the domain is scoped after the socket is connected, it can -still :manpage:`send(2)` data just like a stream socket. However, in the same -scenario, a non-connected datagram socket cannot send data (with -:manpage:`sendto(2)`) outside its scope. - -A process with a scoped domain can inherit a socket created by a non-scoped -process. The process cannot connect to this socket since it has a scoped -domain. - -IPC scoping does not support exceptions, so if a domain is scoped, no rules can -be added to allow access to resources or processes outside of the scope. +interactions between sandboxes. Therefore, at ruleset creation time, each +Landlock domain can restrict the scope for certain operations, so that these +operations can only reach out to processes within the same Landlock domain or in +a nested Landlock domain (the "scope"). + +The operations which can be scoped are: + +``LANDLOCK_SCOPE_SIGNAL`` + This limits the sending of signals to target processes which run within the + same or a nested Landlock domain. + +``LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET`` + This limits the set of abstract :manpage:`unix(7)` sockets to which we can + :manpage:`connect(2)` to socket addresses which were created by a process in + the same or a nested Landlock domain. + + A :manpage:`sendto(2)` on a non-connected datagram socket is treated as if + it were doing an implicit :manpage:`connect(2)` and will be blocked if the + remote end does not stem from the same or a nested Landlock domain. + + A :manpage:`sendto(2)` on a socket which was previously connected will not + be restricted. This works for both datagram and stream sockets. + +IPC scoping does not support exceptions via :manpage:`landlock_add_rule(2)`. +If an operation is scoped within a domain, no rules can be added to allow access +to resources or processes outside of the scope. Truncating files ---------------- @@ -595,6 +594,16 @@ Starting with the Landlock ABI version 6, it is possible to restrict :manpage:`signal(7)` sending by setting ``LANDLOCK_SCOPE_SIGNAL`` to the ``scoped`` ruleset attribute. +Logging (ABI < 7) +----------------- + +Starting with the Landlock ABI version 7, it is possible to control logging of +Landlock audit events with the ``LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF``, +``LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON``, and +``LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF`` flags passed to +sys_landlock_restrict_self(). See Documentation/admin-guide/LSM/landlock.rst +for more details on audit. + .. _kernel_support: Kernel support @@ -683,9 +692,16 @@ fine-grained restrictions). Moreover, their complexity can lead to security issues, especially when untrusted processes can manipulate them (cf. `Controlling access to user namespaces <https://lwn.net/Articles/673597/>`_). +How to disable Landlock audit records? +-------------------------------------- + +You might want to put in place filters as explained here: +Documentation/admin-guide/LSM/landlock.rst + Additional documentation ======================== +* Documentation/admin-guide/LSM/landlock.rst * Documentation/security/landlock.rst * https://landlock.io diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst index 41102f74c5e2..1dabfc29be0d 100644 --- a/Documentation/userspace-api/mseal.rst +++ b/Documentation/userspace-api/mseal.rst @@ -130,6 +130,27 @@ Use cases - Chrome browser: protect some security sensitive data structures. +- System mappings: + The system mappings are created by the kernel and includes vdso, vvar, + vvar_vclock, vectors (arm compat-mode), sigpage (arm compat-mode), uprobes. + + Those system mappings are readonly only or execute only, memory sealing can + protect them from ever changing to writable or unmmap/remapped as different + attributes. This is useful to mitigate memory corruption issues where a + corrupted pointer is passed to a memory management system. + + If supported by an architecture (CONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS), + the CONFIG_MSEAL_SYSTEM_MAPPINGS seals all system mappings of this + architecture. + + The following architectures currently support this feature: x86-64, arm64, + and s390. + + WARNING: This feature breaks programs which rely on relocating + or unmapping system mappings. Known broken software at the time + of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore + this config can't be enabled universally. + When not to use mseal ===================== Applications can apply sealing to any virtual memory region from userspace, diff --git a/Documentation/userspace-api/perf_ring_buffer.rst b/Documentation/userspace-api/perf_ring_buffer.rst index bde9d8cbc106..dc71544532ce 100644 --- a/Documentation/userspace-api/perf_ring_buffer.rst +++ b/Documentation/userspace-api/perf_ring_buffer.rst @@ -627,7 +627,7 @@ regular ring buffer. AUX events and AUX trace data are two different things. Let's see an example:: - perf record -a -e cycles -e cs_etm/@tmc_etr0/ -- sleep 2 + perf record -a -e cycles -e cs_etm// -- sleep 2 The above command enables two events: one is the event *cycles* from PMU and another is the AUX event *cs_etm* from Arm CoreSight, both are saved @@ -766,7 +766,7 @@ only record AUX trace data at a specific time point which users are interested in. E.g. below gives an example of how to take snapshots with 1 second interval with Arm CoreSight:: - perf record -e cs_etm/@tmc_etr0/u -S -a program & + perf record -e cs_etm//u -S -a program & PERFPID=$! while true; do kill -USR2 $PERFPID diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 1f8625b7646a..47c7c3f92314 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7447,6 +7447,75 @@ Unused bitfields in the bitarrays must be set to zero. This capability connects the vcpu to an in-kernel XIVE device. +6.76 KVM_CAP_HYPERV_SYNIC +------------------------- + +:Architectures: x86 +:Target: vcpu + +This capability, if KVM_CHECK_EXTENSION indicates that it is +available, means that the kernel has an implementation of the +Hyper-V Synthetic interrupt controller(SynIC). Hyper-V SynIC is +used to support Windows Hyper-V based guest paravirt drivers(VMBus). + +In order to use SynIC, it has to be activated by setting this +capability via KVM_ENABLE_CAP ioctl on the vcpu fd. Note that this +will disable the use of APIC hardware virtualization even if supported +by the CPU, as it's incompatible with SynIC auto-EOI behavior. + +6.77 KVM_CAP_HYPERV_SYNIC2 +-------------------------- + +:Architectures: x86 +:Target: vcpu + +This capability enables a newer version of Hyper-V Synthetic interrupt +controller (SynIC). The only difference with KVM_CAP_HYPERV_SYNIC is that KVM +doesn't clear SynIC message and event flags pages when they are enabled by +writing to the respective MSRs. + +6.78 KVM_CAP_HYPERV_DIRECT_TLBFLUSH +----------------------------------- + +:Architectures: x86 +:Target: vcpu + +This capability indicates that KVM running on top of Hyper-V hypervisor +enables Direct TLB flush for its guests meaning that TLB flush +hypercalls are handled by Level 0 hypervisor (Hyper-V) bypassing KVM. +Due to the different ABI for hypercall parameters between Hyper-V and +KVM, enabling this capability effectively disables all hypercall +handling by KVM (as some KVM hypercall may be mistakenly treated as TLB +flush hypercalls by Hyper-V) so userspace should disable KVM identification +in CPUID and only exposes Hyper-V identification. In this case, guest +thinks it's running on Hyper-V and only use Hyper-V hypercalls. + +6.79 KVM_CAP_HYPERV_ENFORCE_CPUID +--------------------------------- + +:Architectures: x86 +:Target: vcpu + +When enabled, KVM will disable emulated Hyper-V features provided to the +guest according to the bits Hyper-V CPUID feature leaves. Otherwise, all +currently implemented Hyper-V features are provided unconditionally when +Hyper-V identification is set in the HYPERV_CPUID_INTERFACE (0x40000001) +leaf. + +6.80 KVM_CAP_ENFORCE_PV_FEATURE_CPUID +------------------------------------- + +:Architectures: x86 +:Target: vcpu + +When enabled, KVM will disable paravirtual features provided to the +guest according to the bits in the KVM_CPUID_FEATURES CPUID leaf +(0x40000001). Otherwise, a guest may use the paravirtual features +regardless of what has actually been exposed through the CPUID leaf. + +.. _KVM_CAP_DIRTY_LOG_RING: + + .. _cap_enable_vm: 7. Capabilities that can be enabled on VMs @@ -7927,10 +7996,10 @@ by POWER10 processor. 7.24 KVM_CAP_VM_COPY_ENC_CONTEXT_FROM ------------------------------------- -Architectures: x86 SEV enabled -Type: vm -Parameters: args[0] is the fd of the source vm -Returns: 0 on success; ENOTTY on error +:Architectures: x86 SEV enabled +:Type: vm +:Parameters: args[0] is the fd of the source vm +:Returns: 0 on success; ENOTTY on error This capability enables userspace to copy encryption context from the vm indicated by the fd to the vm this is called on. @@ -7963,24 +8032,6 @@ default. See Documentation/arch/x86/sgx.rst for more details. -7.26 KVM_CAP_PPC_RPT_INVALIDATE -------------------------------- - -:Capability: KVM_CAP_PPC_RPT_INVALIDATE -:Architectures: ppc -:Type: vm - -This capability indicates that the kernel is capable of handling -H_RPT_INVALIDATE hcall. - -In order to enable the use of H_RPT_INVALIDATE in the guest, -user space might have to advertise it for the guest. For example, -IBM pSeries (sPAPR) guest starts using it if "hcall-rpt-invalidate" is -present in the "ibm,hypertas-functions" device-tree property. - -This capability is enabled for hypervisors on platforms like POWER9 -that support radix MMU. - 7.27 KVM_CAP_EXIT_ON_EMULATION_FAILURE -------------------------------------- @@ -8038,24 +8089,9 @@ indicated by the fd to the VM this is called on. This is intended to support intra-host migration of VMs between userspace VMMs, upgrading the VMM process without interrupting the guest. -7.30 KVM_CAP_PPC_AIL_MODE_3 -------------------------------- - -:Capability: KVM_CAP_PPC_AIL_MODE_3 -:Architectures: ppc -:Type: vm - -This capability indicates that the kernel supports the mode 3 setting for the -"Address Translation Mode on Interrupt" aka "Alternate Interrupt Location" -resource that is controlled with the H_SET_MODE hypercall. - -This capability allows a guest kernel to use a better-performance mode for -handling interrupts and system calls. - 7.31 KVM_CAP_DISABLE_QUIRKS2 ---------------------------- -:Capability: KVM_CAP_DISABLE_QUIRKS2 :Parameters: args[0] - set of KVM quirks to disable :Architectures: x86 :Type: vm @@ -8210,27 +8246,6 @@ This capability is aimed to mitigate the threat that malicious VMs can cause CPU stuck (due to event windows don't open up) and make the CPU unavailable to host or other VMs. -7.34 KVM_CAP_MEMORY_FAULT_INFO ------------------------------- - -:Architectures: x86 -:Returns: Informational only, -EINVAL on direct KVM_ENABLE_CAP. - -The presence of this capability indicates that KVM_RUN will fill -kvm_run.memory_fault if KVM cannot resolve a guest page fault VM-Exit, e.g. if -there is a valid memslot but no backing VMA for the corresponding host virtual -address. - -The information in kvm_run.memory_fault is valid if and only if KVM_RUN returns -an error with errno=EFAULT or errno=EHWPOISON *and* kvm_run.exit_reason is set -to KVM_EXIT_MEMORY_FAULT. - -Note: Userspaces which attempt to resolve memory faults so that they can retry -KVM_RUN are encouraged to guard against repeatedly receiving the same -error/annotated fault. - -See KVM_EXIT_MEMORY_FAULT for more information. - 7.35 KVM_CAP_X86_APIC_BUS_CYCLES_NS ----------------------------------- @@ -8248,19 +8263,220 @@ by KVM_CHECK_EXTENSION. Note: Userspace is responsible for correctly configuring CPUID 0x15, a.k.a. the core crystal clock frequency, if a non-zero CPUID 0x15 is exposed to the guest. -7.36 KVM_CAP_X86_GUEST_MODE ------------------------------- +7.36 KVM_CAP_DIRTY_LOG_RING/KVM_CAP_DIRTY_LOG_RING_ACQ_REL +---------------------------------------------------------- + +:Architectures: x86, arm64 +:Type: vm +:Parameters: args[0] - size of the dirty log ring + +KVM is capable of tracking dirty memory using ring buffers that are +mmapped into userspace; there is one dirty ring per vcpu. + +The dirty ring is available to userspace as an array of +``struct kvm_dirty_gfn``. Each dirty entry is defined as:: + + struct kvm_dirty_gfn { + __u32 flags; + __u32 slot; /* as_id | slot_id */ + __u64 offset; + }; + +The following values are defined for the flags field to define the +current state of the entry:: + + #define KVM_DIRTY_GFN_F_DIRTY BIT(0) + #define KVM_DIRTY_GFN_F_RESET BIT(1) + #define KVM_DIRTY_GFN_F_MASK 0x3 + +Userspace should call KVM_ENABLE_CAP ioctl right after KVM_CREATE_VM +ioctl to enable this capability for the new guest and set the size of +the rings. Enabling the capability is only allowed before creating any +vCPU, and the size of the ring must be a power of two. The larger the +ring buffer, the less likely the ring is full and the VM is forced to +exit to userspace. The optimal size depends on the workload, but it is +recommended that it be at least 64 KiB (4096 entries). + +Just like for dirty page bitmaps, the buffer tracks writes to +all user memory regions for which the KVM_MEM_LOG_DIRTY_PAGES flag was +set in KVM_SET_USER_MEMORY_REGION. Once a memory region is registered +with the flag set, userspace can start harvesting dirty pages from the +ring buffer. + +An entry in the ring buffer can be unused (flag bits ``00``), +dirty (flag bits ``01``) or harvested (flag bits ``1X``). The +state machine for the entry is as follows:: + + dirtied harvested reset + 00 -----------> 01 -------------> 1X -------+ + ^ | + | | + +------------------------------------------+ + +To harvest the dirty pages, userspace accesses the mmapped ring buffer +to read the dirty GFNs. If the flags has the DIRTY bit set (at this stage +the RESET bit must be cleared), then it means this GFN is a dirty GFN. +The userspace should harvest this GFN and mark the flags from state +``01b`` to ``1Xb`` (bit 0 will be ignored by KVM, but bit 1 must be set +to show that this GFN is harvested and waiting for a reset), and move +on to the next GFN. The userspace should continue to do this until the +flags of a GFN have the DIRTY bit cleared, meaning that it has harvested +all the dirty GFNs that were available. + +Note that on weakly ordered architectures, userspace accesses to the +ring buffer (and more specifically the 'flags' field) must be ordered, +using load-acquire/store-release accessors when available, or any +other memory barrier that will ensure this ordering. + +It's not necessary for userspace to harvest the all dirty GFNs at once. +However it must collect the dirty GFNs in sequence, i.e., the userspace +program cannot skip one dirty GFN to collect the one next to it. + +After processing one or more entries in the ring buffer, userspace +calls the VM ioctl KVM_RESET_DIRTY_RINGS to notify the kernel about +it, so that the kernel will reprotect those collected GFNs. +Therefore, the ioctl must be called *before* reading the content of +the dirty pages. + +The dirty ring can get full. When it happens, the KVM_RUN of the +vcpu will return with exit reason KVM_EXIT_DIRTY_LOG_FULL. + +The dirty ring interface has a major difference comparing to the +KVM_GET_DIRTY_LOG interface in that, when reading the dirty ring from +userspace, it's still possible that the kernel has not yet flushed the +processor's dirty page buffers into the kernel buffer (with dirty bitmaps, the +flushing is done by the KVM_GET_DIRTY_LOG ioctl). To achieve that, one +needs to kick the vcpu out of KVM_RUN using a signal. The resulting +vmexit ensures that all dirty GFNs are flushed to the dirty rings. + +NOTE: KVM_CAP_DIRTY_LOG_RING_ACQ_REL is the only capability that +should be exposed by weakly ordered architecture, in order to indicate +the additional memory ordering requirements imposed on userspace when +reading the state of an entry and mutating it from DIRTY to HARVESTED. +Architecture with TSO-like ordering (such as x86) are allowed to +expose both KVM_CAP_DIRTY_LOG_RING and KVM_CAP_DIRTY_LOG_RING_ACQ_REL +to userspace. + +After enabling the dirty rings, the userspace needs to detect the +capability of KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP to see whether the +ring structures can be backed by per-slot bitmaps. With this capability +advertised, it means the architecture can dirty guest pages without +vcpu/ring context, so that some of the dirty information will still be +maintained in the bitmap structure. KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP +can't be enabled if the capability of KVM_CAP_DIRTY_LOG_RING_ACQ_REL +hasn't been enabled, or any memslot has been existing. + +Note that the bitmap here is only a backup of the ring structure. The +use of the ring and bitmap combination is only beneficial if there is +only a very small amount of memory that is dirtied out of vcpu/ring +context. Otherwise, the stand-alone per-slot bitmap mechanism needs to +be considered. + +To collect dirty bits in the backup bitmap, userspace can use the same +KVM_GET_DIRTY_LOG ioctl. KVM_CLEAR_DIRTY_LOG isn't needed as long as all +the generation of the dirty bits is done in a single pass. Collecting +the dirty bitmap should be the very last thing that the VMM does before +considering the state as complete. VMM needs to ensure that the dirty +state is final and avoid missing dirty pages from another ioctl ordered +after the bitmap collection. + +NOTE: Multiple examples of using the backup bitmap: (1) save vgic/its +tables through command KVM_DEV_ARM_{VGIC_GRP_CTRL, ITS_SAVE_TABLES} on +KVM device "kvm-arm-vgic-its". (2) restore vgic/its tables through +command KVM_DEV_ARM_{VGIC_GRP_CTRL, ITS_RESTORE_TABLES} on KVM device +"kvm-arm-vgic-its". VGICv3 LPI pending status is restored. (3) save +vgic3 pending table through KVM_DEV_ARM_VGIC_{GRP_CTRL, SAVE_PENDING_TABLES} +command on KVM device "kvm-arm-vgic-v3". + +7.37 KVM_CAP_PMU_CAPABILITY +--------------------------- :Architectures: x86 -:Returns: Informational only, -EINVAL on direct KVM_ENABLE_CAP. +:Type: vm +:Parameters: arg[0] is bitmask of PMU virtualization capabilities. +:Returns: 0 on success, -EINVAL when arg[0] contains invalid bits -The presence of this capability indicates that KVM_RUN will update the -KVM_RUN_X86_GUEST_MODE bit in kvm_run.flags to indicate whether the -vCPU was executing nested guest code when it exited. +This capability alters PMU virtualization in KVM. -KVM exits with the register state of either the L1 or L2 guest -depending on which executed at the time of an exit. Userspace must -take care to differentiate between these cases. +Calling KVM_CHECK_EXTENSION for this capability returns a bitmask of +PMU virtualization capabilities that can be adjusted on a VM. + +The argument to KVM_ENABLE_CAP is also a bitmask and selects specific +PMU virtualization capabilities to be applied to the VM. This can +only be invoked on a VM prior to the creation of VCPUs. + +At this time, KVM_PMU_CAP_DISABLE is the only capability. Setting +this capability will disable PMU virtualization for that VM. Usermode +should adjust CPUID leaf 0xA to reflect that the PMU is disabled. + +7.38 KVM_CAP_VM_DISABLE_NX_HUGE_PAGES +------------------------------------- + +:Architectures: x86 +:Type: vm +:Parameters: arg[0] must be 0. +:Returns: 0 on success, -EPERM if the userspace process does not + have CAP_SYS_BOOT, -EINVAL if args[0] is not 0 or any vCPUs have been + created. + +This capability disables the NX huge pages mitigation for iTLB MULTIHIT. + +The capability has no effect if the nx_huge_pages module parameter is not set. + +This capability may only be set before any vCPUs are created. + +7.39 KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE +--------------------------------------- + +:Architectures: arm64 +:Type: vm +:Parameters: arg[0] is the new split chunk size. +:Returns: 0 on success, -EINVAL if any memslot was already created. + +This capability sets the chunk size used in Eager Page Splitting. + +Eager Page Splitting improves the performance of dirty-logging (used +in live migrations) when guest memory is backed by huge-pages. It +avoids splitting huge-pages (into PAGE_SIZE pages) on fault, by doing +it eagerly when enabling dirty logging (with the +KVM_MEM_LOG_DIRTY_PAGES flag for a memory region), or when using +KVM_CLEAR_DIRTY_LOG. + +The chunk size specifies how many pages to break at a time, using a +single allocation for each chunk. Bigger the chunk size, more pages +need to be allocated ahead of time. + +The chunk size needs to be a valid block size. The list of acceptable +block sizes is exposed in KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES as a +64-bit bitmap (each bit describing a block size). The default value is +0, to disable the eager page splitting. + +7.40 KVM_CAP_EXIT_HYPERCALL +--------------------------- + +:Architectures: x86 +:Type: vm + +This capability, if enabled, will cause KVM to exit to userspace +with KVM_EXIT_HYPERCALL exit reason to process some hypercalls. + +Calling KVM_CHECK_EXTENSION for this capability will return a bitmask +of hypercalls that can be configured to exit to userspace. +Right now, the only such hypercall is KVM_HC_MAP_GPA_RANGE. + +The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset +of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace +the hypercalls whose corresponding bit is in the argument, and return +ENOSYS for the others. + +7.41 KVM_CAP_ARM_SYSTEM_SUSPEND +------------------------------- + +:Architectures: arm64 +:Type: vm + +When enabled, KVM will exit to userspace with KVM_EXIT_SYSTEM_EVENT of +type KVM_SYSTEM_EVENT_SUSPEND to process the guest suspend request. 7.37 KVM_CAP_ARM_WRITABLE_IMP_ID_REGS ------------------------------------- @@ -8297,21 +8513,6 @@ H_RANDOM hypercall backed by a hardware random-number generator. If present, the kernel H_RANDOM handler can be enabled for guest use with the KVM_CAP_PPC_ENABLE_HCALL capability. -8.2 KVM_CAP_HYPERV_SYNIC ------------------------- - -:Architectures: x86 - -This capability, if KVM_CHECK_EXTENSION indicates that it is -available, means that the kernel has an implementation of the -Hyper-V Synthetic interrupt controller(SynIC). Hyper-V SynIC is -used to support Windows Hyper-V based guest paravirt drivers(VMBus). - -In order to use SynIC, it has to be activated by setting this -capability via KVM_ENABLE_CAP ioctl on the vcpu fd. Note that this -will disable the use of APIC hardware virtualization even if supported -by the CPU, as it's incompatible with SynIC auto-EOI behavior. - 8.3 KVM_CAP_PPC_MMU_RADIX ------------------------- @@ -8362,20 +8563,6 @@ may be incompatible with the MIPS VZ ASE. virtualization, including standard guest virtual memory segments. == ========================================================================== -8.6 KVM_CAP_MIPS_TE -------------------- - -:Architectures: mips - -This capability, if KVM_CHECK_EXTENSION on the main kvm handle indicates that -it is available, means that the trap & emulate implementation is available to -run guest code in user mode, even if KVM_CAP_MIPS_VZ indicates that hardware -assisted virtualisation is also available. KVM_VM_MIPS_TE (0) must be passed -to KVM_CREATE_VM to create a VM which utilises it. - -If KVM_CHECK_EXTENSION on a kvm VM handle indicates that this capability is -available, it means that the VM is using trap & emulate. - 8.7 KVM_CAP_MIPS_64BIT ---------------------- @@ -8457,16 +8644,6 @@ virtual SMT modes that can be set using KVM_CAP_PPC_SMT. If bit N (counting from the right) is set, then a virtual SMT mode of 2^N is available. -8.11 KVM_CAP_HYPERV_SYNIC2 --------------------------- - -:Architectures: x86 - -This capability enables a newer version of Hyper-V Synthetic interrupt -controller (SynIC). The only difference with KVM_CAP_HYPERV_SYNIC is that KVM -doesn't clear SynIC message and event flags pages when they are enabled by -writing to the respective MSRs. - 8.12 KVM_CAP_HYPERV_VP_INDEX ---------------------------- @@ -8481,7 +8658,6 @@ capability is absent, userspace can still query this msr's value. ------------------------------- :Architectures: s390 -:Parameters: none This capability indicates if the flic device will be able to get/set the AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows @@ -8555,21 +8731,6 @@ This capability indicates that KVM supports paravirtualized Hyper-V IPI send hypercalls: HvCallSendSyntheticClusterIpi, HvCallSendSyntheticClusterIpiEx. -8.21 KVM_CAP_HYPERV_DIRECT_TLBFLUSH ------------------------------------ - -:Architectures: x86 - -This capability indicates that KVM running on top of Hyper-V hypervisor -enables Direct TLB flush for its guests meaning that TLB flush -hypercalls are handled by Level 0 hypervisor (Hyper-V) bypassing KVM. -Due to the different ABI for hypercall parameters between Hyper-V and -KVM, enabling this capability effectively disables all hypercall -handling by KVM (as some KVM hypercall may be mistakenly treated as TLB -flush hypercalls by Hyper-V) so userspace should disable KVM identification -in CPUID and only exposes Hyper-V identification. In this case, guest -thinks it's running on Hyper-V and only use Hyper-V hypercalls. - 8.22 KVM_CAP_S390_VCPU_RESETS ----------------------------- @@ -8647,142 +8808,6 @@ In combination with KVM_CAP_X86_USER_SPACE_MSR, this allows user space to trap and emulate MSRs that are outside of the scope of KVM as well as limit the attack surface on KVM's MSR emulation code. -8.28 KVM_CAP_ENFORCE_PV_FEATURE_CPUID -------------------------------------- - -Architectures: x86 - -When enabled, KVM will disable paravirtual features provided to the -guest according to the bits in the KVM_CPUID_FEATURES CPUID leaf -(0x40000001). Otherwise, a guest may use the paravirtual features -regardless of what has actually been exposed through the CPUID leaf. - -.. _KVM_CAP_DIRTY_LOG_RING: - -8.29 KVM_CAP_DIRTY_LOG_RING/KVM_CAP_DIRTY_LOG_RING_ACQ_REL ----------------------------------------------------------- - -:Architectures: x86, arm64 -:Parameters: args[0] - size of the dirty log ring - -KVM is capable of tracking dirty memory using ring buffers that are -mmapped into userspace; there is one dirty ring per vcpu. - -The dirty ring is available to userspace as an array of -``struct kvm_dirty_gfn``. Each dirty entry is defined as:: - - struct kvm_dirty_gfn { - __u32 flags; - __u32 slot; /* as_id | slot_id */ - __u64 offset; - }; - -The following values are defined for the flags field to define the -current state of the entry:: - - #define KVM_DIRTY_GFN_F_DIRTY BIT(0) - #define KVM_DIRTY_GFN_F_RESET BIT(1) - #define KVM_DIRTY_GFN_F_MASK 0x3 - -Userspace should call KVM_ENABLE_CAP ioctl right after KVM_CREATE_VM -ioctl to enable this capability for the new guest and set the size of -the rings. Enabling the capability is only allowed before creating any -vCPU, and the size of the ring must be a power of two. The larger the -ring buffer, the less likely the ring is full and the VM is forced to -exit to userspace. The optimal size depends on the workload, but it is -recommended that it be at least 64 KiB (4096 entries). - -Just like for dirty page bitmaps, the buffer tracks writes to -all user memory regions for which the KVM_MEM_LOG_DIRTY_PAGES flag was -set in KVM_SET_USER_MEMORY_REGION. Once a memory region is registered -with the flag set, userspace can start harvesting dirty pages from the -ring buffer. - -An entry in the ring buffer can be unused (flag bits ``00``), -dirty (flag bits ``01``) or harvested (flag bits ``1X``). The -state machine for the entry is as follows:: - - dirtied harvested reset - 00 -----------> 01 -------------> 1X -------+ - ^ | - | | - +------------------------------------------+ - -To harvest the dirty pages, userspace accesses the mmapped ring buffer -to read the dirty GFNs. If the flags has the DIRTY bit set (at this stage -the RESET bit must be cleared), then it means this GFN is a dirty GFN. -The userspace should harvest this GFN and mark the flags from state -``01b`` to ``1Xb`` (bit 0 will be ignored by KVM, but bit 1 must be set -to show that this GFN is harvested and waiting for a reset), and move -on to the next GFN. The userspace should continue to do this until the -flags of a GFN have the DIRTY bit cleared, meaning that it has harvested -all the dirty GFNs that were available. - -Note that on weakly ordered architectures, userspace accesses to the -ring buffer (and more specifically the 'flags' field) must be ordered, -using load-acquire/store-release accessors when available, or any -other memory barrier that will ensure this ordering. - -It's not necessary for userspace to harvest the all dirty GFNs at once. -However it must collect the dirty GFNs in sequence, i.e., the userspace -program cannot skip one dirty GFN to collect the one next to it. - -After processing one or more entries in the ring buffer, userspace -calls the VM ioctl KVM_RESET_DIRTY_RINGS to notify the kernel about -it, so that the kernel will reprotect those collected GFNs. -Therefore, the ioctl must be called *before* reading the content of -the dirty pages. - -The dirty ring can get full. When it happens, the KVM_RUN of the -vcpu will return with exit reason KVM_EXIT_DIRTY_LOG_FULL. - -The dirty ring interface has a major difference comparing to the -KVM_GET_DIRTY_LOG interface in that, when reading the dirty ring from -userspace, it's still possible that the kernel has not yet flushed the -processor's dirty page buffers into the kernel buffer (with dirty bitmaps, the -flushing is done by the KVM_GET_DIRTY_LOG ioctl). To achieve that, one -needs to kick the vcpu out of KVM_RUN using a signal. The resulting -vmexit ensures that all dirty GFNs are flushed to the dirty rings. - -NOTE: KVM_CAP_DIRTY_LOG_RING_ACQ_REL is the only capability that -should be exposed by weakly ordered architecture, in order to indicate -the additional memory ordering requirements imposed on userspace when -reading the state of an entry and mutating it from DIRTY to HARVESTED. -Architecture with TSO-like ordering (such as x86) are allowed to -expose both KVM_CAP_DIRTY_LOG_RING and KVM_CAP_DIRTY_LOG_RING_ACQ_REL -to userspace. - -After enabling the dirty rings, the userspace needs to detect the -capability of KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP to see whether the -ring structures can be backed by per-slot bitmaps. With this capability -advertised, it means the architecture can dirty guest pages without -vcpu/ring context, so that some of the dirty information will still be -maintained in the bitmap structure. KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP -can't be enabled if the capability of KVM_CAP_DIRTY_LOG_RING_ACQ_REL -hasn't been enabled, or any memslot has been existing. - -Note that the bitmap here is only a backup of the ring structure. The -use of the ring and bitmap combination is only beneficial if there is -only a very small amount of memory that is dirtied out of vcpu/ring -context. Otherwise, the stand-alone per-slot bitmap mechanism needs to -be considered. - -To collect dirty bits in the backup bitmap, userspace can use the same -KVM_GET_DIRTY_LOG ioctl. KVM_CLEAR_DIRTY_LOG isn't needed as long as all -the generation of the dirty bits is done in a single pass. Collecting -the dirty bitmap should be the very last thing that the VMM does before -considering the state as complete. VMM needs to ensure that the dirty -state is final and avoid missing dirty pages from another ioctl ordered -after the bitmap collection. - -NOTE: Multiple examples of using the backup bitmap: (1) save vgic/its -tables through command KVM_DEV_ARM_{VGIC_GRP_CTRL, ITS_SAVE_TABLES} on -KVM device "kvm-arm-vgic-its". (2) restore vgic/its tables through -command KVM_DEV_ARM_{VGIC_GRP_CTRL, ITS_RESTORE_TABLES} on KVM device -"kvm-arm-vgic-its". VGICv3 LPI pending status is restored. (3) save -vgic3 pending table through KVM_DEV_ARM_VGIC_{GRP_CTRL, SAVE_PENDING_TABLES} -command on KVM device "kvm-arm-vgic-v3". - 8.30 KVM_CAP_XEN_HVM -------------------- @@ -8847,10 +8872,9 @@ clearing the PVCLOCK_TSC_STABLE_BIT flag in Xen pvclock sources. This will be done when the KVM_CAP_XEN_HVM ioctl sets the KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE flag. -8.31 KVM_CAP_PPC_MULTITCE -------------------------- +8.31 KVM_CAP_SPAPR_MULTITCE +--------------------------- -:Capability: KVM_CAP_PPC_MULTITCE :Architectures: ppc :Type: vm @@ -8882,72 +8906,9 @@ This capability indicates that the KVM virtual PTP service is supported in the host. A VMM can check whether the service is available to the guest on migration. -8.33 KVM_CAP_HYPERV_ENFORCE_CPUID ---------------------------------- - -Architectures: x86 - -When enabled, KVM will disable emulated Hyper-V features provided to the -guest according to the bits Hyper-V CPUID feature leaves. Otherwise, all -currently implemented Hyper-V features are provided unconditionally when -Hyper-V identification is set in the HYPERV_CPUID_INTERFACE (0x40000001) -leaf. - -8.34 KVM_CAP_EXIT_HYPERCALL ---------------------------- - -:Capability: KVM_CAP_EXIT_HYPERCALL -:Architectures: x86 -:Type: vm - -This capability, if enabled, will cause KVM to exit to userspace -with KVM_EXIT_HYPERCALL exit reason to process some hypercalls. - -Calling KVM_CHECK_EXTENSION for this capability will return a bitmask -of hypercalls that can be configured to exit to userspace. -Right now, the only such hypercall is KVM_HC_MAP_GPA_RANGE. - -The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset -of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace -the hypercalls whose corresponding bit is in the argument, and return -ENOSYS for the others. - -8.35 KVM_CAP_PMU_CAPABILITY ---------------------------- - -:Capability: KVM_CAP_PMU_CAPABILITY -:Architectures: x86 -:Type: vm -:Parameters: arg[0] is bitmask of PMU virtualization capabilities. -:Returns: 0 on success, -EINVAL when arg[0] contains invalid bits - -This capability alters PMU virtualization in KVM. - -Calling KVM_CHECK_EXTENSION for this capability returns a bitmask of -PMU virtualization capabilities that can be adjusted on a VM. - -The argument to KVM_ENABLE_CAP is also a bitmask and selects specific -PMU virtualization capabilities to be applied to the VM. This can -only be invoked on a VM prior to the creation of VCPUs. - -At this time, KVM_PMU_CAP_DISABLE is the only capability. Setting -this capability will disable PMU virtualization for that VM. Usermode -should adjust CPUID leaf 0xA to reflect that the PMU is disabled. - -8.36 KVM_CAP_ARM_SYSTEM_SUSPEND -------------------------------- - -:Capability: KVM_CAP_ARM_SYSTEM_SUSPEND -:Architectures: arm64 -:Type: vm - -When enabled, KVM will exit to userspace with KVM_EXIT_SYSTEM_EVENT of -type KVM_SYSTEM_EVENT_SUSPEND to process the guest suspend request. - 8.37 KVM_CAP_S390_PROTECTED_DUMP -------------------------------- -:Capability: KVM_CAP_S390_PROTECTED_DUMP :Architectures: s390 :Type: vm @@ -8957,27 +8918,9 @@ PV guests. The `KVM_PV_DUMP` command is available for the dump related UV data. Also the vcpu ioctl `KVM_S390_PV_CPU_COMMAND` is available and supports the `KVM_PV_DUMP_CPU` subcommand. -8.38 KVM_CAP_VM_DISABLE_NX_HUGE_PAGES -------------------------------------- - -:Capability: KVM_CAP_VM_DISABLE_NX_HUGE_PAGES -:Architectures: x86 -:Type: vm -:Parameters: arg[0] must be 0. -:Returns: 0 on success, -EPERM if the userspace process does not - have CAP_SYS_BOOT, -EINVAL if args[0] is not 0 or any vCPUs have been - created. - -This capability disables the NX huge pages mitigation for iTLB MULTIHIT. - -The capability has no effect if the nx_huge_pages module parameter is not set. - -This capability may only be set before any vCPUs are created. - 8.39 KVM_CAP_S390_CPU_TOPOLOGY ------------------------------ -:Capability: KVM_CAP_S390_CPU_TOPOLOGY :Architectures: s390 :Type: vm @@ -8999,37 +8942,9 @@ structure. When getting the Modified Change Topology Report value, the attr->addr must point to a byte where the value will be stored or retrieved from. -8.40 KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE ---------------------------------------- - -:Capability: KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE -:Architectures: arm64 -:Type: vm -:Parameters: arg[0] is the new split chunk size. -:Returns: 0 on success, -EINVAL if any memslot was already created. - -This capability sets the chunk size used in Eager Page Splitting. - -Eager Page Splitting improves the performance of dirty-logging (used -in live migrations) when guest memory is backed by huge-pages. It -avoids splitting huge-pages (into PAGE_SIZE pages) on fault, by doing -it eagerly when enabling dirty logging (with the -KVM_MEM_LOG_DIRTY_PAGES flag for a memory region), or when using -KVM_CLEAR_DIRTY_LOG. - -The chunk size specifies how many pages to break at a time, using a -single allocation for each chunk. Bigger the chunk size, more pages -need to be allocated ahead of time. - -The chunk size needs to be a valid block size. The list of acceptable -block sizes is exposed in KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES as a -64-bit bitmap (each bit describing a block size). The default value is -0, to disable the eager page splitting. - 8.41 KVM_CAP_VM_TYPES --------------------- -:Capability: KVM_CAP_MEMORY_ATTRIBUTES :Architectures: x86 :Type: system ioctl @@ -9046,6 +8961,67 @@ Do not use KVM_X86_SW_PROTECTED_VM for "real" VMs, and especially not in production. The behavior and effective ABI for software-protected VMs is unstable. +8.42 KVM_CAP_PPC_RPT_INVALIDATE +------------------------------- + +:Architectures: ppc + +This capability indicates that the kernel is capable of handling +H_RPT_INVALIDATE hcall. + +In order to enable the use of H_RPT_INVALIDATE in the guest, +user space might have to advertise it for the guest. For example, +IBM pSeries (sPAPR) guest starts using it if "hcall-rpt-invalidate" is +present in the "ibm,hypertas-functions" device-tree property. + +This capability is enabled for hypervisors on platforms like POWER9 +that support radix MMU. + +8.43 KVM_CAP_PPC_AIL_MODE_3 +--------------------------- + +:Architectures: ppc + +This capability indicates that the kernel supports the mode 3 setting for the +"Address Translation Mode on Interrupt" aka "Alternate Interrupt Location" +resource that is controlled with the H_SET_MODE hypercall. + +This capability allows a guest kernel to use a better-performance mode for +handling interrupts and system calls. + +8.44 KVM_CAP_MEMORY_FAULT_INFO +------------------------------ + +:Architectures: x86 + +The presence of this capability indicates that KVM_RUN will fill +kvm_run.memory_fault if KVM cannot resolve a guest page fault VM-Exit, e.g. if +there is a valid memslot but no backing VMA for the corresponding host virtual +address. + +The information in kvm_run.memory_fault is valid if and only if KVM_RUN returns +an error with errno=EFAULT or errno=EHWPOISON *and* kvm_run.exit_reason is set +to KVM_EXIT_MEMORY_FAULT. + +Note: Userspaces which attempt to resolve memory faults so that they can retry +KVM_RUN are encouraged to guard against repeatedly receiving the same +error/annotated fault. + +See KVM_EXIT_MEMORY_FAULT for more information. + +8.45 KVM_CAP_X86_GUEST_MODE +--------------------------- + +:Architectures: x86 + +The presence of this capability indicates that KVM_RUN will update the +KVM_RUN_X86_GUEST_MODE bit in kvm_run.flags to indicate whether the +vCPU was executing nested guest code when it exited. + +KVM exits with the register state of either the L1 or L2 guest +depending on which executed at the time of an exit. Userspace must +take care to differentiate between these cases. + 9. Known KVM API problems ========================= @@ -9076,9 +9052,10 @@ the local APIC. The same is true for the ``KVM_FEATURE_PV_UNHALT`` paravirtualized feature. -CPU[EAX=1]:ECX[24] (TSC_DEADLINE) is not reported by ``KVM_GET_SUPPORTED_CPUID``. -It can be enabled if ``KVM_CAP_TSC_DEADLINE_TIMER`` is present and the kernel -has enabled in-kernel emulation of the local APIC. +On older versions of Linux, CPU[EAX=1]:ECX[24] (TSC_DEADLINE) is not reported by +``KVM_GET_SUPPORTED_CPUID``, but it can be enabled if ``KVM_CAP_TSC_DEADLINE_TIMER`` +is present and the kernel has enabled in-kernel emulation of the local APIC. +On newer versions, ``KVM_GET_SUPPORTED_CPUID`` does report the bit as available. CPU topology ~~~~~~~~~~~~ |