diff options
Diffstat (limited to 'Documentation')
824 files changed, 26840 insertions, 5371 deletions
diff --git a/Documentation/ABI/README b/Documentation/ABI/README index 8bac9cb09a6d..ef0e6d11e919 100644 --- a/Documentation/ABI/README +++ b/Documentation/ABI/README @@ -1,4 +1,5 @@ -This directory attempts to document the ABI between the Linux kernel and +This part of the documentation inside Documentation/ABI directory +attempts to document the ABI between the Linux kernel and userspace, and the relative stability of these interfaces. Due to the everchanging nature of Linux, and the differing maturity levels, these interfaces should be used by userspace programs in different ways. diff --git a/Documentation/ABI/obsolete/sysfs-class-cxl b/Documentation/ABI/removed/sysfs-class-cxl index 8cba1b626985..266c413b96e8 100644 --- a/Documentation/ABI/obsolete/sysfs-class-cxl +++ b/Documentation/ABI/removed/sysfs-class-cxl @@ -1,5 +1,4 @@ -The cxl driver is no longer maintained, and will be removed from the kernel in -the near future. +The cxl driver was removed in 6.15. Please note that attributes that are shared between devices are stored in the directory pointed to by the symlink device/. @@ -10,7 +9,7 @@ For example, the real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is Slave contexts (eg. /sys/class/cxl/afu0.0s): What: /sys/class/cxl/<afu>/afu_err_buf -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only AFU Error Buffer contents. The contents of this file are @@ -21,7 +20,7 @@ Description: read only What: /sys/class/cxl/<afu>/irqs_max -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read/write Decimal value of maximum number of interrupts that can be @@ -32,7 +31,7 @@ Description: read/write Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/irqs_min -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Decimal value of the minimum number of interrupts that @@ -42,7 +41,7 @@ Description: read only Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/mmio_size -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Decimal value of the size of the MMIO space that may be mmapped @@ -50,7 +49,7 @@ Description: read only Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/modes_supported -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only List of the modes this AFU supports. One per line. @@ -58,7 +57,7 @@ Description: read only Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/mode -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read/write The current mode the AFU is using. Will be one of the modes @@ -68,7 +67,7 @@ Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/prefault_mode -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read/write Set the mode for prefaulting in segments into the segment table @@ -88,7 +87,7 @@ Description: read/write Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/reset -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: write only Writing 1 here will reset the AFU provided there are not @@ -96,14 +95,14 @@ Description: write only Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/api_version -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Decimal value of the current version of the kernel/user API. Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/api_version_compatible -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Decimal value of the lowest version of the userspace API @@ -117,7 +116,7 @@ An AFU may optionally export one or more PCIe like configuration records, known as AFU configuration records, which will show up here (if present). What: /sys/class/cxl/<afu>/cr<config num>/vendor -Date: February 2015 +Date: February 2015, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Hexadecimal value of the vendor ID found in this AFU @@ -125,7 +124,7 @@ Description: read only Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/cr<config num>/device -Date: February 2015 +Date: February 2015, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Hexadecimal value of the device ID found in this AFU @@ -133,7 +132,7 @@ Description: read only Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/cr<config num>/class -Date: February 2015 +Date: February 2015, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Hexadecimal value of the class code found in this AFU @@ -141,7 +140,7 @@ Description: read only Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>/cr<config num>/config -Date: February 2015 +Date: February 2015, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only This binary file provides raw access to the AFU configuration @@ -155,7 +154,7 @@ Users: https://github.com/ibm-capi/libcxl Master contexts (eg. /sys/class/cxl/afu0.0m) What: /sys/class/cxl/<afu>m/mmio_size -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Decimal value of the size of the MMIO space that may be mmapped @@ -163,14 +162,14 @@ Description: read only Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>m/pp_mmio_len -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Decimal value of the Per Process MMIO space length. Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<afu>m/pp_mmio_off -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only (not in a guest) @@ -181,21 +180,21 @@ Users: https://github.com/ibm-capi/libcxl Card info (eg. /sys/class/cxl/card0) What: /sys/class/cxl/<card>/caia_version -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Identifies the CAIA Version the card implements. Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<card>/psl_revision -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Identifies the revision level of the PSL. Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<card>/base_image -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only (not in a guest) @@ -206,7 +205,7 @@ Description: read only Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<card>/image_loaded -Date: September 2014 +Date: September 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only (not in a guest) @@ -215,7 +214,7 @@ Description: read only Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<card>/load_image_on_perst -Date: December 2014 +Date: December 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read/write (not in a guest) @@ -232,7 +231,7 @@ Description: read/write Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<card>/reset -Date: October 2014 +Date: October 2014, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: write only Writing 1 will issue a PERST to card provided there are no @@ -243,7 +242,7 @@ Description: write only Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<card>/perst_reloads_same_image -Date: July 2015 +Date: July 2015, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read/write (not in a guest) @@ -257,7 +256,7 @@ Description: read/write Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<card>/psl_timebase_synced -Date: March 2016 +Date: March 2016, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Returns 1 if the psl timebase register is synchronized @@ -265,7 +264,7 @@ Description: read only Users: https://github.com/ibm-capi/libcxl What: /sys/class/cxl/<card>/tunneled_ops_supported -Date: May 2018 +Date: May 2018, removed February 2025 Contact: linuxppc-dev@lists.ozlabs.org Description: read only Returns 1 if tunneled operations are supported in capi mode, diff --git a/Documentation/ABI/removed/sysfs-class-rfkill b/Documentation/ABI/removed/sysfs-class-rfkill index f25174eafd55..20cb688af173 100644 --- a/Documentation/ABI/removed/sysfs-class-rfkill +++ b/Documentation/ABI/removed/sysfs-class-rfkill @@ -4,7 +4,7 @@ For details to this subsystem look at Documentation/driver-api/rfkill.rst. What: /sys/class/rfkill/rfkill[0-9]+/claim Date: 09-Jul-2007 -KernelVersion v2.6.22 +KernelVersion: v2.6.22 Contact: linux-wireless@vger.kernel.org Description: This file was deprecated because there no longer was a way to claim just control over a single rfkill instance. diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block index 0cceb2badc83..3879963f0f01 100644 --- a/Documentation/ABI/stable/sysfs-block +++ b/Documentation/ABI/stable/sysfs-block @@ -109,6 +109,10 @@ Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Indicates whether a storage device is capable of storing integrity metadata. Set if the device is T10 PI-capable. + This flag is set to 1 if the storage media is formatted + with T10 Protection Information. If the storage media is + not formatted with T10 Protection Information, this flag + is set to 0. What: /sys/block/<disk>/integrity/format @@ -117,6 +121,13 @@ Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Metadata format for integrity capable block device. E.g. T10-DIF-TYPE1-CRC. + This field describes the type of T10 Protection Information + that the block device can send and receive. + If the device can store application integrity metadata but + no T10 Protection Information profile is used, this field + contains "nop". + If the device does not support integrity metadata, this + field contains "none". What: /sys/block/<disk>/integrity/protection_interval_bytes @@ -142,7 +153,17 @@ Date: June 2008 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Number of bytes of integrity tag space available per - 512 bytes of data. + protection_interval_bytes, which is typically + the device's logical block size. + This field describes the size of the application tag + if the storage device is formatted with T10 Protection + Information and permits use of the application tag. + The tag_size is reported in bytes and indicates the + space available for adding an opaque tag to each block + (protection_interval_bytes). + If the device does not support T10 Protection Information + (even if the device provides application integrity + metadata space), this field is set to 0. What: /sys/block/<disk>/integrity/write_generate @@ -229,6 +250,17 @@ Description: encryption, refer to Documentation/block/inline-encryption.rst. +What: /sys/block/<disk>/queue/crypto/hw_wrapped_keys +Date: February 2025 +Contact: linux-block@vger.kernel.org +Description: + [RO] The presence of this file indicates that the device + supports hardware-wrapped inline encryption keys, i.e. key blobs + that can only be unwrapped and used by dedicated hardware. For + more information about hardware-wrapped inline encryption keys, + see Documentation/block/inline-encryption.rst. + + What: /sys/block/<disk>/queue/crypto/max_dun_bits Date: February 2022 Contact: linux-block@vger.kernel.org @@ -267,6 +299,15 @@ Description: use with inline encryption. +What: /sys/block/<disk>/queue/crypto/raw_keys +Date: February 2025 +Contact: linux-block@vger.kernel.org +Description: + [RO] The presence of this file indicates that the device + supports raw inline encryption keys, i.e. keys that are managed + in raw, plaintext form in software. + + What: /sys/block/<disk>/queue/dax Date: June 2016 Contact: linux-block@vger.kernel.org diff --git a/Documentation/ABI/stable/sysfs-class-rfkill b/Documentation/ABI/stable/sysfs-class-rfkill index 037979f7dc4b..67b605e3dd16 100644 --- a/Documentation/ABI/stable/sysfs-class-rfkill +++ b/Documentation/ABI/stable/sysfs-class-rfkill @@ -16,7 +16,7 @@ Description: The rfkill class subsystem folder. What: /sys/class/rfkill/rfkill[0-9]+/name Date: 09-Jul-2007 -KernelVersion v2.6.22 +KernelVersion: v2.6.22 Contact: linux-wireless@vger.kernel.org Description: Name assigned by driver to this key (interface or driver name). Values: arbitrary string. @@ -24,7 +24,7 @@ Values: arbitrary string. What: /sys/class/rfkill/rfkill[0-9]+/type Date: 09-Jul-2007 -KernelVersion v2.6.22 +KernelVersion: v2.6.22 Contact: linux-wireless@vger.kernel.org Description: Driver type string ("wlan", "bluetooth", etc). Values: See include/linux/rfkill.h. @@ -32,7 +32,7 @@ Values: See include/linux/rfkill.h. What: /sys/class/rfkill/rfkill[0-9]+/persistent Date: 09-Jul-2007 -KernelVersion v2.6.22 +KernelVersion: v2.6.22 Contact: linux-wireless@vger.kernel.org Description: Whether the soft blocked state is initialised from non-volatile storage at startup. @@ -44,7 +44,7 @@ Values: A numeric value: What: /sys/class/rfkill/rfkill[0-9]+/state Date: 09-Jul-2007 -KernelVersion v2.6.22 +KernelVersion: v2.6.22 Contact: linux-wireless@vger.kernel.org Description: Current state of the transmitter. This file was scheduled to be removed in 2014, but due to its @@ -67,7 +67,7 @@ Values: A numeric value. What: /sys/class/rfkill/rfkill[0-9]+/hard Date: 12-March-2010 -KernelVersion v2.6.34 +KernelVersion: v2.6.34 Contact: linux-wireless@vger.kernel.org Description: Current hardblock state. This file is read only. Values: A numeric value. @@ -81,7 +81,7 @@ Values: A numeric value. What: /sys/class/rfkill/rfkill[0-9]+/soft Date: 12-March-2010 -KernelVersion v2.6.34 +KernelVersion: v2.6.34 Contact: linux-wireless@vger.kernel.org Description: Current softblock state. This file is read and write. Values: A numeric value. 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/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu index 902392d7eddf..cf78bd99f6c8 100644 --- a/Documentation/ABI/stable/sysfs-devices-system-cpu +++ b/Documentation/ABI/stable/sysfs-devices-system-cpu @@ -24,12 +24,6 @@ Description: Default value for the Data Stream Control Register (DSCR) on If set by a process it will be inherited by child processes. Values: 64 bit unsigned integer (bit field) -What: /sys/devices/system/cpu/cpuX/topology/physical_package_id -Description: physical package id of cpuX. Typically corresponds to a physical - socket number, but the actual value is architecture and platform - dependent. -Values: integer - What: /sys/devices/system/cpu/cpuX/topology/die_id Description: the CPU die ID of cpuX. Typically it is the hardware platform's identifier (rather than the kernel's). The actual value is @@ -86,10 +80,6 @@ What: /sys/devices/system/cpu/cpuX/topology/die_cpus Description: internal kernel map of CPUs within the same die. Values: hexadecimal bitmask. -What: /sys/devices/system/cpu/cpuX/topology/ppin -Description: per-socket protected processor inventory number -Values: hexadecimal. - What: /sys/devices/system/cpu/cpuX/topology/die_cpus_list Description: human-readable list of CPUs within the same die. The format is like 0-3, 8-11, 14,17. diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd index f2ec42949a54..4a355e6747ae 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd @@ -246,14 +246,14 @@ Description: Controls whether PRS disable is turned on for the workqueue. capability. What: /sys/bus/dsa/devices/wq<m>.<n>/occupancy -Date May 25, 2021 +Date: May 25, 2021 KernelVersion: 5.14.0 Contact: dmaengine@vger.kernel.org Description: Show the current number of entries in this WQ if WQ Occupancy Support bit WQ capabilities is 1. What: /sys/bus/dsa/devices/wq<m>.<n>/enqcmds_retries -Date Oct 29, 2021 +Date: Oct 29, 2021 KernelVersion: 5.17.0 Contact: dmaengine@vger.kernel.org Description: Indicate the number of retires for an enqcmds submission on a sharedwq. diff --git a/Documentation/ABI/testing/configfs-usb-gadget-midi2 b/Documentation/ABI/testing/configfs-usb-gadget-midi2 index 0eac3aaba137..d76a52e2ca7f 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-midi2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-midi2 @@ -47,7 +47,7 @@ Description: midi1_first_group The first UMP Group number for MIDI 1.0 (0-15) midi1_num_groups The number of groups for MIDI 1.0 (0-16) ui_hint 0: unknown, 1: receiver, 2: sender, 3: both - midi_ci_verison Supported MIDI-CI version number (8 bit) + midi_ci_version Supported MIDI-CI version number (8 bit) is_midi1 Legacy MIDI 1.0 device (0, 1 or 2) sysex8_streams Max number of SysEx8 streams (8 bit) active Active FB flag (0 or 1) 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-cti b/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti index bf2869c413e7..a97b70f588da 100644 --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-cti @@ -1,241 +1,241 @@ What: /sys/bus/coresight/devices/<cti-name>/enable Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Enable/Disable the CTI hardware. What: /sys/bus/coresight/devices/<cti-name>/powered Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Indicate if the CTI hardware is powered. What: /sys/bus/coresight/devices/<cti-name>/ctmid Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Display the associated CTM ID What: /sys/bus/coresight/devices/<cti-name>/nr_trigger_cons Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Number of devices connected to triggers on this CTI What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/name Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Name of connected device <N> What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_signals Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Input trigger signals from connected device <N> What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_types Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Functional types for the input trigger signals from connected device <N> What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_signals Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Output trigger signals to connected device <N> What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_types Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Functional types for the output trigger signals to connected device <N> What: /sys/bus/coresight/devices/<cti-name>/regs/inout_sel Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Select the index for inen and outen registers. What: /sys/bus/coresight/devices/<cti-name>/regs/inen Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Read or write the CTIINEN register selected by inout_sel. What: /sys/bus/coresight/devices/<cti-name>/regs/outen Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Read or write the CTIOUTEN register selected by inout_sel. What: /sys/bus/coresight/devices/<cti-name>/regs/gate Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Read or write CTIGATE register. What: /sys/bus/coresight/devices/<cti-name>/regs/asicctl Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Read or write ASICCTL register. What: /sys/bus/coresight/devices/<cti-name>/regs/intack Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Write the INTACK register. What: /sys/bus/coresight/devices/<cti-name>/regs/appset Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Set CTIAPPSET register to activate channel. Read back to determine current value of register. What: /sys/bus/coresight/devices/<cti-name>/regs/appclear Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Write APPCLEAR register to deactivate channel. What: /sys/bus/coresight/devices/<cti-name>/regs/apppulse Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Write APPPULSE to pulse a channel active for one clock cycle. What: /sys/bus/coresight/devices/<cti-name>/regs/chinstatus Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Read current status of channel inputs. What: /sys/bus/coresight/devices/<cti-name>/regs/choutstatus Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) read current status of channel outputs. What: /sys/bus/coresight/devices/<cti-name>/regs/triginstatus Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) read current status of input trigger signals What: /sys/bus/coresight/devices/<cti-name>/regs/trigoutstatus Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) read current status of output trigger signals. What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_attach Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Attach a CTI input trigger to a CTM channel. What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_detach Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Detach a CTI input trigger from a CTM channel. What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_attach Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Attach a CTI output trigger to a CTM channel. What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_detach Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Detach a CTI output trigger from a CTM channel. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_enable Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Enable CTIGATE for single channel (Write) or list enabled channels through the gate (R). What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_disable Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Disable CTIGATE for single channel. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_set Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Activate a single channel. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_clear Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Deactivate a single channel. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_pulse Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Pulse a single channel - activate for a single clock cycle. What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_filtered Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) List of output triggers filtered across all connections. What: /sys/bus/coresight/devices/<cti-name>/channels/trig_filter_enable Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Enable or disable trigger output signal filtering. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_inuse Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) show channels with at least one attached trigger signal. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_free Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) show channels with no attached trigger signals. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_sel Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (RW) Write channel number to select a channel to view, read to see selected channel number. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_in Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Read to see input triggers connected to selected view channel. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_out Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Read) Read to see output triggers connected to selected view channel. What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_reset Date: March 2020 -KernelVersion 5.7 +KernelVersion: 5.7 Contact: Mike Leach or Mathieu Poirier Description: (Write) Clear all channel / trigger programming. diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm index bf710ea6e0ef..a341b08ae70b 100644 --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm @@ -1,6 +1,6 @@ What: /sys/bus/coresight/devices/<tpdm-name>/integration_test Date: January 2023 -KernelVersion 6.2 +KernelVersion: 6.2 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (Write) Run integration test for tpdm. Integration test @@ -14,7 +14,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/reset_dataset Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (Write) Reset the dataset of the tpdm. @@ -24,7 +24,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_type Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the trigger type of the DSB for tpdm. @@ -35,7 +35,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_ts Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the trigger timestamp of the DSB for tpdm. @@ -46,7 +46,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_mode Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the programming mode of the DSB for tpdm. @@ -60,7 +60,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_idx Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the index number of the edge detection for the DSB @@ -69,7 +69,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_val Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: Write a data to control the edge detection corresponding to @@ -85,7 +85,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_mask Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: Write a data to mask the edge detection corresponding to the index @@ -97,21 +97,21 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/edcr[0:15] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: Read a set of the edge control value of the DSB in TPDM. What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/edcmr[0:7] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: Read a set of the edge control mask of the DSB in TPDM. What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_patt/xpr[0:7] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the value of the trigger pattern for the DSB @@ -119,7 +119,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_patt/xpmr[0:7] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the mask of the trigger pattern for the DSB @@ -127,21 +127,21 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpr[0:7] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the value of the pattern for the DSB subunit TPDM. What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpmr[0:7] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the mask of the pattern for the DSB subunit TPDM. What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/enable_ts Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (Write) Set the pattern timestamp of DSB tpdm. Read @@ -153,7 +153,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/set_type Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (Write) Set the pattern type of DSB tpdm. Read @@ -165,7 +165,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_msr/msr[0:31] Date: March 2023 -KernelVersion 6.7 +KernelVersion: 6.7 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the MSR(mux select register) for the DSB subunit @@ -173,7 +173,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/cmb_mode Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (Write) Set the data collection mode of CMB tpdm. Continuous change creates CMB data set elements on every CMBCLK edge. @@ -187,7 +187,7 @@ Description: (Write) Set the data collection mode of CMB tpdm. Continuous What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_patt/xpr[0:1] Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the value of the trigger pattern for the CMB @@ -195,7 +195,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_patt/xpmr[0:1] Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the mask of the trigger pattern for the CMB @@ -203,21 +203,21 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpr[0:1] Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the value of the pattern for the CMB subunit TPDM. What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpmr[0:1] Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the mask of the pattern for the CMB subunit TPDM. What: /sys/bus/coresight/devices/<tpdm-name>/cmb_patt/enable_ts Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (Write) Set the pattern timestamp of CMB tpdm. Read @@ -229,7 +229,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_ts Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Set/Get the trigger timestamp of the CMB for tpdm. @@ -240,7 +240,7 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/cmb_ts_all Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> Description: (RW) Read or write the status of timestamp upon all interface. @@ -252,8 +252,23 @@ Description: What: /sys/bus/coresight/devices/<tpdm-name>/cmb_msr/msr[0:31] Date: January 2024 -KernelVersion 6.9 +KernelVersion: 6.9 Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com> 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-class-chromeos b/Documentation/ABI/testing/sysfs-class-chromeos index 74ece942722e..7fa5be6cc774 100644 --- a/Documentation/ABI/testing/sysfs-class-chromeos +++ b/Documentation/ABI/testing/sysfs-class-chromeos @@ -31,3 +31,23 @@ Date: August 2015 KernelVersion: 4.2 Description: Show the information about the EC software and hardware. + +What: /sys/class/chromeos/cros_ec/usbpdmuxinfo +Date: February 2025 +Description: + Show PD mux status for each typec port with following flags: + - "USB": USB connected + - "DP": DP connected + - "POLARITY": CC line Polarity inverted + - "HPD_IRQ": Hot Plug Detect interrupt is asserted + - "HPD_LVL": Hot Plug Detect level is asserted + - "SAFE": DP is in safe mode + - "TBT": TBT enabled + - "USB4": USB4 enabled + +What: /sys/class/chromeos/cros_ec/ap_mode_entry +Date: February 2025 +Description: + Show if the AP mode entry EC feature is supported. + It indicates whether the EC waits for direction from the AP + to enter Type-C altmodes or USB4 mode. diff --git a/Documentation/ABI/testing/sysfs-driver-amd-sfh b/Documentation/ABI/testing/sysfs-driver-amd-sfh new file mode 100644 index 000000000000..c053126a83bb --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-amd-sfh @@ -0,0 +1,13 @@ +What: /sys/bus/pci/drivers/pcie_mp2_amd/*/hpd +Date: April 2025 +Contact: mario.limonciello@amd.com +Description: + Human presence detection (HPD) enable/disable. + When HPD is enabled, the device will be able to detect the + presence of a human and will send an interrupt that can be + used to wake the system from a low power state. + When HPD is disabled, the device will not be able to detect + the presence of a human. + + Access: Read/Write + Valid values: enabled/disabled diff --git a/Documentation/ABI/testing/sysfs-driver-hid-appletb-kbd b/Documentation/ABI/testing/sysfs-driver-hid-appletb-kbd new file mode 100644 index 000000000000..2a19584d091e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-appletb-kbd @@ -0,0 +1,13 @@ +What: /sys/bus/hid/drivers/hid-appletb-kbd/<dev>/mode +Date: September, 2023 +KernelVersion: 6.5 +Contact: linux-input@vger.kernel.org +Description: + The set of keys displayed on the Touch Bar. + Valid values are: + == ================= + 0 Escape key only + 1 Function keys + 2 Media/brightness keys + 3 None + == ================= 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-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index 5fa6655aee84..ae0191295d29 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -1559,3 +1559,48 @@ Description: Symbol - HCMID. This file shows the UFSHCD manufacturer id. The Manufacturer ID is defined by JEDEC in JEDEC-JEP106. The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/critical_health +What: /sys/bus/platform/devices/*.ufs/critical_health +Date: February 2025 +Contact: Avri Altman <avri.altman@wdc.com> +Description: Report the number of times a critical health event has been + reported by a UFS device. Further insight into the specific + issue can be gained by reading one of: bPreEOLInfo, + bDeviceLifeTimeEstA, bDeviceLifeTimeEstB, + bWriteBoosterBufferLifeTimeEst, and bRPMBLifeTimeEst. + + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/clkscale_enable +What: /sys/bus/platform/devices/*.ufs/clkscale_enable +Date: January 2025 +Contact: Ziqi Chen <quic_ziqichen@quicinc.com> +Description: + This attribute shows whether the UFS clock scaling is enabled or not. + And it can be used to enable/disable the clock scaling by writing + 1 or 0 to this attribute. + + The attribute is read/write. + +What: /sys/bus/platform/drivers/ufshcd/*/clkgate_enable +What: /sys/bus/platform/devices/*.ufs/clkgate_enable +Date: January 2025 +Contact: Ziqi Chen <quic_ziqichen@quicinc.com> +Description: + This attribute shows whether the UFS clock gating is enabled or not. + And it can be used to enable/disable the clock gating by writing + 1 or 0 to this attribute. + + The attribute is read/write. + +What: /sys/bus/platform/drivers/ufshcd/*/clkgate_delay_ms +What: /sys/bus/platform/devices/*.ufs/clkgate_delay_ms +Date: January 2025 +Contact: Ziqi Chen <quic_ziqichen@quicinc.com> +Description: + This attribute shows and sets the number of milliseconds of idle time + before the UFS driver starts to perform clock gating. This can + prevent the UFS from frequently performing clock gating/ungating. + + The attribute is read/write. diff --git a/Documentation/ABI/testing/sysfs-edac-ecs b/Documentation/ABI/testing/sysfs-edac-ecs new file mode 100644 index 000000000000..87c885c4eb1a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-edac-ecs @@ -0,0 +1,74 @@ +What: /sys/bus/edac/devices/<dev-name>/ecs_fruX +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + The sysfs EDAC bus devices /<dev-name>/ecs_fruX subdirectory + pertains to the memory media ECS (Error Check Scrub) control + feature, where <dev-name> directory corresponds to a device + registered with the EDAC device driver for the ECS feature. + /ecs_fruX belongs to the media FRUs (Field Replaceable Unit) + under the memory device. + + The sysfs ECS attr nodes are only present if the parent + driver has implemented the corresponding attr callback + function and provided the necessary operations to the EDAC + device driver during registration. + +What: /sys/bus/edac/devices/<dev-name>/ecs_fruX/log_entry_type +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The log entry type of how the DDR5 ECS log is reported. + + - 0 - per DRAM. + + - 1 - per memory media FRU. + + - All other values are reserved. + +What: /sys/bus/edac/devices/<dev-name>/ecs_fruX/mode +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The mode of how the DDR5 ECS counts the errors. + Error count is tracked based on two different modes + selected by DDR5 ECS Control Feature - Codeword mode and + Row Count mode. If the ECS is under Codeword mode, then + the error count increments each time a codeword with check + bit errors is detected. If the ECS is under Row Count mode, + then the error counter increments each time a row with + check bit errors is detected. + + - 0 - ECS counts rows in the memory media that have ECC errors. + + - 1 - ECS counts codewords with errors, specifically, it counts + the number of ECC-detected errors in the memory media. + + - All other values are reserved. + +What: /sys/bus/edac/devices/<dev-name>/ecs_fruX/reset +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (WO) ECS reset ECC counter. + + - 1 - reset ECC counter to the default value. + + - All other values are reserved. + +What: /sys/bus/edac/devices/<dev-name>/ecs_fruX/threshold +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) DDR5 ECS threshold count per gigabits of memory cells. + The ECS error count is subject to the ECS Threshold count + per Gbit, which masks error counts less than the Threshold. + + Supported values are 256, 1024 and 4096. + + All other values are reserved. diff --git a/Documentation/ABI/testing/sysfs-edac-memory-repair b/Documentation/ABI/testing/sysfs-edac-memory-repair new file mode 100644 index 000000000000..0434a3b23ff3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-edac-memory-repair @@ -0,0 +1,206 @@ +What: /sys/bus/edac/devices/<dev-name>/mem_repairX +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + The sysfs EDAC bus devices /<dev-name>/mem_repairX subdirectory + pertains to the memory media repair features control, such as + PPR (Post Package Repair), memory sparing etc, where <dev-name> + directory corresponds to a device registered with the EDAC + device driver for the memory repair features. + + Post Package Repair is a maintenance operation requests the memory + device to perform a repair operation on its media. It is a memory + self-healing feature that fixes a failing memory location by + replacing it with a spare row in a DRAM device. For example, a + CXL memory device with DRAM components that support PPR features may + implement PPR maintenance operations. DRAM components may support + two types of PPR functions: hard PPR, for a permanent row repair, and + soft PPR, for a temporary row repair. Soft PPR may be much faster + than hard PPR, but the repair is lost with a power cycle. + + The sysfs attributes nodes for a repair feature are only + present if the parent driver has implemented the corresponding + attr callback function and provided the necessary operations + to the EDAC device driver during registration. + + In some states of system configuration (e.g. before address + decoders have been configured), memory devices (e.g. CXL) + may not have an active mapping in the main host address + physical address map. As such, the memory to repair must be + identified by a device specific physical addressing scheme + using a device physical address(DPA). The DPA and other control + attributes to use will be presented in related error records. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/repair_type +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RO) Memory repair type. For eg. post package repair, + memory sparing etc. Valid values are: + + - ppr - Post package repair. + + - cacheline-sparing + + - row-sparing + + - bank-sparing + + - rank-sparing + + - All other values are reserved. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/persist_mode +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) Get/Set the current persist repair mode set for a + repair function. Persist repair modes supported in the + device, based on a memory repair function, either is temporary, + which is lost with a power cycle or permanent. Valid values are: + + - 0 - Soft memory repair (temporary repair). + + - 1 - Hard memory repair (permanent repair). + + - All other values are reserved. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/repair_safe_when_in_use +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RO) True if memory media is accessible and data is retained + during the memory repair operation. + The data may not be retained and memory requests may not be + correctly processed during a repair operation. In such case + repair operation can not be executed at runtime. The memory + must be taken offline. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/hpa +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) Host Physical Address (HPA) of the memory to repair. + The HPA to use will be provided in related error records. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/dpa +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) Device Physical Address (DPA) of the memory to repair. + The specific DPA to use will be provided in related error + records. + + In some states of system configuration (e.g. before address + decoders have been configured), memory devices (e.g. CXL) + may not have an active mapping in the main host address + physical address map. As such, the memory to repair must be + identified by a device specific physical addressing scheme + using a DPA. The device physical address(DPA) to use will be + presented in related error records. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/nibble_mask +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) Read/Write Nibble mask of the memory to repair. + Nibble mask identifies one or more nibbles in error on the + memory bus that produced the error event. Nibble Mask bit 0 + shall be set if nibble 0 on the memory bus produced the + event, etc. For example, CXL PPR and sparing, a nibble mask + bit set to 1 indicates the request to perform repair + operation in the specific device. All nibble mask bits set + to 1 indicates the request to perform the operation in all + devices. Eg. for CXL memory repair, the specific value of + nibble mask to use will be provided in related error records. + For more details, See nibble mask field in CXL spec ver 3.1, + section 8.2.9.7.1.2 Table 8-103 soft PPR and section + 8.2.9.7.1.3 Table 8-104 hard PPR, section 8.2.9.7.1.4 + Table 8-105 memory sparing. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/min_hpa +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/max_hpa +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/min_dpa +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/max_dpa +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The supported range of memory address that is to be + repaired. The memory device may give the supported range of + attributes to use and it will depend on the memory device + and the portion of memory to repair. + The userspace may receive the specific value of attributes + to use for a repair operation from the memory device via + related error records and trace events, for eg. CXL DRAM + and CXL general media error records in CXL memory devices. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/bank_group +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/bank +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/rank +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/row +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/column +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/channel +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/sub_channel +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The control attributes for the memory to be repaired. + The specific value of attributes to use depends on the + portion of memory to repair and will be reported to the host + in related error records and be available to userspace + in trace events, such as CXL DRAM and CXL general media + error records of CXL memory devices. + + When readng back these attributes, it returns the current + value of memory requested to be repaired. + + bank_group - The bank group of the memory to repair. + + bank - The bank number of the memory to repair. + + rank - The rank of the memory to repair. Rank is defined as a + set of memory devices on a channel that together execute a + transaction. + + row - The row number of the memory to repair. + + column - The column number of the memory to repair. + + channel - The channel of the memory to repair. Channel is + defined as an interface that can be independently accessed + for a transaction. + + sub_channel - The subchannel of the memory to repair. + + The requirement to set these attributes varies based on the + repair function. The attributes in sysfs are not present + unless required for a repair function. + + For example, CXL spec ver 3.1, Section 8.2.9.7.1.2 Table 8-103 + soft PPR and Section 8.2.9.7.1.3 Table 8-104 hard PPR operations, + these attributes are not required to set. CXL spec ver 3.1, + Section 8.2.9.7.1.4 Table 8-105 memory sparing, these attributes + are required to set based on memory sparing granularity. + +What: /sys/bus/edac/devices/<dev-name>/mem_repairX/repair +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (WO) Issue the memory repair operation for the specified + memory repair attributes. The operation may fail if resources + are insufficient based on the requirements of the memory + device and repair function. + + - 1 - Issue the repair operation. + + - All other values are reserved. diff --git a/Documentation/ABI/testing/sysfs-edac-scrub b/Documentation/ABI/testing/sysfs-edac-scrub new file mode 100644 index 000000000000..c43be90deab4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-edac-scrub @@ -0,0 +1,69 @@ +What: /sys/bus/edac/devices/<dev-name>/scrubX +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + The sysfs EDAC bus devices /<dev-name>/scrubX subdirectory + belongs to an instance of memory scrub control feature, + where <dev-name> directory corresponds to a device/memory + region registered with the EDAC device driver for the + scrub control feature. + + The sysfs scrub attr nodes are only present if the parent + driver has implemented the corresponding attr callback + function and provided the necessary operations to the EDAC + device driver during registration. + +What: /sys/bus/edac/devices/<dev-name>/scrubX/addr +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The base address of the memory region to be scrubbed + for on-demand scrubbing. Setting address starts scrubbing. + The size must be set before that. + + The readback addr value is non-zero if the requested + on-demand scrubbing is in progress, zero otherwise. + +What: /sys/bus/edac/devices/<dev-name>/scrubX/size +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The size of the memory region to be scrubbed + (on-demand scrubbing). + +What: /sys/bus/edac/devices/<dev-name>/scrubX/enable_background +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) Start/Stop background (patrol) scrubbing if supported. + +What: /sys/bus/edac/devices/<dev-name>/scrubX/min_cycle_duration +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RO) Supported minimum scrub cycle duration in seconds + by the memory scrubber. + +What: /sys/bus/edac/devices/<dev-name>/scrubX/max_cycle_duration +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RO) Supported maximum scrub cycle duration in seconds + by the memory scrubber. + +What: /sys/bus/edac/devices/<dev-name>/scrubX/current_cycle_duration +Date: March 2025 +KernelVersion: 6.15 +Contact: linux-edac@vger.kernel.org +Description: + (RW) The current scrub cycle duration in seconds and must be + within the supported range by the memory scrubber. + + Scrub has an overhead when running and that may want to be + reduced by taking longer to do it. diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 3e1630c70d8a..59adb7dc6f9e 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -347,7 +347,7 @@ Description: Used to control configure extension list: - [c] means add/del cold file extension What: /sys/fs/f2fs/<disk>/unusable -Date April 2019 +Date: April 2019 Contact: "Daniel Rosenberg" <drosen@google.com> Description: If checkpoint=disable, it displays the number of blocks that are unusable. @@ -355,7 +355,7 @@ Description: If checkpoint=disable, it displays the number of blocks that would be unusable if checkpoint=disable were to be set. What: /sys/fs/f2fs/<disk>/encoding -Date July 2019 +Date: July 2019 Contact: "Daniel Rosenberg" <drosen@google.com> Description: Displays name and version of the encoding set for the filesystem. If no encoding is set, displays (none) @@ -734,6 +734,7 @@ Description: Support configuring fault injection type, should be FAULT_BLKADDR_VALIDITY 0x000040000 FAULT_BLKADDR_CONSISTENCE 0x000080000 FAULT_NO_SEGMENT 0x000100000 + FAULT_INCONSISTENT_FOOTER 0x000200000 =========================== =========== What: /sys/fs/f2fs/<disk>/discard_io_aware_gran @@ -828,3 +829,20 @@ Date: November 2024 Contact: "Chao Yu" <chao@kernel.org> Description: It controls max read extent count for per-inode, the value of threshold is 10240 by default. + +What: /sys/fs/f2fs/tuning/reclaim_caches_kb +Date: February 2025 +Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> +Description: It reclaims the given KBs of file-backed pages registered by + ioctl(F2FS_IOC_DONATE_RANGE). + For example, writing N tries to drop N KBs spaces in LRU. + +What: /sys/fs/f2fs/<disk>/carve_out +Date: March 2025 +Contact: "Daeho Jeong" <daehojeong@google.com> +Description: For several zoned storage devices, vendors will provide extra space which + was used for device level GC than specs and F2FS can use this space for + filesystem level GC. To do that, we can reserve the space using + reserved_blocks. However, it is not enough, since this extra space should + not be shown to users. So, with this new sysfs node, we can hide the space + by substracting reserved_blocks from total bytes. diff --git a/Documentation/ABI/testing/sysfs-kernel-fadump b/Documentation/ABI/testing/sysfs-kernel-fadump index 2f9daa7ca55b..b64b7622e6fc 100644 --- a/Documentation/ABI/testing/sysfs-kernel-fadump +++ b/Documentation/ABI/testing/sysfs-kernel-fadump @@ -55,4 +55,5 @@ Date: May 2024 Contact: linuxppc-dev@lists.ozlabs.org Description: read/write This is a special sysfs file available to setup additional - parameters to be passed to capture kernel. + parameters to be passed to capture kernel. For HASH MMU it + is exported only if RMA size higher than 768MB. 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-platform-mellanox-bootctl b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl index 65ed3865da62..09f783fa0a53 100644 --- a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl +++ b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl @@ -150,3 +150,13 @@ Description: The "mfg_lock" sysfs attribute is write-only. A successful write to this attribute will latch the board-level attributes into EEPROM, making them read-only. + +What: /sys/bus/platform/devices/MLNXBF04:00/rtc_battery +Date: June 2025 +KernelVersion: 6.15 +Contact: "Xiangrong Li <xiangrongl@nvidia.com>" +Description: + The "rtc_battery" sysfs attribute is read-only. + A successful read from this attribute returns the status of + the board's RTC battery. The RTC battery status register is + also cleared upon successful read operation. diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index a3942b1036e2..2192478e83cf 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -131,7 +131,7 @@ Description: CAUTION: Using it will cause your machine's real-time (CMOS) clock to be set to a random invalid time after a resume. -What; /sys/power/pm_trace_dev_match +What: /sys/power/pm_trace_dev_match Date: October 2010 Contact: James Hogan <jhogan@kernel.org> Description: 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/Makefile b/Documentation/Makefile index 52c6c5a3efa9..63094646df28 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -12,7 +12,7 @@ endif # Check for broken ABI files ifeq ($(CONFIG_WARN_ABI_ERRORS),y) -$(shell $(srctree)/scripts/get_abi.pl validate --dir $(srctree)/Documentation/ABI) +$(shell $(srctree)/scripts/get_abi.py --dir $(srctree)/Documentation/ABI validate) endif # You can set these variables from the command line. 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/rcubarrier.rst b/Documentation/RCU/rcubarrier.rst index 6da7f66da2a8..12a7b059654f 100644 --- a/Documentation/RCU/rcubarrier.rst +++ b/Documentation/RCU/rcubarrier.rst @@ -329,10 +329,7 @@ Answer: was first added back in 2005. This is because on_each_cpu() disables preemption, which acted as an RCU read-side critical section, thus preventing CPU 0's grace period from completing - until on_each_cpu() had dealt with all of the CPUs. However, - with the advent of preemptible RCU, rcu_barrier() no longer - waited on nonpreemptible regions of code in preemptible kernels, - that being the job of the new rcu_barrier_sched() function. + until on_each_cpu() had dealt with all of the CPUs. However, with the RCU flavor consolidation around v4.20, this possibility was once again ruled out, because the consolidated diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst index 30080ff6f406..d1ccd6039a8c 100644 --- a/Documentation/RCU/stallwarn.rst +++ b/Documentation/RCU/stallwarn.rst @@ -96,6 +96,13 @@ warnings: the ``rcu_.*timer wakeup didn't happen for`` console-log message, which will include additional debugging information. +- A timer issue causes time to appear to jump forward, so that RCU + believes that the RCU CPU stall-warning timeout has been exceeded + when in fact much less time has passed. This could be due to + timer hardware bugs, timer driver bugs, or even corruption of + the "jiffies" global variable. These sorts of timer hardware + and driver bugs are not uncommon when testing new hardware. + - A low-level kernel issue that either fails to invoke one of the variants of rcu_eqs_enter(true), rcu_eqs_exit(true), ct_idle_enter(), ct_idle_exit(), ct_irq_enter(), or ct_irq_exit() on the one 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/README.rst b/Documentation/admin-guide/README.rst index eb9452668909..70b02f30013a 100644 --- a/Documentation/admin-guide/README.rst +++ b/Documentation/admin-guide/README.rst @@ -165,7 +165,7 @@ Configuring the kernel "make xconfig" Qt based configuration tool. - "make gconfig" GTK+ based configuration tool. + "make gconfig" GTK based configuration tool. "make oldconfig" Default all questions based on the contents of your existing ./.config file and asking about @@ -176,7 +176,7 @@ Configuring the kernel values without prompting. "make defconfig" Create a ./.config file by using the default - symbol values from either arch/$ARCH/defconfig + symbol values from either arch/$ARCH/configs/defconfig or arch/$ARCH/configs/${PLATFORM}_defconfig, depending on the architecture. diff --git a/Documentation/admin-guide/abi-obsolete-files.rst b/Documentation/admin-guide/abi-obsolete-files.rst new file mode 100644 index 000000000000..3061a916b4b5 --- /dev/null +++ b/Documentation/admin-guide/abi-obsolete-files.rst @@ -0,0 +1,7 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Obsolete ABI Files +================== + +.. kernel-abi:: obsolete + :no-symbols: diff --git a/Documentation/admin-guide/abi-obsolete.rst b/Documentation/admin-guide/abi-obsolete.rst index 594e697aa1b2..640f3903e847 100644 --- a/Documentation/admin-guide/abi-obsolete.rst +++ b/Documentation/admin-guide/abi-obsolete.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + ABI obsolete symbols ==================== @@ -7,5 +9,5 @@ marked to be removed at some later point in time. The description of the interface will document the reason why it is obsolete and when it can be expected to be removed. -.. kernel-abi:: ABI/obsolete - :rst: +.. kernel-abi:: obsolete + :no-files: diff --git a/Documentation/admin-guide/abi-removed-files.rst b/Documentation/admin-guide/abi-removed-files.rst new file mode 100644 index 000000000000..f1bdfadd2ec4 --- /dev/null +++ b/Documentation/admin-guide/abi-removed-files.rst @@ -0,0 +1,7 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Removed ABI Files +================= + +.. kernel-abi:: removed + :no-symbols: diff --git a/Documentation/admin-guide/abi-removed.rst b/Documentation/admin-guide/abi-removed.rst index f9e000c81828..88832d3eacd6 100644 --- a/Documentation/admin-guide/abi-removed.rst +++ b/Documentation/admin-guide/abi-removed.rst @@ -1,5 +1,7 @@ +.. SPDX-License-Identifier: GPL-2.0 + ABI removed symbols =================== -.. kernel-abi:: ABI/removed - :rst: +.. kernel-abi:: removed + :no-files: diff --git a/Documentation/admin-guide/abi-stable-files.rst b/Documentation/admin-guide/abi-stable-files.rst new file mode 100644 index 000000000000..f867738fc178 --- /dev/null +++ b/Documentation/admin-guide/abi-stable-files.rst @@ -0,0 +1,7 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Stable ABI Files +================ + +.. kernel-abi:: stable + :no-symbols: diff --git a/Documentation/admin-guide/abi-stable.rst b/Documentation/admin-guide/abi-stable.rst index fc3361d847b1..528c68401f4b 100644 --- a/Documentation/admin-guide/abi-stable.rst +++ b/Documentation/admin-guide/abi-stable.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + ABI stable symbols ================== @@ -10,5 +12,5 @@ for at least 2 years. Most interfaces (like syscalls) are expected to never change and always be available. -.. kernel-abi:: ABI/stable - :rst: +.. kernel-abi:: stable + :no-files: diff --git a/Documentation/admin-guide/abi-testing-files.rst b/Documentation/admin-guide/abi-testing-files.rst new file mode 100644 index 000000000000..1da868e42fdb --- /dev/null +++ b/Documentation/admin-guide/abi-testing-files.rst @@ -0,0 +1,7 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Testing ABI Files +================= + +.. kernel-abi:: testing + :no-symbols: diff --git a/Documentation/admin-guide/abi-testing.rst b/Documentation/admin-guide/abi-testing.rst index 19767926b344..6153ebd38e2d 100644 --- a/Documentation/admin-guide/abi-testing.rst +++ b/Documentation/admin-guide/abi-testing.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + ABI testing symbols =================== @@ -16,5 +18,5 @@ Programs that use these interfaces are strongly encouraged to add their name to the description of these interfaces, so that the kernel developers can easily notify them if any changes occur. -.. kernel-abi:: ABI/testing - :rst: +.. kernel-abi:: testing + :no-files: diff --git a/Documentation/admin-guide/abi.rst b/Documentation/admin-guide/abi.rst index bcab3ef2597c..c6039359e585 100644 --- a/Documentation/admin-guide/abi.rst +++ b/Documentation/admin-guide/abi.rst @@ -1,7 +1,14 @@ +.. SPDX-License-Identifier: GPL-2.0 + ===================== Linux ABI description ===================== +.. kernel-abi:: README + +ABI symbols +----------- + .. toctree:: :maxdepth: 2 @@ -9,3 +16,14 @@ Linux ABI description abi-testing abi-obsolete abi-removed + +ABI files +--------- + +.. toctree:: + :maxdepth: 2 + + abi-stable-files + abi-testing-files + abi-obsolete-files + abi-removed-files 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/freezer-subsystem.rst b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst index 582d3427de3f..a964aff373b1 100644 --- a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst +++ b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst @@ -125,3 +125,7 @@ to unfreeze all tasks in the container:: This is the basic mechanism which should do the right thing for user space task in a simple scenario. + +This freezer implementation is affected by shortcomings (see commit +76f969e8948d8 ("cgroup: cgroup v2 freezer")) and cgroup v2 freezer is +recommended. diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index 286d16fc22eb..d6b1db8cc7eb 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst @@ -90,6 +90,7 @@ Brief summary of control files. used. memory.swappiness set/show swappiness parameter of vmscan (See sysctl's vm.swappiness) + Per memcg knob does not exist in cgroup v2. memory.move_charge_at_immigrate This knob is deprecated. memory.oom_control set/show oom controls. This knob is deprecated and shouldn't be @@ -609,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 cb1b4e759b7e..1a16ce68a4d7 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1076,15 +1076,20 @@ cpufreq governor about the minimum desired frequency which should always be provided by a CPU, as well as the maximum desired frequency, which should not be exceeded by a CPU. -WARNING: cgroup2 doesn't yet support control of realtime processes. For -a kernel built with the CONFIG_RT_GROUP_SCHED option enabled for group -scheduling of realtime processes, the cpu controller can only be enabled -when all RT processes are in the root cgroup. This limitation does -not apply if CONFIG_RT_GROUP_SCHED is disabled. Be aware that system -management software may already have placed RT processes into nonroot -cgroups during the system boot process, and these processes may need -to be moved to the root cgroup before the cpu controller can be enabled -with a CONFIG_RT_GROUP_SCHED enabled kernel. +WARNING: cgroup2 cpu controller doesn't yet fully support the control of +realtime processes. For a kernel built with the CONFIG_RT_GROUP_SCHED option +enabled for group scheduling of realtime processes, the cpu controller can only +be enabled when all RT processes are in the root cgroup. Be aware that system +management software may already have placed RT processes into non-root cgroups +during the system boot process, and these processes may need to be moved to the +root cgroup before the cpu controller can be enabled with a +CONFIG_RT_GROUP_SCHED enabled kernel. + +With CONFIG_RT_GROUP_SCHED disabled, this limitation does not apply and some of +the interface files either affect realtime processes or account for them. See +the following section for details. Only the cpu controller is affected by +CONFIG_RT_GROUP_SCHED. Other controllers can be used for the resource control of +realtime processes irrespective of CONFIG_RT_GROUP_SCHED. CPU Interface Files @@ -1440,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, @@ -1483,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 @@ -1555,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) @@ -1570,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 @@ -1579,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 @@ -1656,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/ext4.rst b/Documentation/admin-guide/ext4.rst index 2418b0c2d3df..b857eb6ca1b6 100644 --- a/Documentation/admin-guide/ext4.rst +++ b/Documentation/admin-guide/ext4.rst @@ -238,11 +238,10 @@ When mounting an ext4 filesystem, the following option are accepted: configured using tune2fs) data_err=ignore(*) - Just print an error message if an error occurs in a file data buffer in - ordered mode. + Just print an error message if an error occurs in a file data buffer. + data_err=abort - Abort the journal if an error occurs in a file data buffer in ordered - mode. + Abort the journal if an error occurs in a file data buffer. grpid | bsdgroups New objects have the group ID of their parent. diff --git a/Documentation/admin-guide/gpio/gpio-sim.rst b/Documentation/admin-guide/gpio/gpio-sim.rst index 1cc5567a4bbe..35d49ccd49e0 100644 --- a/Documentation/admin-guide/gpio/gpio-sim.rst +++ b/Documentation/admin-guide/gpio/gpio-sim.rst @@ -71,7 +71,7 @@ specific lines. The name of those subdirectories must take the form of: ``'line<offset>'`` (e.g. ``'line0'``, ``'line20'``, etc.) as the name will be used by the module to assign the config to the specific line at given offset. -Once the confiuration is complete, the ``'live'`` attribute must be set to 1 in +Once the configuration is complete, the ``'live'`` attribute must be set to 1 in order to instantiate the chip. It can be set back to 0 to destroy the simulated chip. The module will synchronously wait for the new simulated device to be successfully probed and if this doesn't happen, writing to ``'live'`` will diff --git a/Documentation/admin-guide/gpio/gpio-virtuser.rst b/Documentation/admin-guide/gpio/gpio-virtuser.rst index 2aca70db9f3b..7e7c0df51640 100644 --- a/Documentation/admin-guide/gpio/gpio-virtuser.rst +++ b/Documentation/admin-guide/gpio/gpio-virtuser.rst @@ -92,7 +92,7 @@ struct. The first two take string values as arguments: Activating GPIO consumers ------------------------- -Once the confiuration is complete, the ``'live'`` attribute must be set to 1 in +Once the configuration is complete, the ``'live'`` attribute must be set to 1 in order to instantiate the consumer. It can be set back to 0 to destroy the virtual device. The module will synchronously wait for the new simulated device to be successfully probed and if this doesn't happen, writing to ``'live'`` will diff --git a/Documentation/admin-guide/highuid.rst b/Documentation/admin-guide/highuid.rst deleted file mode 100644 index 6ee70465c0ea..000000000000 --- a/Documentation/admin-guide/highuid.rst +++ /dev/null @@ -1,80 +0,0 @@ -=================================================== -Notes on the change from 16-bit UIDs to 32-bit UIDs -=================================================== - -:Author: Chris Wing <wingc@umich.edu> -:Last updated: January 11, 2000 - -- kernel code MUST take into account __kernel_uid_t and __kernel_uid32_t - when communicating between user and kernel space in an ioctl or data - structure. - -- kernel code should use uid_t and gid_t in kernel-private structures and - code. - -What's left to be done for 32-bit UIDs on all Linux architectures: - -- Disk quotas have an interesting limitation that is not related to the - maximum UID/GID. They are limited by the maximum file size on the - underlying filesystem, because quota records are written at offsets - corresponding to the UID in question. - Further investigation is needed to see if the quota system can cope - properly with huge UIDs. If it can deal with 64-bit file offsets on all - architectures, this should not be a problem. - -- Decide whether or not to keep backwards compatibility with the system - accounting file, or if we should break it as the comments suggest - (currently, the old 16-bit UID and GID are still written to disk, and - part of the former pad space is used to store separate 32-bit UID and - GID) - -- Need to validate that OS emulation calls the 16-bit UID - compatibility syscalls, if the OS being emulated used 16-bit UIDs, or - uses the 32-bit UID system calls properly otherwise. - - This affects at least: - - - iBCS on Intel - - - sparc32 emulation on sparc64 - (need to support whatever new 32-bit UID system calls are added to - sparc32) - -- Validate that all filesystems behave properly. - - At present, 32-bit UIDs _should_ work for: - - - ext2 - - ufs - - isofs - - nfs - - coda - - udf - - Ioctl() fixups have been made for: - - - ncpfs - - smbfs - - Filesystems with simple fixups to prevent 16-bit UID wraparound: - - - minix - - sysv - - qnx4 - - Other filesystems have not been checked yet. - -- The ncpfs and smpfs filesystems cannot presently use 32-bit UIDs in - all ioctl()s. Some new ioctl()s have been added with 32-bit UIDs, but - more are needed. (as well as new user<->kernel data structures) - -- The ELF core dump format only supports 16-bit UIDs on arm, i386, m68k, - sh, and sparc32. Fixing this is probably not that important, but would - require adding a new ELF section. - -- The ioctl()s used to control the in-kernel NFS server only support - 16-bit UIDs on arm, i386, m68k, sh, and sparc32. - -- make sure that the UID mapping feature of AX25 networking works properly - (it should be safe because it's always used a 32-bit integer to - communicate between user and kernel) diff --git a/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst index 0585d02b9a6c..ad15417d39f9 100644 --- a/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst +++ b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst @@ -29,14 +29,6 @@ Below is the list of affected Intel processors [#f1]_: RAPTORLAKE_S 06_BFH =================== ============ -As an exception to this table, Intel Xeon E family parts ALDERLAKE(06_97H) and -RAPTORLAKE(06_B7H) codenamed Catlow are not affected. They are reported as -vulnerable in Linux because they share the same family/model with an affected -part. Unlike their affected counterparts, they do not enumerate RFDS_CLEAR or -CPUID.HYBRID. This information could be used to distinguish between the -affected and unaffected parts, but it is deemed not worth adding complexity as -the reporting is fixed automatically when these parts enumerate RFDS_NO. - Mitigation ========== Intel released a microcode update that enables software to clear sensitive diff --git a/Documentation/admin-guide/hw-vuln/srso.rst b/Documentation/admin-guide/hw-vuln/srso.rst index 2ad1c05b8c88..66af95251a3d 100644 --- a/Documentation/admin-guide/hw-vuln/srso.rst +++ b/Documentation/admin-guide/hw-vuln/srso.rst @@ -104,7 +104,20 @@ The possible values in this file are: (spec_rstack_overflow=ibpb-vmexit) + * 'Mitigation: Reduced Speculation': + This mitigation gets automatically enabled when the above one "IBPB on + VMEXIT" has been selected and the CPU supports the BpSpecReduce bit. + + It gets automatically enabled on machines which have the + SRSO_USER_KERNEL_NO=1 CPUID bit. In that case, the code logic is to switch + to the above =ibpb-vmexit mitigation because the user/kernel boundary is + not affected anymore and thus "safe RET" is not needed. + + After enabling the IBPB on VMEXIT mitigation option, the BpSpecReduce bit + is detected (functionality present on all such machines) and that + practically overrides IBPB on VMEXIT as it has a lot less performance + impact and takes care of the guest->host attack vector too. In order to exploit vulnerability, an attacker needs to: diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index c8af32a8f800..259d79fbeb94 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -187,7 +187,6 @@ A few hard-to-categorize and generally obsolete documents. .. toctree:: :maxdepth: 1 - highuid ldm unicode diff --git a/Documentation/admin-guide/iostats.rst b/Documentation/admin-guide/iostats.rst index 609a3201fd4e..9453196ade51 100644 --- a/Documentation/admin-guide/iostats.rst +++ b/Documentation/admin-guide/iostats.rst @@ -2,62 +2,39 @@ I/O statistics fields ===================== -Since 2.4.20 (and some versions before, with patches), and 2.5.45, -more extensive disk statistics have been introduced to help measure disk -activity. Tools such as ``sar`` and ``iostat`` typically interpret these and do -the work for you, but in case you are interested in creating your own -tools, the fields are explained here. - -In 2.4 now, the information is found as additional fields in -``/proc/partitions``. In 2.6 and upper, the same information is found in two -places: one is in the file ``/proc/diskstats``, and the other is within -the sysfs file system, which must be mounted in order to obtain -the information. Throughout this document we'll assume that sysfs -is mounted on ``/sys``, although of course it may be mounted anywhere. -Both ``/proc/diskstats`` and sysfs use the same source for the information -and so should not differ. - -Here are examples of these different formats:: - - 2.4: - 3 0 39082680 hda 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160 - 3 1 9221278 hda1 35486 0 35496 38030 0 0 0 0 0 38030 38030 - - 2.6+ sysfs: - 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160 - 35486 38030 38030 38030 - - 2.6+ diskstats: - 3 0 hda 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160 - 3 1 hda1 35486 38030 38030 38030 - - 4.18+ diskstats: - 3 0 hda 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160 0 0 0 0 - -On 2.4 you might execute ``grep 'hda ' /proc/partitions``. On 2.6+, you have -a choice of ``cat /sys/block/hda/stat`` or ``grep 'hda ' /proc/diskstats``. - -The advantage of one over the other is that the sysfs choice works well -if you are watching a known, small set of disks. ``/proc/diskstats`` may -be a better choice if you are watching a large number of disks because -you'll avoid the overhead of 50, 100, or 500 or more opens/closes with -each snapshot of your disk statistics. - -In 2.4, the statistics fields are those after the device name. In -the above example, the first field of statistics would be 446216. -By contrast, in 2.6+ if you look at ``/sys/block/hda/stat``, you'll -find just the 15 fields, beginning with 446216. If you look at -``/proc/diskstats``, the 15 fields will be preceded by the major and -minor device numbers, and device name. Each of these formats provides -15 fields of statistics, each meaning exactly the same things. -All fields except field 9 are cumulative since boot. Field 9 should -go to zero as I/Os complete; all others only increase (unless they -overflow and wrap). Wrapping might eventually occur on a very busy -or long-lived system; so applications should be prepared to deal with -it. Regarding wrapping, the types of the fields are either unsigned -int (32 bit) or unsigned long (32-bit or 64-bit, depending on your -machine) as noted per-field below. Unless your observations are very -spread in time, these fields should not wrap twice before you notice it. +The kernel exposes disk statistics via ``/proc/diskstats`` and +``/sys/block/<device>/stat``. These stats are usually accessed via tools +such as ``sar`` and ``iostat``. + +Here are examples using a disk with two partitions:: + + /proc/diskstats: + 259 0 nvme0n1 255999 814 12369153 47919 996852 81 36123024 425995 0 301795 580470 0 0 0 0 60602 106555 + 259 1 nvme0n1p1 492 813 17572 96 848 81 108288 210 0 76 307 0 0 0 0 0 0 + 259 2 nvme0n1p2 255401 1 12343477 47799 996004 0 36014736 425784 0 344336 473584 0 0 0 0 0 0 + + /sys/block/nvme0n1/stat: + 255999 814 12369153 47919 996858 81 36123056 426009 0 301809 580491 0 0 0 0 60605 106562 + + /sys/block/nvme0n1/nvme0n1p1/stat: + 492 813 17572 96 848 81 108288 210 0 76 307 0 0 0 0 0 0 + +Both files contain the same 17 statistics. ``/sys/block/<device>/stat`` +contains the fields for ``<device>``. In ``/proc/diskstats`` the fields +are prefixed with the major and minor device numbers and the device +name. In the example above, the first stat value for ``nvme0n1`` is +255999 in both files. + +The sysfs ``stat`` file is efficient for monitoring a small, known set +of disks. If you're tracking a large number of devices, +``/proc/diskstats`` is often the better choice since it avoids the +overhead of opening and closing multiple files for each snapshot. + +All fields are cumulative, monotonic counters, except for field 9, which +resets to zero as I/Os complete. The remaining fields reset at boot, on +device reattachment or reinitialization, or when the underlying counter +overflows. Applications reading these counters should detect and handle +resets when comparing stat snapshots. Each set of stats only applies to the indicated device; if you want system-wide stats you'll have to find all the devices and sum them all up. diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst index 5376890adbeb..1f7f14c6e184 100644 --- a/Documentation/admin-guide/kdump/kdump.rst +++ b/Documentation/admin-guide/kdump/kdump.rst @@ -180,10 +180,6 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64) 1) On i386, enable high memory support under "Processor type and features":: - CONFIG_HIGHMEM64G=y - - or:: - CONFIG_HIGHMEM4G 2) With CONFIG_SMP=y, usually nr_cpus=1 need specified on the kernel diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index fb8752b42ec8..76e538c77e31 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -416,10 +416,6 @@ Format: { quiet (default) | verbose | debug } Change the amount of debugging information output when initialising the APIC and IO-APIC components. - For X86-32, this can also be used to specify an APIC - driver name. - Format: apic=driver_name - Examples: apic=bigsmp apic_extnmi= [APIC,X86,EARLY] External NMI delivery setting Format: { bsp (default) | all | none } @@ -1411,14 +1407,21 @@ earlyprintk=serial[,0x...[,baudrate]] earlyprintk=ttySn[,baudrate] earlyprintk=dbgp[debugController#] - earlyprintk=pciserial[,force],bus:device.function[,baudrate] + earlyprintk=pciserial[,force],bus:device.function[,{nocfg|baudrate}] earlyprintk=xdbc[xhciController#] earlyprintk=bios + earlyprintk=mmio,membase[,{nocfg|baudrate}] earlyprintk is useful when the kernel crashes before the normal console is initialized. It is not enabled by default because it has some cosmetic problems. + Only 32-bit memory addresses are supported for "mmio" + and "pciserial" devices. + + 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. @@ -1785,7 +1788,9 @@ allocation boundaries as a proactive defense against bounds-checking flaws in the kernel's copy_to_user()/copy_from_user() interface. - on Perform hardened usercopy checks (default). + The default is determined by + CONFIG_HARDENED_USERCOPY_DEFAULT_ON. + on Perform hardened usercopy checks. off Disable hardened usercopy checks. hardlockup_all_cpu_backtrace= @@ -1861,7 +1866,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 @@ -1873,15 +1878,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. @@ -1892,6 +1906,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. @@ -1933,6 +1954,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. @@ -2316,6 +2343,9 @@ per_cpu_perf_limits Allow per-logical-CPU P-State performance control limits using cpufreq sysfs interface + no_cas + Do not enable capacity-aware scheduling (CAS) on + hybrid systems intremap= [X86-64,Intel-IOMMU,EARLY] on enable Interrupt Remapping (default) @@ -3116,6 +3146,8 @@ * max_sec_lba48: Set or clear transfer size limit to 65535 sectors. + * external: Mark port as external (hotplug-capable). + * [no]lpm: Enable or disable link power management. * [no]setxfer: Indicate if transfer speed mode setting @@ -4233,10 +4265,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. @@ -5017,6 +5049,14 @@ Format: <bool> default: 0 (auto_verbose is enabled) + printk.debug_non_panic_cpus= + Allows storing messages from non-panic CPUs into + the printk log buffer during panic(). They are + flushed to consoles by the panic-CPU on + a best-effort basis. + Format: <bool> (1/Y/y=enable, 0/N/n=disable) + Default: disabled + printk.devkmsg={on,off,ratelimit} Control writing to /dev/kmsg. on - unlimited logging to /dev/kmsg from userspace @@ -5758,6 +5798,11 @@ rcutorture.test_boost_duration= [KNL] Duration (s) of each individual boost test. + rcutorture.test_boost_holdoff= [KNL] + Holdoff time (s) from start of test to the start + of RCU priority-boost testing. Defaults to zero, + that is, no holdoff. + rcutorture.test_boost_interval= [KNL] Interval (s) between each boost test. @@ -6082,7 +6127,7 @@ is assumed to be I/O ports; otherwise it is memory. reserve_mem= [RAM] - Format: nn[KNG]:<align>:<label> + Format: nn[KMG]:<align>:<label> Reserve physical memory and label it with a name that other subsystems can use to access it. This is typically used for systems that do not wipe the RAM, and this command @@ -6582,6 +6627,8 @@ Selecting 'on' will also enable the mitigation against user space to user space task attacks. + Selecting specific mitigation does not force enable + user mitigations. Selecting 'off' will disable both the kernel and the user space protections. @@ -7241,6 +7288,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 @@ -7279,6 +7328,15 @@ See also "Event triggers" in Documentation/trace/events.rst + traceoff_after_boot + [FTRACE] Sometimes tracing is used to debug issues + during the boot process. Since the trace buffer has a + limited amount of storage, it may be prudent to + disable tracing after the boot is finished, otherwise + the critical information may be overwritten. With this + option, the main tracing buffer will be turned off at + the end of the boot process. + traceoff_on_warning [FTRACE] enable this option to disable tracing when a warning is hit. This turns off "tracing_on". Tracing can @@ -7477,6 +7535,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. @@ -7672,13 +7746,6 @@ 16 - SIGBUS faults Example: user_debug=31 - userpte= - [X86,EARLY] Flags controlling user PTE allocations. - - nohigh = do not allocate PTE pages in - HIGHMEM regardless of setting - of CONFIG_HIGHPTE. - vdso= [X86,SH,SPARC] On X86_32, this is an alias for vdso32=. Otherwise: diff --git a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst index ea7fa2a8bbf0..ee9a6c94f383 100644 --- a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst +++ b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst @@ -278,12 +278,7 @@ To reduce its OS jitter, do any of the following: due to the rtas_event_scan() function. WARNING: Please check your CPU specifications to make sure that this is safe on your particular system. - e. If running on Cell Processor, build your kernel with - CBE_CPUFREQ_SPU_GOVERNOR=n to avoid OS jitter from - spu_gov_work(). - WARNING: Please check your CPU specifications to - make sure that this is safe on your particular system. - f. If running on PowerMAC, build your kernel with + e. If running on PowerMAC, build your kernel with CONFIG_PMAC_RACKMETER=n to disable the CPU-meter, avoiding OS jitter from rackmeter_do_timer(). diff --git a/Documentation/admin-guide/laptops/index.rst b/Documentation/admin-guide/laptops/index.rst index cd9a1c2695fd..e71c8984c23e 100644 --- a/Documentation/admin-guide/laptops/index.rst +++ b/Documentation/admin-guide/laptops/index.rst @@ -11,6 +11,7 @@ Laptop Drivers disk-shock-protection laptop-mode lg-laptop + samsung-galaxybook sony-laptop sonypi thinkpad-acpi diff --git a/Documentation/admin-guide/laptops/samsung-galaxybook.rst b/Documentation/admin-guide/laptops/samsung-galaxybook.rst new file mode 100644 index 000000000000..752b8f1a4a74 --- /dev/null +++ b/Documentation/admin-guide/laptops/samsung-galaxybook.rst @@ -0,0 +1,174 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +========================== +Samsung Galaxy Book Driver +========================== + +Joshua Grisham <josh@joshuagrisham.com> + +This is a Linux x86 platform driver for Samsung Galaxy Book series notebook +devices which utilizes Samsung's ``SCAI`` ACPI device in order to control +extra features and receive various notifications. + +Supported devices +================= + +Any device with one of the supported ACPI device IDs should be supported. This +covers most of the "Samsung Galaxy Book" series notebooks that are currently +available as of this writing, and could include other Samsung notebook devices +as well. + +Status +====== + +The following features are currently supported: + +- :ref:`Keyboard backlight <keyboard-backlight>` control +- :ref:`Performance mode <performance-mode>` control implemented using the + platform profile interface +- :ref:`Battery charge control end threshold + <battery-charge-control-end-threshold>` (stop charging battery at given + percentage value) implemented as a battery hook +- :ref:`Firmware Attributes <firmware-attributes>` to allow control of various + device settings +- :ref:`Handling of Fn hotkeys <keyboard-hotkey-actions>` for various actions +- :ref:`Handling of ACPI notifications and hotkeys + <acpi-notifications-and-hotkey-actions>` + +Because different models of these devices can vary in their features, there is +logic built within the driver which attempts to test each implemented feature +for a valid response before enabling its support (registering additional devices +or extensions, adding sysfs attributes, etc). Therefore, it can be important to +note that not all features may be supported for your particular device. + +The following features might be possible to implement but will require +additional investigation and are therefore not supported at this time: + +- "Dolby Atmos" mode for the speakers +- "Outdoor Mode" for increasing screen brightness on models with ``SAM0427`` +- "Silent Mode" on models with ``SAM0427`` + +.. _keyboard-backlight: + +Keyboard backlight +================== + +A new LED class named ``samsung-galaxybook::kbd_backlight`` is created which +will then expose the device using the standard sysfs-based LED interface at +``/sys/class/leds/samsung-galaxybook::kbd_backlight``. Brightness can be +controlled by writing the desired value to the ``brightness`` sysfs attribute or +with any other desired userspace utility. + +.. note:: + Most of these devices have an ambient light sensor which also turns + off the keyboard backlight under well-lit conditions. This behavior does not + seem possible to control at this time, but can be good to be aware of. + +.. _performance-mode: + +Performance mode +================ + +This driver implements the +Documentation/userspace-api/sysfs-platform_profile.rst interface for working +with the "performance mode" function of the Samsung ACPI device. + +Mapping of each Samsung "performance mode" to its respective platform profile is +performed dynamically by the driver, as not all models support all of the same +performance modes. Your device might have one or more of the following mappings: + +- "Silent" maps to ``low-power`` +- "Quiet" maps to ``quiet`` +- "Optimized" maps to ``balanced`` +- "High performance" maps to ``performance`` + +The result of the mapping can be printed in the kernel log when the module is +loaded. Supported profiles can also be retrieved from +``/sys/firmware/acpi/platform_profile_choices``, while +``/sys/firmware/acpi/platform_profile`` can be used to read or write the +currently selected profile. + +The ``balanced`` platform profile will be set during module load if no profile +has been previously set. + +.. _battery-charge-control-end-threshold: + +Battery charge control end threshold +==================================== + +This platform driver will add the ability to set the battery's charge control +end threshold, but does not have the ability to set a start threshold. + +This feature is typically called "Battery Saver" by the various Samsung +applications in Windows, but in Linux we have implemented the standardized +"charge control threshold" sysfs interface on the battery device to allow for +controlling this functionality from the userspace. + +The sysfs attribute +``/sys/class/power_supply/BAT1/charge_control_end_threshold`` can be used to +read or set the desired charge end threshold. + +If you wish to maintain interoperability with the Samsung Settings application +in Windows, then you should set the value to 100 to represent "off", or enable +the feature using only one of the following values: 50, 60, 70, 80, or 90. +Otherwise, the driver will accept any value between 1 and 100 as the percentage +that you wish the battery to stop charging at. + +.. note:: + Some devices have been observed as automatically "turning off" the charge + control end threshold if an input value of less than 30 is given. + +.. _firmware-attributes: + +Firmware Attributes +=================== + +The following enumeration-typed firmware attributes are set up by this driver +and should be accessible under +``/sys/class/firmware-attributes/samsung-galaxybook/attributes/`` if your device +supports them: + +- ``power_on_lid_open`` (device should power on when the lid is opened) +- ``usb_charging`` (USB ports can deliver power to connected devices even when + the device is powered off or in a low sleep state) +- ``block_recording`` (blocks access to camera and microphone) + +All of these attributes are simple boolean-like enumeration values which use 0 +to represent "off" and 1 to represent "on". Use the ``current_value`` attribute +to get or change the setting on the device. + +Note that when ``block_recording`` is updated, the input device "Samsung Galaxy +Book Lens Cover" will receive a ``SW_CAMERA_LENS_COVER`` switch event which +reflects the current state. + +.. _keyboard-hotkey-actions: + +Keyboard hotkey actions (i8042 filter) +====================================== + +The i8042 filter will swallow the keyboard events for the Fn+F9 hotkey (Multi- +level keyboard backlight toggle) and Fn+F10 hotkey (Block recording toggle) +and instead execute their actions within the driver itself. + +Fn+F9 will cycle through the brightness levels of the keyboard backlight. A +notification will be sent using ``led_classdev_notify_brightness_hw_changed`` +so that the userspace can be aware of the change. This mimics the behavior of +other existing devices where the brightness level is cycled internally by the +embedded controller and then reported via a notification. + +Fn+F10 will toggle the value of the "block recording" setting, which blocks +or allows usage of the built-in camera and microphone (and generates the same +Lens Cover switch event mentioned above). + +.. _acpi-notifications-and-hotkey-actions: + +ACPI notifications and hotkey actions +===================================== + +ACPI notifications will generate ACPI netlink events under the device class +``samsung-galaxybook`` and bus ID matching the Samsung ACPI device ID found on +your device. The events can be received using userspace tools such as +``acpi_listen`` and ``acpid``. + +The Fn+F11 Performance mode hotkey will be handled by the driver; each keypress +will cycle to the next available platform profile. diff --git a/Documentation/admin-guide/media/cec.rst b/Documentation/admin-guide/media/cec.rst index 92690e1f2183..b2e7a300494a 100644 --- a/Documentation/admin-guide/media/cec.rst +++ b/Documentation/admin-guide/media/cec.rst @@ -451,7 +451,7 @@ configure the CEC devices for HDMI Input and the HDMI Outputs manually. --------------------- A three character manufacturer name that is used in the EDID for the HDMI -Input. If not set, then userspace is reponsible for configuring an EDID. +Input. If not set, then userspace is responsible for configuring an EDID. If set, then the driver will update the EDID automatically based on the resolutions supported by the connected displays, and it will not be possible anymore to manually set the EDID for the HDMI Input. diff --git a/Documentation/admin-guide/media/mgb4.rst b/Documentation/admin-guide/media/mgb4.rst index b9da127c074d..f69d331e3cb1 100644 --- a/Documentation/admin-guide/media/mgb4.rst +++ b/Documentation/admin-guide/media/mgb4.rst @@ -22,7 +22,9 @@ Global (PCI card) parameters | 0 - No module present | 1 - FPDL3 - | 2 - GMSL + | 2 - GMSL (one serializer, two daisy chained deserializers) + | 3 - GMSL (one serializer, two deserializers) + | 4 - GMSL (two deserializers with two daisy chain outputs) **module_version** (R): Module version number. Zero in case of a missing module. 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/pm/cpufreq.rst b/Documentation/admin-guide/pm/cpufreq.rst index a21369eba034..3950583f2b15 100644 --- a/Documentation/admin-guide/pm/cpufreq.rst +++ b/Documentation/admin-guide/pm/cpufreq.rst @@ -248,6 +248,20 @@ are the following: If that frequency cannot be determined, this attribute should not be present. +``cpuinfo_avg_freq`` + An average frequency (in KHz) of all CPUs belonging to a given policy, + derived from a hardware provided feedback and reported on a time frame + spanning at most few milliseconds. + + This is expected to be based on the frequency the hardware actually runs + at and, as such, might require specialised hardware support (such as AMU + extension on ARM). If one cannot be determined, this attribute should + not be present. + + Note, that failed attempt to retrieve current frequency for a given + CPU(s) will result in an appropriate error, i.e: EAGAIN for CPU that + remains idle (raised on ARM). + ``cpuinfo_max_freq`` Maximum possible operating frequency the CPUs belonging to this policy can run at (in kHz). @@ -293,7 +307,8 @@ are the following: Some architectures (e.g. ``x86``) may attempt to provide information more precisely reflecting the current CPU frequency through this attribute, but that still may not be the exact current CPU frequency as - seen by the hardware at the moment. + seen by the hardware at the moment. This behavior though, is only + available via c:macro:``CPUFREQ_ARCH_CUR_FREQ`` option. ``scaling_driver`` The scaling driver currently in use. diff --git a/Documentation/admin-guide/pm/cpuidle.rst b/Documentation/admin-guide/pm/cpuidle.rst index eb58d7a5affd..0c090b076224 100644 --- a/Documentation/admin-guide/pm/cpuidle.rst +++ b/Documentation/admin-guide/pm/cpuidle.rst @@ -275,20 +275,25 @@ values and, when predicting the idle duration next time, it computes the average and variance of them. If the variance is small (smaller than 400 square milliseconds) or it is small relative to the average (the average is greater that 6 times the standard deviation), the average is regarded as the "typical -interval" value. Otherwise, the longest of the saved observed idle duration +interval" value. Otherwise, either the longest or the shortest (depending on +which one is farther from the average) of the saved observed idle duration values is discarded and the computation is repeated for the remaining ones. + Again, if the variance of them is small (in the above sense), the average is taken as the "typical interval" value and so on, until either the "typical -interval" is determined or too many data points are disregarded, in which case -the "typical interval" is assumed to equal "infinity" (the maximum unsigned -integer value). - -If the "typical interval" computed this way is long enough, the governor obtains -the time until the closest timer event with the assumption that the scheduler -tick will be stopped. That time, referred to as the *sleep length* in what follows, -is the upper bound on the time before the next CPU wakeup. It is used to determine -the sleep length range, which in turn is needed to get the sleep length correction -factor. +interval" is determined or too many data points are disregarded. In the latter +case, if the size of the set of data points still under consideration is +sufficiently large, the next idle duration is not likely to be above the largest +idle duration value still in that set, so that value is taken as the predicted +next idle duration. Finally, if the set of data points still under +consideration is too small, no prediction is made. + +If the preliminary prediction of the next idle duration computed this way is +long enough, the governor obtains the time until the closest timer event with +the assumption that the scheduler tick will be stopped. That time, referred to +as the *sleep length* in what follows, is the upper bound on the time before the +next CPU wakeup. It is used to determine the sleep length range, which in turn +is needed to get the sleep length correction factor. The ``menu`` governor maintains an array containing several correction factor values that correspond to different sleep length ranges organized so that each @@ -302,7 +307,7 @@ to 1 the correction factor becomes (it must fall between 0 and 1 inclusive). The sleep length is multiplied by the correction factor for the range that it falls into to obtain an approximation of the predicted idle duration that is compared to the "typical interval" determined previously and the minimum of -the two is taken as the idle duration prediction. +the two is taken as the final idle duration prediction. If the "typical interval" value is small, which means that the CPU is likely to be woken up soon enough, the sleep length computation is skipped as it may diff --git a/Documentation/admin-guide/pm/intel_idle.rst b/Documentation/admin-guide/pm/intel_idle.rst index 39bd6ecce7de..5940528146eb 100644 --- a/Documentation/admin-guide/pm/intel_idle.rst +++ b/Documentation/admin-guide/pm/intel_idle.rst @@ -192,11 +192,19 @@ even if they have been enumerated (see :ref:`cpu-pm-qos` in Documentation/admin-guide/pm/cpuidle.rst). Setting ``max_cstate`` to 0 causes the ``intel_idle`` initialization to fail. -The ``no_acpi`` and ``use_acpi`` module parameters (recognized by ``intel_idle`` -if the kernel has been configured with ACPI support) can be set to make the -driver ignore the system's ACPI tables entirely or use them for all of the -recognized processor models, respectively (they both are unset by default and -``use_acpi`` has no effect if ``no_acpi`` is set). +The ``no_acpi``, ``use_acpi`` and ``no_native`` module parameters are +recognized by ``intel_idle`` if the kernel has been configured with ACPI +support. In the case that ACPI is not configured these flags have no impact +on functionality. + +``no_acpi`` - Do not use ACPI at all. Only native mode is available, no +ACPI mode. + +``use_acpi`` - No-op in ACPI mode, the driver will consult ACPI tables for +C-states on/off status in native mode. + +``no_native`` - Work only in ACPI mode, no native mode available (ignore +all custom tables). The value of the ``states_off`` module parameter (0 by default) represents a list of idle states to be disabled by default in the form of a bitmask. diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst index bf13ad25a32f..78fc83ed2a7e 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst @@ -696,6 +696,9 @@ of them have to be prepended with the ``intel_pstate=`` prefix. Use per-logical-CPU P-State limits (see `Coordination of P-state Limits`_ for details). +``no_cas`` + Do not enable capacity-aware scheduling (CAS) which is enabled by + default on hybrid systems. Diagnostics and Tuning ====================== diff --git a/Documentation/admin-guide/pnp.rst b/Documentation/admin-guide/pnp.rst index 3eda08191d13..24d80e3eb309 100644 --- a/Documentation/admin-guide/pnp.rst +++ b/Documentation/admin-guide/pnp.rst @@ -129,9 +129,6 @@ pnp_put_protocol pnp_register_protocol use this to register a new PnP protocol -pnp_unregister_protocol - use this function to remove a PnP protocol from the Plug and Play Layer - pnp_register_driver adds a PnP driver to the Plug and Play Layer diff --git a/Documentation/admin-guide/serial-console.rst b/Documentation/admin-guide/serial-console.rst index a3dfc2c66e01..1609e7479249 100644 --- a/Documentation/admin-guide/serial-console.rst +++ b/Documentation/admin-guide/serial-console.rst @@ -78,7 +78,9 @@ If no console device is specified, the first device found capable of acting as a system console will be used. At this time, the system first looks for a VGA card and then for a serial port. So if you don't have a VGA card in your system the first serial port will automatically -become the console. +become the console, unless the kernel is configured with the +CONFIG_NULL_TTY_DEFAULT_CONSOLE option, then it will default to using the +ttynull device. You will need to create a new device to use ``/dev/console``. The official ``/dev/console`` is now character device 5,1. 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/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index a43b78b4b646..dd49a89a62d3 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -212,6 +212,17 @@ pid>/``). This value defaults to 0. +core_sort_vma +============= + +The default coredump writes VMAs in address order. By setting +``core_sort_vma`` to 1, VMAs will be written from smallest size +to largest size. This is known to break at least elfutils, but +can be handy when dealing with very large (and truncated) +coredumps where the more useful debugging details are included +in the smaller VMAs. + + core_uses_pid ============= 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/admin-guide/thunderbolt.rst b/Documentation/admin-guide/thunderbolt.rst index 2ed79f41a411..d0502691dfa1 100644 --- a/Documentation/admin-guide/thunderbolt.rst +++ b/Documentation/admin-guide/thunderbolt.rst @@ -28,7 +28,7 @@ should be a userspace tool that handles all the low-level details, keeps a database of the authorized devices and prompts users for new connections. More details about the sysfs interface for Thunderbolt devices can be -found in ``Documentation/ABI/testing/sysfs-bus-thunderbolt``. +found in Documentation/ABI/testing/sysfs-bus-thunderbolt. Those users who just want to connect any device without any sort of manual work can add following line to diff --git a/Documentation/admin-guide/workload-tracing.rst b/Documentation/admin-guide/workload-tracing.rst index 6be38c1b9c5b..d6313890ee41 100644 --- a/Documentation/admin-guide/workload-tracing.rst +++ b/Documentation/admin-guide/workload-tracing.rst @@ -82,7 +82,7 @@ Install tools to build Linux kernel and tools in kernel repository. scripts/ver_linux is a good way to check if your system already has the necessary tools:: - sudo apt-get build-essentials flex bison yacc + sudo apt-get install build-essential flex bison yacc sudo apt install libelf-dev systemtap-sdt-dev libslang2-dev libperl-dev libdw-dev cscope is a good tool to browse kernel sources. Let's install it now:: diff --git a/Documentation/arch/arm64/amu.rst b/Documentation/arch/arm64/amu.rst index 01f2de2b0450..ac1b3f0e211d 100644 --- a/Documentation/arch/arm64/amu.rst +++ b/Documentation/arch/arm64/amu.rst @@ -80,7 +80,7 @@ bypass the setting of AMUSERENR_EL0 to trap accesses from EL0 (userspace) to EL1 (kernel). Therefore, firmware should still ensure accesses to AMU registers are not trapped in EL2/EL3. -The fixed counters of AMUv1 are accessible though the following system +The fixed counters of AMUv1 are accessible through the following system register definitions: - SYS_AMEVCNTR0_CORE_EL0 diff --git a/Documentation/arch/arm64/asymmetric-32bit.rst b/Documentation/arch/arm64/asymmetric-32bit.rst index 1ca2b359a907..57b8d7476f71 100644 --- a/Documentation/arch/arm64/asymmetric-32bit.rst +++ b/Documentation/arch/arm64/asymmetric-32bit.rst @@ -55,7 +55,7 @@ sysfs The subset of CPUs capable of running 32-bit tasks is described in ``/sys/devices/system/cpu/aarch32_el0`` and is documented further in -``Documentation/ABI/testing/sysfs-devices-system-cpu``. +Documentation/ABI/testing/sysfs-devices-system-cpu. **Note:** CPUs are advertised by this file as they are detected and so late-onlining of 32-bit-capable CPUs can result in the file contents diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst index cad6fdc96b98..dee7b6de864f 100644 --- a/Documentation/arch/arm64/booting.rst +++ b/Documentation/arch/arm64/booting.rst @@ -288,6 +288,12 @@ Before jumping into the kernel, the following conditions must be met: - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1. + For CPUs with the Fine Grained Traps 2 (FEAT_FGT2) extension present: + + - If EL3 is present and the kernel is entered at EL2: + + - SCR_EL3.FGTEn2 (bit 59) must be initialised to 0b1. + For CPUs with support for HCRX_EL2 (FEAT_HCX) present: - If EL3 is present and the kernel is entered at EL2: @@ -382,6 +388,22 @@ Before jumping into the kernel, the following conditions must be met: - SMCR_EL2.EZT0 (bit 30) must be initialised to 0b1. + For CPUs with the Performance Monitors Extension (FEAT_PMUv3p9): + + - If EL3 is present: + + - MDCR_EL3.EnPM2 (bit 7) must be initialised to 0b1. + + - If the kernel is entered at EL1 and EL2 is present: + + - HDFGRTR2_EL2.nPMICNTR_EL0 (bit 2) must be initialised to 0b1. + - HDFGRTR2_EL2.nPMICFILTR_EL0 (bit 3) must be initialised to 0b1. + - HDFGRTR2_EL2.nPMUACR_EL1 (bit 4) must be initialised to 0b1. + + - HDFGWTR2_EL2.nPMICNTR_EL0 (bit 2) must be initialised to 0b1. + - HDFGWTR2_EL2.nPMICFILTR_EL0 (bit 3) must be initialised to 0b1. + - HDFGWTR2_EL2.nPMUACR_EL1 (bit 4) must be initialised to 0b1. + For CPUs with Memory Copy and Memory Set instructions (FEAT_MOPS): - If the kernel is entered at EL1 and EL2 is present: diff --git a/Documentation/arch/arm64/gcs.rst b/Documentation/arch/arm64/gcs.rst index 1f65a3193e77..226c0b008456 100644 --- a/Documentation/arch/arm64/gcs.rst +++ b/Documentation/arch/arm64/gcs.rst @@ -37,7 +37,7 @@ intended to be exhaustive. shadow stacks rather than GCS. * Support for GCS is reported to userspace via HWCAP_GCS in the aux vector - AT_HWCAP2 entry. + AT_HWCAP entry. * GCS is enabled per thread. While there is support for disabling GCS at runtime this should be done with great care. 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/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst index f074f6219f5c..f968c13b46a7 100644 --- a/Documentation/arch/arm64/silicon-errata.rst +++ b/Documentation/arch/arm64/silicon-errata.rst @@ -284,6 +284,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | Rockchip | RK3588 | #3588001 | ROCKCHIP_ERRATUM_3588001 | +----------------+-----------------+-----------------+-----------------------------+ +| Rockchip | RK3568 | #3568002 | ROCKCHIP_ERRATUM_3568002 | ++----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ | Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 | +----------------+-----------------+-----------------+-----------------------------+ diff --git a/Documentation/arch/powerpc/cxl.rst b/Documentation/arch/powerpc/cxl.rst deleted file mode 100644 index d2d77057610e..000000000000 --- a/Documentation/arch/powerpc/cxl.rst +++ /dev/null @@ -1,469 +0,0 @@ -==================================== -Coherent Accelerator Interface (CXL) -==================================== - -Introduction -============ - - The coherent accelerator interface is designed to allow the - coherent connection of accelerators (FPGAs and other devices) to a - POWER system. These devices need to adhere to the Coherent - Accelerator Interface Architecture (CAIA). - - IBM refers to this as the Coherent Accelerator Processor Interface - or CAPI. In the kernel it's referred to by the name CXL to avoid - confusion with the ISDN CAPI subsystem. - - Coherent in this context means that the accelerator and CPUs can - both access system memory directly and with the same effective - addresses. - - -Hardware overview -================= - - :: - - POWER8/9 FPGA - +----------+ +---------+ - | | | | - | CPU | | AFU | - | | | | - | | | | - | | | | - +----------+ +---------+ - | PHB | | | - | +------+ | PSL | - | | CAPP |<------>| | - +---+------+ PCIE +---------+ - - The POWER8/9 chip has a Coherently Attached Processor Proxy (CAPP) - unit which is part of the PCIe Host Bridge (PHB). This is managed - by Linux by calls into OPAL. Linux doesn't directly program the - CAPP. - - The FPGA (or coherently attached device) consists of two parts. - The POWER Service Layer (PSL) and the Accelerator Function Unit - (AFU). The AFU is used to implement specific functionality behind - the PSL. The PSL, among other things, provides memory address - translation services to allow each AFU direct access to userspace - memory. - - The AFU is the core part of the accelerator (eg. the compression, - crypto etc function). The kernel has no knowledge of the function - of the AFU. Only userspace interacts directly with the AFU. - - The PSL provides the translation and interrupt services that the - AFU needs. This is what the kernel interacts with. For example, if - the AFU needs to read a particular effective address, it sends - that address to the PSL, the PSL then translates it, fetches the - data from memory and returns it to the AFU. If the PSL has a - translation miss, it interrupts the kernel and the kernel services - the fault. The context to which this fault is serviced is based on - who owns that acceleration function. - - - POWER8 and PSL Version 8 are compliant to the CAIA Version 1.0. - - POWER9 and PSL Version 9 are compliant to the CAIA Version 2.0. - - This PSL Version 9 provides new features such as: - - * Interaction with the nest MMU on the P9 chip. - * Native DMA support. - * Supports sending ASB_Notify messages for host thread wakeup. - * Supports Atomic operations. - * etc. - - Cards with a PSL9 won't work on a POWER8 system and cards with a - PSL8 won't work on a POWER9 system. - -AFU Modes -========= - - There are two programming modes supported by the AFU. Dedicated - and AFU directed. AFU may support one or both modes. - - When using dedicated mode only one MMU context is supported. In - this mode, only one userspace process can use the accelerator at - time. - - When using AFU directed mode, up to 16K simultaneous contexts can - be supported. This means up to 16K simultaneous userspace - applications may use the accelerator (although specific AFUs may - support fewer). In this mode, the AFU sends a 16 bit context ID - with each of its requests. This tells the PSL which context is - associated with each operation. If the PSL can't translate an - operation, the ID can also be accessed by the kernel so it can - determine the userspace context associated with an operation. - - -MMIO space -========== - - A portion of the accelerator MMIO space can be directly mapped - from the AFU to userspace. Either the whole space can be mapped or - just a per context portion. The hardware is self describing, hence - the kernel can determine the offset and size of the per context - portion. - - -Interrupts -========== - - AFUs may generate interrupts that are destined for userspace. These - are received by the kernel as hardware interrupts and passed onto - userspace by a read syscall documented below. - - Data storage faults and error interrupts are handled by the kernel - driver. - - -Work Element Descriptor (WED) -============================= - - The WED is a 64-bit parameter passed to the AFU when a context is - started. Its format is up to the AFU hence the kernel has no - knowledge of what it represents. Typically it will be the - effective address of a work queue or status block where the AFU - and userspace can share control and status information. - - - - -User API -======== - -1. AFU character devices -^^^^^^^^^^^^^^^^^^^^^^^^ - - For AFUs operating in AFU directed mode, two character device - files will be created. /dev/cxl/afu0.0m will correspond to a - master context and /dev/cxl/afu0.0s will correspond to a slave - context. Master contexts have access to the full MMIO space an - AFU provides. Slave contexts have access to only the per process - MMIO space an AFU provides. - - For AFUs operating in dedicated process mode, the driver will - only create a single character device per AFU called - /dev/cxl/afu0.0d. This will have access to the entire MMIO space - that the AFU provides (like master contexts in AFU directed). - - The types described below are defined in include/uapi/misc/cxl.h - - The following file operations are supported on both slave and - master devices. - - A userspace library libcxl is available here: - - https://github.com/ibm-capi/libcxl - - This provides a C interface to this kernel API. - -open ----- - - Opens the device and allocates a file descriptor to be used with - the rest of the API. - - A dedicated mode AFU only has one context and only allows the - device to be opened once. - - An AFU directed mode AFU can have many contexts, the device can be - opened once for each context that is available. - - When all available contexts are allocated the open call will fail - and return -ENOSPC. - - Note: - IRQs need to be allocated for each context, which may limit - the number of contexts that can be created, and therefore - how many times the device can be opened. The POWER8 CAPP - supports 2040 IRQs and 3 are used by the kernel, so 2037 are - left. If 1 IRQ is needed per context, then only 2037 - contexts can be allocated. If 4 IRQs are needed per context, - then only 2037/4 = 509 contexts can be allocated. - - -ioctl ------ - - CXL_IOCTL_START_WORK: - Starts the AFU context and associates it with the current - process. Once this ioctl is successfully executed, all memory - mapped into this process is accessible to this AFU context - using the same effective addresses. No additional calls are - required to map/unmap memory. The AFU memory context will be - updated as userspace allocates and frees memory. This ioctl - returns once the AFU context is started. - - Takes a pointer to a struct cxl_ioctl_start_work - - :: - - struct cxl_ioctl_start_work { - __u64 flags; - __u64 work_element_descriptor; - __u64 amr; - __s16 num_interrupts; - __s16 reserved1; - __s32 reserved2; - __u64 reserved3; - __u64 reserved4; - __u64 reserved5; - __u64 reserved6; - }; - - flags: - Indicates which optional fields in the structure are - valid. - - work_element_descriptor: - The Work Element Descriptor (WED) is a 64-bit argument - defined by the AFU. Typically this is an effective - address pointing to an AFU specific structure - describing what work to perform. - - amr: - Authority Mask Register (AMR), same as the powerpc - AMR. This field is only used by the kernel when the - corresponding CXL_START_WORK_AMR value is specified in - flags. If not specified the kernel will use a default - value of 0. - - num_interrupts: - Number of userspace interrupts to request. This field - is only used by the kernel when the corresponding - CXL_START_WORK_NUM_IRQS value is specified in flags. - If not specified the minimum number required by the - AFU will be allocated. The min and max number can be - obtained from sysfs. - - reserved fields: - For ABI padding and future extensions - - CXL_IOCTL_GET_PROCESS_ELEMENT: - Get the current context id, also known as the process element. - The value is returned from the kernel as a __u32. - - -mmap ----- - - An AFU may have an MMIO space to facilitate communication with the - AFU. If it does, the MMIO space can be accessed via mmap. The size - and contents of this area are specific to the particular AFU. The - size can be discovered via sysfs. - - In AFU directed mode, master contexts are allowed to map all of - the MMIO space and slave contexts are allowed to only map the per - process MMIO space associated with the context. In dedicated - process mode the entire MMIO space can always be mapped. - - This mmap call must be done after the START_WORK ioctl. - - Care should be taken when accessing MMIO space. Only 32 and 64-bit - accesses are supported by POWER8. Also, the AFU will be designed - with a specific endianness, so all MMIO accesses should consider - endianness (recommend endian(3) variants like: le64toh(), - be64toh() etc). These endian issues equally apply to shared memory - queues the WED may describe. - - -read ----- - - Reads events from the AFU. Blocks if no events are pending - (unless O_NONBLOCK is supplied). Returns -EIO in the case of an - unrecoverable error or if the card is removed. - - read() will always return an integral number of events. - - The buffer passed to read() must be at least 4K bytes. - - The result of the read will be a buffer of one or more events, - each event is of type struct cxl_event, of varying size:: - - struct cxl_event { - struct cxl_event_header header; - union { - struct cxl_event_afu_interrupt irq; - struct cxl_event_data_storage fault; - struct cxl_event_afu_error afu_error; - }; - }; - - The struct cxl_event_header is defined as - - :: - - struct cxl_event_header { - __u16 type; - __u16 size; - __u16 process_element; - __u16 reserved1; - }; - - type: - This defines the type of event. The type determines how - the rest of the event is structured. These types are - described below and defined by enum cxl_event_type. - - size: - This is the size of the event in bytes including the - struct cxl_event_header. The start of the next event can - be found at this offset from the start of the current - event. - - process_element: - Context ID of the event. - - reserved field: - For future extensions and padding. - - If the event type is CXL_EVENT_AFU_INTERRUPT then the event - structure is defined as - - :: - - struct cxl_event_afu_interrupt { - __u16 flags; - __u16 irq; /* Raised AFU interrupt number */ - __u32 reserved1; - }; - - flags: - These flags indicate which optional fields are present - in this struct. Currently all fields are mandatory. - - irq: - The IRQ number sent by the AFU. - - reserved field: - For future extensions and padding. - - If the event type is CXL_EVENT_DATA_STORAGE then the event - structure is defined as - - :: - - struct cxl_event_data_storage { - __u16 flags; - __u16 reserved1; - __u32 reserved2; - __u64 addr; - __u64 dsisr; - __u64 reserved3; - }; - - flags: - These flags indicate which optional fields are present in - this struct. Currently all fields are mandatory. - - address: - The address that the AFU unsuccessfully attempted to - access. Valid accesses will be handled transparently by the - kernel but invalid accesses will generate this event. - - dsisr: - This field gives information on the type of fault. It is a - copy of the DSISR from the PSL hardware when the address - fault occurred. The form of the DSISR is as defined in the - CAIA. - - reserved fields: - For future extensions - - If the event type is CXL_EVENT_AFU_ERROR then the event structure - is defined as - - :: - - struct cxl_event_afu_error { - __u16 flags; - __u16 reserved1; - __u32 reserved2; - __u64 error; - }; - - flags: - These flags indicate which optional fields are present in - this struct. Currently all fields are Mandatory. - - error: - Error status from the AFU. Defined by the AFU. - - reserved fields: - For future extensions and padding - - -2. Card character device (powerVM guest only) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - In a powerVM guest, an extra character device is created for the - card. The device is only used to write (flash) a new image on the - FPGA accelerator. Once the image is written and verified, the - device tree is updated and the card is reset to reload the updated - image. - -open ----- - - Opens the device and allocates a file descriptor to be used with - the rest of the API. The device can only be opened once. - -ioctl ------ - -CXL_IOCTL_DOWNLOAD_IMAGE / CXL_IOCTL_VALIDATE_IMAGE: - Starts and controls flashing a new FPGA image. Partial - reconfiguration is not supported (yet), so the image must contain - a copy of the PSL and AFU(s). Since an image can be quite large, - the caller may have to iterate, splitting the image in smaller - chunks. - - Takes a pointer to a struct cxl_adapter_image:: - - struct cxl_adapter_image { - __u64 flags; - __u64 data; - __u64 len_data; - __u64 len_image; - __u64 reserved1; - __u64 reserved2; - __u64 reserved3; - __u64 reserved4; - }; - - flags: - These flags indicate which optional fields are present in - this struct. Currently all fields are mandatory. - - data: - Pointer to a buffer with part of the image to write to the - card. - - len_data: - Size of the buffer pointed to by data. - - len_image: - Full size of the image. - - -Sysfs Class -=========== - - A cxl sysfs class is added under /sys/class/cxl to facilitate - enumeration and tuning of the accelerators. Its layout is - described in Documentation/ABI/testing/sysfs-class-cxl - - -Udev rules -========== - - The following udev rules could be used to create a symlink to the - most logical chardev to use in any programming mode (afuX.Yd for - dedicated, afuX.Ys for afu directed), since the API is virtually - identical for each:: - - SUBSYSTEM=="cxl", ATTRS{mode}=="dedicated_process", SYMLINK="cxl/%b" - SUBSYSTEM=="cxl", ATTRS{mode}=="afu_directed", \ - KERNEL=="afu[0-9]*.[0-9]*s", SYMLINK="cxl/%b" diff --git a/Documentation/arch/powerpc/cxlflash.rst b/Documentation/arch/powerpc/cxlflash.rst deleted file mode 100644 index e8f488acfa41..000000000000 --- a/Documentation/arch/powerpc/cxlflash.rst +++ /dev/null @@ -1,433 +0,0 @@ -================================ -Coherent Accelerator (CXL) Flash -================================ - -Introduction -============ - - The IBM Power architecture provides support for CAPI (Coherent - Accelerator Power Interface), which is available to certain PCIe slots - on Power 8 systems. CAPI can be thought of as a special tunneling - protocol through PCIe that allow PCIe adapters to look like special - purpose co-processors which can read or write an application's - memory and generate page faults. As a result, the host interface to - an adapter running in CAPI mode does not require the data buffers to - be mapped to the device's memory (IOMMU bypass) nor does it require - memory to be pinned. - - On Linux, Coherent Accelerator (CXL) kernel services present CAPI - devices as a PCI device by implementing a virtual PCI host bridge. - This abstraction simplifies the infrastructure and programming - model, allowing for drivers to look similar to other native PCI - device drivers. - - CXL provides a mechanism by which user space applications can - directly talk to a device (network or storage) bypassing the typical - kernel/device driver stack. The CXL Flash Adapter Driver enables a - user space application direct access to Flash storage. - - The CXL Flash Adapter Driver is a kernel module that sits in the - SCSI stack as a low level device driver (below the SCSI disk and - protocol drivers) for the IBM CXL Flash Adapter. This driver is - responsible for the initialization of the adapter, setting up the - special path for user space access, and performing error recovery. It - communicates directly the Flash Accelerator Functional Unit (AFU) - as described in Documentation/arch/powerpc/cxl.rst. - - The cxlflash driver supports two, mutually exclusive, modes of - operation at the device (LUN) level: - - - Any flash device (LUN) can be configured to be accessed as a - regular disk device (i.e.: /dev/sdc). This is the default mode. - - - Any flash device (LUN) can be configured to be accessed from - user space with a special block library. This mode further - specifies the means of accessing the device and provides for - either raw access to the entire LUN (referred to as direct - or physical LUN access) or access to a kernel/AFU-mediated - partition of the LUN (referred to as virtual LUN access). The - segmentation of a disk device into virtual LUNs is assisted - by special translation services provided by the Flash AFU. - -Overview -======== - - The Coherent Accelerator Interface Architecture (CAIA) introduces a - concept of a master context. A master typically has special privileges - granted to it by the kernel or hypervisor allowing it to perform AFU - wide management and control. The master may or may not be involved - directly in each user I/O, but at the minimum is involved in the - initial setup before the user application is allowed to send requests - directly to the AFU. - - The CXL Flash Adapter Driver establishes a master context with the - AFU. It uses memory mapped I/O (MMIO) for this control and setup. The - Adapter Problem Space Memory Map looks like this:: - - +-------------------------------+ - | 512 * 64 KB User MMIO | - | (per context) | - | User Accessible | - +-------------------------------+ - | 512 * 128 B per context | - | Provisioning and Control | - | Trusted Process accessible | - +-------------------------------+ - | 64 KB Global | - | Trusted Process accessible | - +-------------------------------+ - - This driver configures itself into the SCSI software stack as an - adapter driver. The driver is the only entity that is considered a - Trusted Process to program the Provisioning and Control and Global - areas in the MMIO Space shown above. The master context driver - discovers all LUNs attached to the CXL Flash adapter and instantiates - scsi block devices (/dev/sdb, /dev/sdc etc.) for each unique LUN - seen from each path. - - Once these scsi block devices are instantiated, an application - written to a specification provided by the block library may get - access to the Flash from user space (without requiring a system call). - - This master context driver also provides a series of ioctls for this - block library to enable this user space access. The driver supports - two modes for accessing the block device. - - The first mode is called a virtual mode. In this mode a single scsi - block device (/dev/sdb) may be carved up into any number of distinct - virtual LUNs. The virtual LUNs may be resized as long as the sum of - the sizes of all the virtual LUNs, along with the meta-data associated - with it does not exceed the physical capacity. - - The second mode is called the physical mode. In this mode a single - block device (/dev/sdb) may be opened directly by the block library - and the entire space for the LUN is available to the application. - - Only the physical mode provides persistence of the data. i.e. The - data written to the block device will survive application exit and - restart and also reboot. The virtual LUNs do not persist (i.e. do - not survive after the application terminates or the system reboots). - - -Block library API -================= - - Applications intending to get access to the CXL Flash from user - space should use the block library, as it abstracts the details of - interfacing directly with the cxlflash driver that are necessary for - performing administrative actions (i.e.: setup, tear down, resize). - The block library can be thought of as a 'user' of services, - implemented as IOCTLs, that are provided by the cxlflash driver - specifically for devices (LUNs) operating in user space access - mode. While it is not a requirement that applications understand - the interface between the block library and the cxlflash driver, - a high-level overview of each supported service (IOCTL) is provided - below. - - The block library can be found on GitHub: - http://github.com/open-power/capiflash - - -CXL Flash Driver LUN IOCTLs -=========================== - - Users, such as the block library, that wish to interface with a flash - device (LUN) via user space access need to use the services provided - by the cxlflash driver. As these services are implemented as ioctls, - a file descriptor handle must first be obtained in order to establish - the communication channel between a user and the kernel. This file - descriptor is obtained by opening the device special file associated - with the scsi disk device (/dev/sdb) that was created during LUN - discovery. As per the location of the cxlflash driver within the - SCSI protocol stack, this open is actually not seen by the cxlflash - driver. Upon successful open, the user receives a file descriptor - (herein referred to as fd1) that should be used for issuing the - subsequent ioctls listed below. - - The structure definitions for these IOCTLs are available in: - uapi/scsi/cxlflash_ioctl.h - -DK_CXLFLASH_ATTACH ------------------- - - This ioctl obtains, initializes, and starts a context using the CXL - kernel services. These services specify a context id (u16) by which - to uniquely identify the context and its allocated resources. The - services additionally provide a second file descriptor (herein - referred to as fd2) that is used by the block library to initiate - memory mapped I/O (via mmap()) to the CXL flash device and poll for - completion events. This file descriptor is intentionally installed by - this driver and not the CXL kernel services to allow for intermediary - notification and access in the event of a non-user-initiated close(), - such as a killed process. This design point is described in further - detail in the description for the DK_CXLFLASH_DETACH ioctl. - - There are a few important aspects regarding the "tokens" (context id - and fd2) that are provided back to the user: - - - These tokens are only valid for the process under which they - were created. The child of a forked process cannot continue - to use the context id or file descriptor created by its parent - (see DK_CXLFLASH_VLUN_CLONE for further details). - - - These tokens are only valid for the lifetime of the context and - the process under which they were created. Once either is - destroyed, the tokens are to be considered stale and subsequent - usage will result in errors. - - - A valid adapter file descriptor (fd2 >= 0) is only returned on - the initial attach for a context. Subsequent attaches to an - existing context (DK_CXLFLASH_ATTACH_REUSE_CONTEXT flag present) - do not provide the adapter file descriptor as it was previously - made known to the application. - - - When a context is no longer needed, the user shall detach from - the context via the DK_CXLFLASH_DETACH ioctl. When this ioctl - returns with a valid adapter file descriptor and the return flag - DK_CXLFLASH_APP_CLOSE_ADAP_FD is present, the application _must_ - close the adapter file descriptor following a successful detach. - - - When this ioctl returns with a valid fd2 and the return flag - DK_CXLFLASH_APP_CLOSE_ADAP_FD is present, the application _must_ - close fd2 in the following circumstances: - - + Following a successful detach of the last user of the context - + Following a successful recovery on the context's original fd2 - + In the child process of a fork(), following a clone ioctl, - on the fd2 associated with the source context - - - At any time, a close on fd2 will invalidate the tokens. Applications - should exercise caution to only close fd2 when appropriate (outlined - in the previous bullet) to avoid premature loss of I/O. - -DK_CXLFLASH_USER_DIRECT ------------------------ - This ioctl is responsible for transitioning the LUN to direct - (physical) mode access and configuring the AFU for direct access from - user space on a per-context basis. Additionally, the block size and - last logical block address (LBA) are returned to the user. - - As mentioned previously, when operating in user space access mode, - LUNs may be accessed in whole or in part. Only one mode is allowed - at a time and if one mode is active (outstanding references exist), - requests to use the LUN in a different mode are denied. - - The AFU is configured for direct access from user space by adding an - entry to the AFU's resource handle table. The index of the entry is - treated as a resource handle that is returned to the user. The user - is then able to use the handle to reference the LUN during I/O. - -DK_CXLFLASH_USER_VIRTUAL ------------------------- - This ioctl is responsible for transitioning the LUN to virtual mode - of access and configuring the AFU for virtual access from user space - on a per-context basis. Additionally, the block size and last logical - block address (LBA) are returned to the user. - - As mentioned previously, when operating in user space access mode, - LUNs may be accessed in whole or in part. Only one mode is allowed - at a time and if one mode is active (outstanding references exist), - requests to use the LUN in a different mode are denied. - - The AFU is configured for virtual access from user space by adding - an entry to the AFU's resource handle table. The index of the entry - is treated as a resource handle that is returned to the user. The - user is then able to use the handle to reference the LUN during I/O. - - By default, the virtual LUN is created with a size of 0. The user - would need to use the DK_CXLFLASH_VLUN_RESIZE ioctl to adjust the grow - the virtual LUN to a desired size. To avoid having to perform this - resize for the initial creation of the virtual LUN, the user has the - option of specifying a size as part of the DK_CXLFLASH_USER_VIRTUAL - ioctl, such that when success is returned to the user, the - resource handle that is provided is already referencing provisioned - storage. This is reflected by the last LBA being a non-zero value. - - When a LUN is accessible from more than one port, this ioctl will - return with the DK_CXLFLASH_ALL_PORTS_ACTIVE return flag set. This - provides the user with a hint that I/O can be retried in the event - of an I/O error as the LUN can be reached over multiple paths. - -DK_CXLFLASH_VLUN_RESIZE ------------------------ - This ioctl is responsible for resizing a previously created virtual - LUN and will fail if invoked upon a LUN that is not in virtual - mode. Upon success, an updated last LBA is returned to the user - indicating the new size of the virtual LUN associated with the - resource handle. - - The partitioning of virtual LUNs is jointly mediated by the cxlflash - driver and the AFU. An allocation table is kept for each LUN that is - operating in the virtual mode and used to program a LUN translation - table that the AFU references when provided with a resource handle. - - This ioctl can return -EAGAIN if an AFU sync operation takes too long. - In addition to returning a failure to user, cxlflash will also schedule - an asynchronous AFU reset. Should the user choose to retry the operation, - it is expected to succeed. If this ioctl fails with -EAGAIN, the user - can either retry the operation or treat it as a failure. - -DK_CXLFLASH_RELEASE -------------------- - This ioctl is responsible for releasing a previously obtained - reference to either a physical or virtual LUN. This can be - thought of as the inverse of the DK_CXLFLASH_USER_DIRECT or - DK_CXLFLASH_USER_VIRTUAL ioctls. Upon success, the resource handle - is no longer valid and the entry in the resource handle table is - made available to be used again. - - As part of the release process for virtual LUNs, the virtual LUN - is first resized to 0 to clear out and free the translation tables - associated with the virtual LUN reference. - -DK_CXLFLASH_DETACH ------------------- - This ioctl is responsible for unregistering a context with the - cxlflash driver and release outstanding resources that were - not explicitly released via the DK_CXLFLASH_RELEASE ioctl. Upon - success, all "tokens" which had been provided to the user from the - DK_CXLFLASH_ATTACH onward are no longer valid. - - When the DK_CXLFLASH_APP_CLOSE_ADAP_FD flag was returned on a successful - attach, the application _must_ close the fd2 associated with the context - following the detach of the final user of the context. - -DK_CXLFLASH_VLUN_CLONE ----------------------- - This ioctl is responsible for cloning a previously created - context to a more recently created context. It exists solely to - support maintaining user space access to storage after a process - forks. Upon success, the child process (which invoked the ioctl) - will have access to the same LUNs via the same resource handle(s) - as the parent, but under a different context. - - Context sharing across processes is not supported with CXL and - therefore each fork must be met with establishing a new context - for the child process. This ioctl simplifies the state management - and playback required by a user in such a scenario. When a process - forks, child process can clone the parents context by first creating - a context (via DK_CXLFLASH_ATTACH) and then using this ioctl to - perform the clone from the parent to the child. - - The clone itself is fairly simple. The resource handle and lun - translation tables are copied from the parent context to the child's - and then synced with the AFU. - - When the DK_CXLFLASH_APP_CLOSE_ADAP_FD flag was returned on a successful - attach, the application _must_ close the fd2 associated with the source - context (still resident/accessible in the parent process) following the - clone. This is to avoid a stale entry in the file descriptor table of the - child process. - - This ioctl can return -EAGAIN if an AFU sync operation takes too long. - In addition to returning a failure to user, cxlflash will also schedule - an asynchronous AFU reset. Should the user choose to retry the operation, - it is expected to succeed. If this ioctl fails with -EAGAIN, the user - can either retry the operation or treat it as a failure. - -DK_CXLFLASH_VERIFY ------------------- - This ioctl is used to detect various changes such as the capacity of - the disk changing, the number of LUNs visible changing, etc. In cases - where the changes affect the application (such as a LUN resize), the - cxlflash driver will report the changed state to the application. - - The user calls in when they want to validate that a LUN hasn't been - changed in response to a check condition. As the user is operating out - of band from the kernel, they will see these types of events without - the kernel's knowledge. When encountered, the user's architected - behavior is to call in to this ioctl, indicating what they want to - verify and passing along any appropriate information. For now, only - verifying a LUN change (ie: size different) with sense data is - supported. - -DK_CXLFLASH_RECOVER_AFU ------------------------ - This ioctl is used to drive recovery (if such an action is warranted) - of a specified user context. Any state associated with the user context - is re-established upon successful recovery. - - User contexts are put into an error condition when the device needs to - be reset or is terminating. Users are notified of this error condition - by seeing all 0xF's on an MMIO read. Upon encountering this, the - architected behavior for a user is to call into this ioctl to recover - their context. A user may also call into this ioctl at any time to - check if the device is operating normally. If a failure is returned - from this ioctl, the user is expected to gracefully clean up their - context via release/detach ioctls. Until they do, the context they - hold is not relinquished. The user may also optionally exit the process - at which time the context/resources they held will be freed as part of - the release fop. - - When the DK_CXLFLASH_APP_CLOSE_ADAP_FD flag was returned on a successful - attach, the application _must_ unmap and close the fd2 associated with the - original context following this ioctl returning success and indicating that - the context was recovered (DK_CXLFLASH_RECOVER_AFU_CONTEXT_RESET). - -DK_CXLFLASH_MANAGE_LUN ----------------------- - This ioctl is used to switch a LUN from a mode where it is available - for file-system access (legacy), to a mode where it is set aside for - exclusive user space access (superpipe). In case a LUN is visible - across multiple ports and adapters, this ioctl is used to uniquely - identify each LUN by its World Wide Node Name (WWNN). - - -CXL Flash Driver Host IOCTLs -============================ - - Each host adapter instance that is supported by the cxlflash driver - has a special character device associated with it to enable a set of - host management function. These character devices are hosted in a - class dedicated for cxlflash and can be accessed via `/dev/cxlflash/*`. - - Applications can be written to perform various functions using the - host ioctl APIs below. - - The structure definitions for these IOCTLs are available in: - uapi/scsi/cxlflash_ioctl.h - -HT_CXLFLASH_LUN_PROVISION -------------------------- - This ioctl is used to create and delete persistent LUNs on cxlflash - devices that lack an external LUN management interface. It is only - valid when used with AFUs that support the LUN provision capability. - - When sufficient space is available, LUNs can be created by specifying - the target port to host the LUN and a desired size in 4K blocks. Upon - success, the LUN ID and WWID of the created LUN will be returned and - the SCSI bus can be scanned to detect the change in LUN topology. Note - that partial allocations are not supported. Should a creation fail due - to a space issue, the target port can be queried for its current LUN - geometry. - - To remove a LUN, the device must first be disassociated from the Linux - SCSI subsystem. The LUN deletion can then be initiated by specifying a - target port and LUN ID. Upon success, the LUN geometry associated with - the port will be updated to reflect new number of provisioned LUNs and - available capacity. - - To query the LUN geometry of a port, the target port is specified and - upon success, the following information is presented: - - - Maximum number of provisioned LUNs allowed for the port - - Current number of provisioned LUNs for the port - - Maximum total capacity of provisioned LUNs for the port (4K blocks) - - Current total capacity of provisioned LUNs for the port (4K blocks) - - With this information, the number of available LUNs and capacity can be - can be calculated. - -HT_CXLFLASH_AFU_DEBUG ---------------------- - This ioctl is used to debug AFUs by supporting a command pass-through - interface. It is only valid when used with AFUs that support the AFU - debug capability. - - With exception of buffer management, AFU debug commands are opaque to - cxlflash and treated as pass-through. For debug commands that do require - data transfer, the user supplies an adequately sized data buffer and must - specify the data transfer direction with respect to the host. There is a - maximum transfer size of 256K imposed. Note that partial read completions - are not supported - when errors are experienced with a host read data - transfer, the data buffer is not copied back to the user. diff --git a/Documentation/arch/powerpc/firmware-assisted-dump.rst b/Documentation/arch/powerpc/firmware-assisted-dump.rst index 7e37aadd1f77..7e266e749cd5 100644 --- a/Documentation/arch/powerpc/firmware-assisted-dump.rst +++ b/Documentation/arch/powerpc/firmware-assisted-dump.rst @@ -120,6 +120,28 @@ to ensure that crash data is preserved to process later. e.g. # echo 1 > /sys/firmware/opal/mpipl/release_core +-- Support for Additional Kernel Arguments in Fadump + Fadump has a feature that allows passing additional kernel arguments + to the fadump kernel. This feature was primarily designed to disable + kernel functionalities that are not required for the fadump kernel + and to reduce its memory footprint while collecting the dump. + + Command to Add Additional Kernel Parameters to Fadump: + e.g. + # echo "nr_cpus=16" > /sys/kernel/fadump/bootargs_append + + The above command is sufficient to add additional arguments to fadump. + An explicit service restart is not required. + + Command to Retrieve the Additional Fadump Arguments: + e.g. + # cat /sys/kernel/fadump/bootargs_append + +Note: Additional kernel arguments for fadump with HASH MMU is only + supported if the RMA size is greater than 768 MB. If the RMA + size is less than 768 MB, the kernel does not export the + /sys/kernel/fadump/bootargs_append sysfs node. + Implementation details: ----------------------- diff --git a/Documentation/arch/powerpc/index.rst b/Documentation/arch/powerpc/index.rst index 9749f6dc258f..0560cbae5fa1 100644 --- a/Documentation/arch/powerpc/index.rst +++ b/Documentation/arch/powerpc/index.rst @@ -12,8 +12,6 @@ powerpc bootwrapper cpu_families cpu_features - cxl - cxlflash dawr-power9 dexcr dscr diff --git a/Documentation/arch/powerpc/papr_hcalls.rst b/Documentation/arch/powerpc/papr_hcalls.rst index 80d2c0aadab5..805e1cb9bab9 100644 --- a/Documentation/arch/powerpc/papr_hcalls.rst +++ b/Documentation/arch/powerpc/papr_hcalls.rst @@ -289,6 +289,17 @@ to be issued multiple times in order to be completely serviced. The subsequent hcalls to the hypervisor until the hcall is completely serviced at which point H_SUCCESS or other error is returned by the hypervisor. +**H_HTM** + +| Input: flags, target, operation (op), op-param1, op-param2, op-param3 +| Out: *dumphtmbufferdata* +| Return Value: *H_Success,H_Busy,H_LongBusyOrder,H_Partial,H_Parameter, + H_P2,H_P3,H_P4,H_P5,H_P6,H_State,H_Not_Available,H_Authority* + +H_HTM supports setup, configuration, control and dumping of Hardware Trace +Macro (HTM) function and its data. HTM buffer stores tracing data for functions +like core instruction, core LLAT and nest. + References ========== .. [1] "Power Architecture Platform Reference" 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/s390/driver-model.rst b/Documentation/arch/s390/driver-model.rst index ad4bc2dbea43..ad18f129fb0b 100644 --- a/Documentation/arch/s390/driver-model.rst +++ b/Documentation/arch/s390/driver-model.rst @@ -244,7 +244,7 @@ information about the interrupt from the irb parameter. -------------------- The ccwgroup mechanism is designed to handle devices consisting of multiple ccw -devices, like lcs or ctc. +devices, like qeth or ctc. The ccw driver provides a 'group' attribute. Piping bus ids of ccw devices to this attributes creates a ccwgroup device consisting of these ccw devices (if diff --git a/Documentation/arch/x86/boot.rst b/Documentation/arch/x86/boot.rst index 76f53d3450e7..77e6163288db 100644 --- a/Documentation/arch/x86/boot.rst +++ b/Documentation/arch/x86/boot.rst @@ -1038,16 +1038,6 @@ Offset/size: 0x000c/4 This field contains maximal allowed type for setup_data and setup_indirect structs. -The Image Checksum -================== - -From boot protocol version 2.08 onwards the CRC-32 is calculated over -the entire file using the characteristic polynomial 0x04C11DB7 and an -initial remainder of 0xffffffff. The checksum is appended to the -file; therefore the CRC of the file up to the limit specified in the -syssize field of the header is always 0. - - The Kernel Command Line ======================= diff --git a/Documentation/arch/x86/sva.rst b/Documentation/arch/x86/sva.rst index 33cb05005982..6a759984d471 100644 --- a/Documentation/arch/x86/sva.rst +++ b/Documentation/arch/x86/sva.rst @@ -25,7 +25,7 @@ to cache translations for virtual addresses. The IOMMU driver uses the mmu_notifier() support to keep the device TLB cache and the CPU cache in sync. When an ATS lookup fails for a virtual address, the device should use the PRI in order to request the virtual address to be paged into the -CPU page tables. The device must use ATS again in order the fetch the +CPU page tables. The device must use ATS again in order to fetch the translation before use. Shared Hardware Workqueues @@ -216,7 +216,7 @@ submitting work and processing completions. Single Root I/O Virtualization (SR-IOV) focuses on providing independent hardware interfaces for virtualizing hardware. Hence, it's required to be -almost fully functional interface to software supporting the traditional +an almost fully functional interface to software supporting the traditional BARs, space for interrupts via MSI-X, its own register layout. Virtual Functions (VFs) are assisted by the Physical Function (PF) driver. diff --git a/Documentation/arch/x86/usb-legacy-support.rst b/Documentation/arch/x86/usb-legacy-support.rst index e01c08b7c981..b17bf122270a 100644 --- a/Documentation/arch/x86/usb-legacy-support.rst +++ b/Documentation/arch/x86/usb-legacy-support.rst @@ -20,11 +20,7 @@ It has several drawbacks, though: features (wheel, extra buttons, touchpad mode) of the real PS/2 mouse may not be available. -2) If CONFIG_HIGHMEM64G is enabled, the PS/2 mouse emulation can cause - system crashes, because the SMM BIOS is not expecting to be in PAE mode. - The Intel E7505 is a typical machine where this happens. - -3) If AMD64 64-bit mode is enabled, again system crashes often happen, +2) If AMD64 64-bit mode is enabled, again system crashes often happen, because the SMM BIOS isn't expecting the CPU to be in 64-bit mode. The BIOS manufacturers only test with Windows, and Windows doesn't do 64-bit yet. @@ -38,11 +34,6 @@ Problem 1) compiled-in, too. Problem 2) - can currently only be solved by either disabling HIGHMEM64G - in the kernel config or USB Legacy support in the BIOS. A BIOS update - could help, but so far no such update exists. - -Problem 3) is usually fixed by a BIOS update. Check the board manufacturers web site. If an update is not available, disable USB Legacy support in the BIOS. If this alone doesn't help, try also adding diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 90b733422ed4..6380e6ab492b 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -77,10 +77,10 @@ Basic design ============ We introduce ``struct blk_crypto_key`` to represent an inline encryption key and -how it will be used. This includes the actual bytes of the key; the size of the -key; the algorithm and data unit size the key will be used with; and the number -of bytes needed to represent the maximum data unit number the key will be used -with. +how it will be used. This includes the type of the key (raw or +hardware-wrapped); the actual bytes of the key; the size of the key; the +algorithm and data unit size the key will be used with; and the number of bytes +needed to represent the maximum data unit number the key will be used with. We introduce ``struct bio_crypt_ctx`` to represent an encryption context. It contains a data unit number and a pointer to a blk_crypto_key. We add pointers @@ -301,3 +301,250 @@ kernel will pretend that the device does not support hardware inline encryption When the crypto API fallback is enabled, this means that all bios with and encryption context will use the fallback, and IO will complete as usual. When the fallback is disabled, a bio with an encryption context will be failed. + +.. _hardware_wrapped_keys: + +Hardware-wrapped keys +===================== + +Motivation and threat model +--------------------------- + +Linux storage encryption (dm-crypt, fscrypt, eCryptfs, etc.) traditionally +relies on the raw encryption key(s) being present in kernel memory so that the +encryption can be performed. This traditionally isn't seen as a problem because +the key(s) won't be present during an offline attack, which is the main type of +attack that storage encryption is intended to protect from. + +However, there is an increasing desire to also protect users' data from other +types of attacks (to the extent possible), including: + +- Cold boot attacks, where an attacker with physical access to a system suddenly + powers it off, then immediately dumps the system memory to extract recently + in-use encryption keys, then uses these keys to decrypt user data on-disk. + +- Online attacks where the attacker is able to read kernel memory without fully + compromising the system, followed by an offline attack where any extracted + keys can be used to decrypt user data on-disk. An example of such an online + attack would be if the attacker is able to run some code on the system that + exploits a Meltdown-like vulnerability but is unable to escalate privileges. + +- Online attacks where the attacker fully compromises the system, but their data + exfiltration is significantly time-limited and/or bandwidth-limited, so in + order to completely exfiltrate the data they need to extract the encryption + keys to use in a later offline attack. + +Hardware-wrapped keys are a feature of inline encryption hardware that is +designed to protect users' data from the above attacks (to the extent possible), +without introducing limitations such as a maximum number of keys. + +Note that it is impossible to **fully** protect users' data from these attacks. +Even in the attacks where the attacker "just" gets read access to kernel memory, +they can still extract any user data that is present in memory, including +plaintext pagecache pages of encrypted files. The focus here is just on +protecting the encryption keys, as those instantly give access to **all** user +data in any following offline attack, rather than just some of it (where which +data is included in that "some" might not be controlled by the attacker). + +Solution overview +----------------- + +Inline encryption hardware typically has "keyslots" into which software can +program keys for the hardware to use; the contents of keyslots typically can't +be read back by software. As such, the above security goals could be achieved +if the kernel simply erased its copy of the key(s) after programming them into +keyslot(s) and thereafter only referred to them via keyslot number. + +However, that naive approach runs into a couple problems: + +- It limits the number of unlocked keys to the number of keyslots, which + typically is a small number. In cases where there is only one encryption key + system-wide (e.g., a full-disk encryption key), that can be tolerable. + However, in general there can be many logged-in users with many different + keys, and/or many running applications with application-specific encrypted + storage areas. This is especially true if file-based encryption (e.g. + fscrypt) is being used. + +- Inline crypto engines typically lose the contents of their keyslots if the + storage controller (usually UFS or eMMC) is reset. Resetting the storage + controller is a standard error recovery procedure that is executed if certain + types of storage errors occur, and such errors can occur at any time. + Therefore, when inline crypto is being used, the operating system must always + be ready to reprogram the keyslots without user intervention. + +Thus, it is important for the kernel to still have a way to "remind" the +hardware about a key, without actually having the raw key itself. + +Somewhat less importantly, it is also desirable that the raw keys are never +visible to software at all, even while being initially unlocked. This would +ensure that a read-only compromise of system memory will never allow a key to be +extracted to be used off-system, even if it occurs when a key is being unlocked. + +To solve all these problems, some vendors of inline encryption hardware have +made their hardware support *hardware-wrapped keys*. Hardware-wrapped keys +are encrypted keys that can only be unwrapped (decrypted) and used by hardware +-- either by the inline encryption hardware itself, or by a dedicated hardware +block that can directly provision keys to the inline encryption hardware. + +(We refer to them as "hardware-wrapped keys" rather than simply "wrapped keys" +to add some clarity in cases where there could be other types of wrapped keys, +such as in file-based encryption. Key wrapping is a commonly used technique.) + +The key which wraps (encrypts) hardware-wrapped keys is a hardware-internal key +that is never exposed to software; it is either a persistent key (a "long-term +wrapping key") or a per-boot key (an "ephemeral wrapping key"). The long-term +wrapped form of the key is what is initially unlocked, but it is erased from +memory as soon as it is converted into an ephemerally-wrapped key. In-use +hardware-wrapped keys are always ephemerally-wrapped, not long-term wrapped. + +As inline encryption hardware can only be used to encrypt/decrypt data on-disk, +the hardware also includes a level of indirection; it doesn't use the unwrapped +key directly for inline encryption, but rather derives both an inline encryption +key and a "software secret" from it. Software can use the "software secret" for +tasks that can't use the inline encryption hardware, such as filenames +encryption. The software secret is not protected from memory compromise. + +Key hierarchy +------------- + +Here is the key hierarchy for a hardware-wrapped key:: + + Hardware-wrapped key + | + | + <Hardware KDF> + | + ----------------------------- + | | + Inline encryption key Software secret + +The components are: + +- *Hardware-wrapped key*: a key for the hardware's KDF (Key Derivation + Function), in ephemerally-wrapped form. The key wrapping algorithm is a + hardware implementation detail that doesn't impact kernel operation, but a + strong authenticated encryption algorithm such as AES-256-GCM is recommended. + +- *Hardware KDF*: a KDF (Key Derivation Function) which the hardware uses to + derive subkeys after unwrapping the wrapped key. The hardware's choice of KDF + doesn't impact kernel operation, but it does need to be known for testing + purposes, and it's also assumed to have at least a 256-bit security strength. + All known hardware uses the SP800-108 KDF in Counter Mode with AES-256-CMAC, + with a particular choice of labels and contexts; new hardware should use this + already-vetted KDF. + +- *Inline encryption key*: a derived key which the hardware directly provisions + to a keyslot of the inline encryption hardware, without exposing it to + software. In all known hardware, this will always be an AES-256-XTS key. + However, in principle other encryption algorithms could be supported too. + Hardware must derive distinct subkeys for each supported encryption algorithm. + +- *Software secret*: a derived key which the hardware returns to software so + that software can use it for cryptographic tasks that can't use inline + encryption. This value is cryptographically isolated from the inline + encryption key, i.e. knowing one doesn't reveal the other. (The KDF ensures + this.) Currently, the software secret is always 32 bytes and thus is suitable + for cryptographic applications that require up to a 256-bit security strength. + Some use cases (e.g. full-disk encryption) won't require the software secret. + +Example: in the case of fscrypt, the fscrypt master key (the key that protects a +particular set of encrypted directories) is made hardware-wrapped. The inline +encryption key is used as the file contents encryption key, while the software +secret (rather than the master key directly) is used to key fscrypt's KDF +(HKDF-SHA512) to derive other subkeys such as filenames encryption keys. + +Note that currently this design assumes a single inline encryption key per +hardware-wrapped key, without any further key derivation. Thus, in the case of +fscrypt, currently hardware-wrapped keys are only compatible with the "inline +encryption optimized" settings, which use one file contents encryption key per +encryption policy rather than one per file. This design could be extended to +make the hardware derive per-file keys using per-file nonces passed down the +storage stack, and in fact some hardware already supports this; future work is +planned to remove this limitation by adding the corresponding kernel support. + +Kernel support +-------------- + +The inline encryption support of the kernel's block layer ("blk-crypto") has +been extended to support hardware-wrapped keys as an alternative to raw keys, +when hardware support is available. This works in the following way: + +- A ``key_types_supported`` field is added to the crypto capabilities in + ``struct blk_crypto_profile``. This allows device drivers to declare that + they support raw keys, hardware-wrapped keys, or both. + +- ``struct blk_crypto_key`` can now contain a hardware-wrapped key as an + alternative to a raw key; a ``key_type`` field is added to + ``struct blk_crypto_config`` to distinguish between the different key types. + This allows users of blk-crypto to en/decrypt data using a hardware-wrapped + key in a way very similar to using a raw key. + +- A new method ``blk_crypto_ll_ops::derive_sw_secret`` is added. Device drivers + that support hardware-wrapped keys must implement this method. Users of + blk-crypto can call ``blk_crypto_derive_sw_secret()`` to access this method. + +- The programming and eviction of hardware-wrapped keys happens via + ``blk_crypto_ll_ops::keyslot_program`` and + ``blk_crypto_ll_ops::keyslot_evict``, just like it does for raw keys. If a + driver supports hardware-wrapped keys, then it must handle hardware-wrapped + keys being passed to these methods. + +blk-crypto-fallback doesn't support hardware-wrapped keys. Therefore, +hardware-wrapped keys can only be used with actual inline encryption hardware. + +All the above deals with hardware-wrapped keys in ephemerally-wrapped form only. +To get such keys in the first place, new block device ioctls have been added to +provide a generic interface to creating and preparing such keys: + +- ``BLKCRYPTOIMPORTKEY`` converts a raw key to long-term wrapped form. It takes + in a pointer to a ``struct blk_crypto_import_key_arg``. The caller must set + ``raw_key_ptr`` and ``raw_key_size`` to the pointer and size (in bytes) of the + raw key to import. On success, ``BLKCRYPTOIMPORTKEY`` returns 0 and writes + the resulting long-term wrapped key blob to the buffer pointed to by + ``lt_key_ptr``, which is of maximum size ``lt_key_size``. It also updates + ``lt_key_size`` to be the actual size of the key. On failure, it returns -1 + and sets errno. An errno of ``EOPNOTSUPP`` indicates that the block device + does not support hardware-wrapped keys. An errno of ``EOVERFLOW`` indicates + that the output buffer did not have enough space for the key blob. + +- ``BLKCRYPTOGENERATEKEY`` is like ``BLKCRYPTOIMPORTKEY``, but it has the + hardware generate the key instead of importing one. It takes in a pointer to + a ``struct blk_crypto_generate_key_arg``. + +- ``BLKCRYPTOPREPAREKEY`` converts a key from long-term wrapped form to + ephemerally-wrapped form. It takes in a pointer to a ``struct + blk_crypto_prepare_key_arg``. The caller must set ``lt_key_ptr`` and + ``lt_key_size`` to the pointer and size (in bytes) of the long-term wrapped + key blob to convert. On success, ``BLKCRYPTOPREPAREKEY`` returns 0 and writes + the resulting ephemerally-wrapped key blob to the buffer pointed to by + ``eph_key_ptr``, which is of maximum size ``eph_key_size``. It also updates + ``eph_key_size`` to be the actual size of the key. On failure, it returns -1 + and sets errno. Errno values of ``EOPNOTSUPP`` and ``EOVERFLOW`` mean the + same as they do for ``BLKCRYPTOIMPORTKEY``. An errno of ``EBADMSG`` indicates + that the long-term wrapped key is invalid. + +Userspace needs to use either ``BLKCRYPTOIMPORTKEY`` or ``BLKCRYPTOGENERATEKEY`` +once to create a key, and then ``BLKCRYPTOPREPAREKEY`` each time the key is +unlocked and added to the kernel. Note that these ioctls have no relevance for +raw keys; they are only for hardware-wrapped keys. + +Testability +----------- + +Both the hardware KDF and the inline encryption itself are well-defined +algorithms that don't depend on any secrets other than the unwrapped key. +Therefore, if the unwrapped key is known to software, these algorithms can be +reproduced in software in order to verify the ciphertext that is written to disk +by the inline encryption hardware. + +However, the unwrapped key will only be known to software for testing if the +"import" functionality is used. Proper testing is not possible in the +"generate" case where the hardware generates the key itself. The correct +operation of the "generate" mode thus relies on the security and correctness of +the hardware RNG and its use to generate the key, as well as the testing of the +"import" mode as that should cover all parts other than the key generation. + +For an example of a test that verifies the ciphertext written to disk in the +"import" mode, see the fscrypt hardware-wrapped key tests in xfstests, or +`Android's vts_kernel_encryption_test +<https://android.googlesource.com/platform/test/vts-testcase/kernel/+/refs/heads/main/encryption/>`_. 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/conf.py b/Documentation/conf.py index 0c2205d536b3..3dad1f90b098 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -47,7 +47,7 @@ from load_config import loadConfig # -- General configuration ------------------------------------------------ # If your documentation needs a minimal Sphinx version, state it here. -needs_sphinx = '2.4.4' +needs_sphinx = '3.4.3' # Add any Sphinx extension module names here, as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom diff --git a/Documentation/core-api/min_heap.rst b/Documentation/core-api/min_heap.rst index 683bc6d09f00..9f57766581df 100644 --- a/Documentation/core-api/min_heap.rst +++ b/Documentation/core-api/min_heap.rst @@ -47,8 +47,8 @@ Example: #define MIN_HEAP_PREALLOCATED(_type, _name, _nr) struct _name { - int nr; /* Number of elements in the heap */ - int size; /* Maximum number of elements that can be held */ + size_t nr; /* Number of elements in the heap */ + size_t size; /* Maximum number of elements that can be held */ _type *data; /* Pointer to the heap data */ _type preallocated[_nr]; /* Static preallocated array */ } diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index ecccc0473da9..4bdc394e86af 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -661,7 +661,7 @@ Do *not* use it from C. Thanks ====== -If you add other %p extensions, please extend <lib/test_printf.c> with -one or more test cases, if at all feasible. +If you add other %p extensions, please extend <lib/tests/printf_kunit.c> +with one or more test cases, if at all feasible. Thank you for your cooperation and attention. 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/this_cpu_ops.rst b/Documentation/core-api/this_cpu_ops.rst index 91acbcf30e9b..533ac5dd5750 100644 --- a/Documentation/core-api/this_cpu_ops.rst +++ b/Documentation/core-api/this_cpu_ops.rst @@ -138,12 +138,22 @@ get_cpu/put_cpu sequence requires. No processor number is available. Instead, the offset of the local per cpu area is simply added to the per cpu offset. -Note that this operation is usually used in a code segment when -preemption has been disabled. The pointer is then used to -access local per cpu data in a critical section. When preemption -is re-enabled this pointer is usually no longer useful since it may -no longer point to per cpu data of the current processor. - +Note that this operation can only be used in code segments where +smp_processor_id() may be used, for example, where preemption has been +disabled. The pointer is then used to access local per cpu data in a +critical section. When preemption is re-enabled this pointer is usually +no longer useful since it may no longer point to per cpu data of the +current processor. + +The special cases where it makes sense to obtain a per-CPU pointer in +preemptible code are addressed by raw_cpu_ptr(), but such use cases need +to handle cases where two different CPUs are accessing the same per cpu +variable, which might well be that of a third CPU. These use cases are +typically performance optimizations. For example, SRCU implements a pair +of counters as a pair of per-CPU variables, and rcu_read_lock_nmisafe() +uses raw_cpu_ptr() to get a pointer to some CPU's counter, and uses +atomic_inc_long() to handle migration between the raw_cpu_ptr() and +the atomic_inc_long(). Per cpu variables and offsets ----------------------------- 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/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index d81c42d1063e..8575178aa87f 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -203,7 +203,7 @@ they happen concurrently in different threads, and at least one of them is a least one is a write. For a more thorough discussion and definition, see `"Plain Accesses and Data Races" in the LKMM`_. -.. _"Plain Accesses and Data Races" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/explanation.txt#n1922 +.. _"Plain Accesses and Data Races" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/explanation.txt?id=8f6629c004b193d23612641c3607e785819e97ab#n2164 Relationship with the Linux-Kernel Memory Consistency Model (LKMM) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst index fdb1df86783a..18c2da67fae4 100644 --- a/Documentation/dev-tools/kselftest.rst +++ b/Documentation/dev-tools/kselftest.rst @@ -347,7 +347,7 @@ kselftest. We use kselftests for lib/ as an example. 1. Create the test module 2. Create the test script that will run (load/unload) the module - e.g. ``tools/testing/selftests/lib/printf.sh`` + e.g. ``tools/testing/selftests/lib/bitmap.sh`` 3. Add line to config file e.g. ``tools/testing/selftests/lib/config`` diff --git a/Documentation/devicetree/bindings/arm/apple.yaml b/Documentation/devicetree/bindings/arm/apple.yaml index dc9aab19ff11..da60e9de1cfb 100644 --- a/Documentation/devicetree/bindings/arm/apple.yaml +++ b/Documentation/devicetree/bindings/arm/apple.yaml @@ -57,6 +57,25 @@ description: | - iPad Pro (2nd Generation) (10.5 Inch) - iPad Pro (2nd Generation) (12.9 Inch) + Devices based on the "T2" SoC: + + - Apple T2 MacBookPro15,2 (j132) + - Apple T2 iMacPro1,1 (j137) + - Apple T2 MacBookAir8,2 (j140a) + - Apple T2 MacBookAir8,1 (j140k) + - Apple T2 MacBookPro16,1 (j152f) + - Apple T2 MacPro7,1 (j160) + - Apple T2 Macmini8,1 (j174) + - Apple T2 iMac20,1 (j185) + - Apple T2 iMac20,2 (j185f) + - Apple T2 MacBookPro15,4 (j213) + - Apple T2 MacBookPro16,2 (j214k) + - Apple T2 MacBookPro16,4 (j215) + - Apple T2 MacBookPro16,3 (j223) + - Apple T2 MacBookAir9,1 (j230k) + - Apple T2 MacBookPro15,1 (j680) + - Apple T2 MacBookPro15,3 (j780) + Devices based on the "A11" SoC: - iPhone 8 @@ -211,6 +230,28 @@ properties: - const: apple,t8011 - const: apple,arm-platform + - description: Apple T2 SoC based platforms + items: + - enum: + - apple,j132 # Apple T2 MacBookPro15,2 (j132) + - apple,j137 # Apple T2 iMacPro1,1 (j137) + - apple,j140a # Apple T2 MacBookAir8,2 (j140a) + - apple,j140k # Apple T2 MacBookAir8,1 (j140k) + - apple,j152f # Apple T2 MacBookPro16,1 (j152f) + - apple,j160 # Apple T2 MacPro7,1 (j160) + - apple,j174 # Apple T2 Macmini8,1 (j174) + - apple,j185 # Apple T2 iMac20,1 (j185) + - apple,j185f # Apple T2 iMac20,2 (j185f) + - apple,j213 # Apple T2 MacBookPro15,4 (j213) + - apple,j214k # Apple T2 MacBookPro16,2 (j214k) + - apple,j215 # Apple T2 MacBookPro16,4 (j215) + - apple,j223 # Apple T2 MacBookPro16,3 (j223) + - apple,j230k # Apple T2 MacBookAir9,1 (j230k) + - apple,j680 # Apple T2 MacBookPro15,1 (j680) + - apple,j780 # Apple T2 MacBookPro15,3 (j780) + - const: apple,t8012 + - const: apple,arm-platform + - description: Apple A11 SoC based platforms items: - enum: diff --git a/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml b/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml index 673277a7a224..5001f4d5a0dc 100644 --- a/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml +++ b/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml @@ -22,6 +22,11 @@ properties: compatible: items: - enum: + - apple,s5l8960x-pmgr + - apple,t7000-pmgr + - apple,s8000-pmgr + - apple,t8010-pmgr + - apple,t8015-pmgr - apple,t8103-pmgr - apple,t8112-pmgr - apple,t6000-pmgr 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/arm,morello.yaml b/Documentation/devicetree/bindings/arm/arm,morello.yaml new file mode 100644 index 000000000000..e843b97fa485 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,morello.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,morello.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Morello Platforms + +maintainers: + - Vincenzo Frascino <vincenzo.frascino@arm.com> + +description: |+ + The Morello architecture is an experimental extension to Armv8.2-A, + which extends the AArch64 state with the principles proposed in + version 7 of the Capability Hardware Enhanced RISC Instructions + (CHERI) ISA. + + ARM's Morello Platforms are built as a research project to explore + capability architectures based on arm. + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: Arm Morello System Platforms + items: + - enum: + - arm,morello-sdp + - arm,morello-fvp + - const: arm,morello + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml index 0ec29366e6c2..3a34b7a2e8d4 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml @@ -23,8 +23,6 @@ properties: - const: atmel,at91rm9200 - items: - enum: - - olimex,sam9-l9260 - - enum: - atmel,at91sam9260 - atmel,at91sam9261 - atmel,at91sam9263 @@ -36,6 +34,37 @@ properties: - atmel,at91sam9x60 - const: atmel,at91sam9 + - description: Olimex SAM9-L9260 + items: + - const: olimex,sam9-l9260 + - const: atmel,at91sam9260 + - const: atmel,at91sam9 + + - description: Calao USB A9260 + items: + - const: calao,usb-a9260 + - const: atmel,at91sam9260 + - const: atmel,at91sam9 + + - description: Calao USB A9263 + items: + - const: calao,usb-a9263 + - const: atmel,at91sam9263 + - const: atmel,at91sam9 + + - description: Calao USB A9G20 + items: + - const: calao,usb-a9g20 + - const: atmel,at91sam9g20 + - const: atmel,at91sam9 + + - description: Calao USB A9G20-LPW + items: + - const: calao,usb-a9g20-lpw + - const: calao,usb-a9g20 + - const: atmel,at91sam9g20 + - const: atmel,at91sam9 + - items: - enum: - overkiz,kizboxmini-base # Overkiz kizbox Mini Base Board diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt index 1a173e92bb13..d3821f651e72 100644 --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt @@ -2,6 +2,7 @@ Atmel system registers Chipid required properties: - compatible: Should be "atmel,sama5d2-chipid" or "microchip,sama7g5-chipid" + "microchip,sama7d65-chipid" - reg : Should contain registers location and length PIT Timer required properties: diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index 73dd73d2d4fa..2e666b2a4dcd 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -177,6 +177,7 @@ properties: - arm,neoverse-v2 - arm,neoverse-v3 - arm,neoverse-v3ae + - arm,rainier - brcm,brahma-b15 - brcm,brahma-b53 - brcm,vulcan diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 0db2cbd7891f..1b90870958a2 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -97,6 +97,7 @@ properties: - i2se,duckbill - i2se,duckbill-2 - karo,tx28 # Ka-Ro electronics TX28 module + - lwn,imx28-btt3 - lwn,imx28-xea - msr,m28cu3 # M28 SoM with custom base board - schulercontrol,imx28-sps1 @@ -296,7 +297,6 @@ properties: - technexion,imx6q-pico-pi # TechNexion i.MX6Q Pico-Pi - technologic,imx6q-ts4900 - technologic,imx6q-ts7970 - - toradex,apalis_imx6q # Apalis iMX6 Modules - udoo,imx6q-udoo # Udoo i.MX6 Quad Board - uniwest,imx6q-evi # Uniwest Evi - variscite,dt6customboard @@ -490,7 +490,6 @@ properties: - technexion,imx6dl-pico-pi # TechNexion i.MX6DL Pico-Pi - technologic,imx6dl-ts4900 - technologic,imx6dl-ts7970 - - toradex,colibri_imx6dl # Colibri iMX6 Modules - udoo,imx6dl-udoo # Udoo i.MX6 Dual-lite Board - vdl,lanmcu # Van der Laan LANMCU board - wand,imx6dl-wandboard # Wandboard i.MX6 Dual Lite Board @@ -688,6 +687,12 @@ properties: - const: phytec,imx6ul-pcl063 # PHYTEC phyCORE-i.MX 6UL - const: fsl,imx6ul + - description: i.MX6UL Variscite VAR-SOM-MX6 Boards + items: + - const: variscite,mx6ulconcerto + - const: variscite,var-som-imx6ul + - const: fsl,imx6ul + - description: Kontron BL i.MX6UL (N631X S) Board items: - const: kontron,bl-imx6ul # Kontron BL i.MX6UL Carrier Board @@ -730,9 +735,6 @@ properties: - joz,jozacp # JOZ Access Point - kontron,sl-imx6ull # Kontron SL i.MX6ULL SoM - myir,imx6ull-mys-6ulx-eval # MYiR Tech iMX6ULL Evaluation Board - - toradex,colibri-imx6ull # Colibri iMX6ULL Modules - - toradex,colibri-imx6ull-emmc # Colibri iMX6ULL 1GB (eMMC) Module - - toradex,colibri-imx6ull-wifi # Colibri iMX6ULL Wi-Fi / BT Modules - uni-t,uti260b # UNI-T UTi260B Thermal Camera - const: fsl,imx6ull @@ -891,8 +893,6 @@ properties: - technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit - technexion,imx7d-pico-nymph # TechNexion i.MX7D Pico-Nymph - technexion,imx7d-pico-pi # TechNexion i.MX7D Pico-Pi - - toradex,colibri-imx7d # Colibri iMX7D Module - - toradex,colibri-imx7d-emmc # Colibri iMX7D 1GB (eMMC) Module - zii,imx7d-rmu2 # ZII RMU2 Board - zii,imx7d-rpu2 # ZII RPU2 Board - const: fsl,imx7d @@ -962,9 +962,6 @@ properties: - innocomm,wb15-evk # i.MX8MM Innocomm EVK board with WB15 SoM - kontron,imx8mm-sl # i.MX8MM Kontron SL (N801X) SOM - kontron,imx8mm-osm-s # i.MX8MM Kontron OSM-S (N802X) SOM - - toradex,verdin-imx8mm # Verdin iMX8M Mini Modules - - toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Modules without Wi-Fi / BT - - toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Modules - prt,prt8mm # i.MX8MM Protonic PRT8MM Board - const: fsl,imx8mm @@ -1098,12 +1095,12 @@ properties: - gateworks,imx8mp-gw74xx # i.MX8MP Gateworks Board - gateworks,imx8mp-gw75xx-2x # i.MX8MP Gateworks Board - gateworks,imx8mp-gw82xx-2x # i.MX8MP Gateworks Board + - skov,imx8mp-skov-basic # SKOV i.MX8MP baseboard without frontplate - skov,imx8mp-skov-revb-hdmi # SKOV i.MX8MP climate control without panel - skov,imx8mp-skov-revb-lt6 # SKOV i.MX8MP climate control with 7” panel - skov,imx8mp-skov-revb-mi1010ait-1cp1 # SKOV i.MX8MP climate control with 10.1" panel - - toradex,verdin-imx8mp # Verdin iMX8M Plus Modules - - toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Modules without Wi-Fi / BT - - toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Modules + - skov,imx8mp-skov-revc-bd500 # SKOV i.MX8MP climate control with LED frontplate + - skov,imx8mp-skov-revc-tian-g07017 # SKOV i.MX8MP climate control with 7" panel - ysoft,imx8mp-iota2-lumpy # Y Soft i.MX8MP IOTA2 Lumpy Board - const: fsl,imx8mp @@ -1273,8 +1270,6 @@ properties: - enum: - fsl,imx8qm-mek # i.MX8QM MEK Board - fsl,imx8qm-mek-revd # i.MX8QM MEK Rev D Board - - toradex,apalis-imx8 # Apalis iMX8 Modules - - toradex,apalis-imx8-v1.1 # Apalis iMX8 V1.1 Modules - const: fsl,imx8qm - description: i.MX8QM Boards with Toradex Apalis iMX8 Modules @@ -1355,6 +1350,7 @@ properties: - description: i.MX95 based Boards items: - enum: + - fsl,imx95-15x15-evk # i.MX95 15x15 EVK Board - fsl,imx95-19x19-evk # i.MX95 19x19 EVK Board - const: fsl,imx95 @@ -1435,7 +1431,6 @@ properties: - fsl,vf610-twr # VF610 Tower Board - lwn,bk4 # Liebherr BK4 controller - phytec,vf610-cosmic # PHYTEC Cosmic/Cosmic+ Board - - toradex,vf610-colibri_vf61 # Colibri VF61 Modules - const: fsl,vf610 - description: Toradex Colibri VF61 Module on Colibri Evaluation Board diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml index e20b5c9b16bc..99961e5282e5 100644 --- a/Documentation/devicetree/bindings/arm/google.yaml +++ b/Documentation/devicetree/bindings/arm/google.yaml @@ -34,10 +34,11 @@ properties: const: '/' compatible: oneOf: - - description: Google Pixel 6 / Oriole + - description: Google Pixel 6 or 6 Pro (Oriole or Raven) items: - enum: - google,gs101-oriole + - google,gs101-raven - const: google,gs101 # Bootloader requires empty ect node to be present diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.yaml index 6905d29f3108..51e1386f0e01 100644 --- a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.yaml +++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.yaml @@ -18,6 +18,7 @@ properties: items: - enum: - cznic,turris-mox + - glinet,gl-mv1000 - globalscale,espressobin - marvell,armada-3720-db - methode,edpu diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml index 538d91be8857..4bc7454a5d3a 100644 --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml @@ -23,6 +23,9 @@ properties: - description: Armada 7040 SoC items: + - enum: + - globalscale,mochabin + - marvell,armada7040-db - const: marvell,armada7040 - const: marvell,armada-ap806-quad - const: marvell,armada-ap806 @@ -35,10 +38,32 @@ properties: - description: Armada 8040 SoC items: + - enum: + - iei,puzzle-m801 + - marvell,armada8040-db + - solidrun,clearfog-gt-8k - const: marvell,armada8040 - const: marvell,armada-ap806-quad - const: marvell,armada-ap806 + - description: Armada 8040 SoC MACCHIATOBin Boards + items: + - enum: + - marvell,armada8040-mcbin-doubleshot + - marvell,armada8040-mcbin-singleshot + - const: marvell,armada8040-mcbin + - const: marvell,armada8040 + - const: marvell,armada-ap806-quad + - const: marvell,armada-ap806 + + - description: Armada 8080 SoC + items: + - enum: + - marvell,armada-8080-db + - const: marvell,armada-8080 + - const: marvell,armada-ap810-octa + - const: marvell,armada-ap810 + - description: Armada CN9130 SoC with no external CP items: - const: marvell,cn9130 diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-8kp.txt b/Documentation/devicetree/bindings/arm/marvell/armada-8kp.txt deleted file mode 100644 index f3e9624534c6..000000000000 --- a/Documentation/devicetree/bindings/arm/marvell/armada-8kp.txt +++ /dev/null @@ -1,15 +0,0 @@ -Marvell Armada 8KPlus Platforms Device Tree Bindings ----------------------------------------------------- - -Boards using a SoC of the Marvell Armada 8KP families must carry -the following root node property: - - - compatible, with one of the following values: - - - "marvell,armada-8080", "marvell,armada-ap810-octa", "marvell,armada-ap810" - when the SoC being used is the Armada 8080 - -Example: - -compatible = "marvell,armada-8080-db", "marvell,armada-8080", - "marvell,armada-ap810-octa", "marvell,armada-ap810" diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 3ce34d68c213..108ae5e0185d 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -414,6 +414,11 @@ properties: - const: mediatek,mt8365 - items: - enum: + - mediatek,mt8370-evk + - const: mediatek,mt8370 + - const: mediatek,mt8188 + - items: + - enum: - mediatek,mt8390-evk - const: mediatek,mt8390 - const: mediatek,mt8188 diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml b/Documentation/devicetree/bindings/arm/pmu.yaml index a148ff54f2b8..295963a3cae7 100644 --- a/Documentation/devicetree/bindings/arm/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/pmu.yaml @@ -67,6 +67,7 @@ properties: - arm,neoverse-v2-pmu - arm,neoverse-v3-pmu - arm,neoverse-v3ae-pmu + - arm,rainier-pmu - brcm,vulcan-pmu - cavium,thunder-pmu - nvidia,denver-pmu 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/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 522a6f0450ea..650fb833d96e 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -49,6 +49,11 @@ properties: - anbernic,rg-arc-s - const: rockchip,rk3566 + - description: Ariaboard Photonicat + items: + - const: ariaboard,photonicat + - const: rockchip,rk3568 + - description: ArmSoM Sige5 board items: - const: armsom,sige5 @@ -178,6 +183,13 @@ properties: - const: engicam,px30-core - const: rockchip,px30 + - description: Firefly iCore-3588Q-based boards + items: + - enum: + - mntre,reform2-rcore + - const: firefly,icore-3588q + - const: rockchip,rk3588 + - description: Firefly Core-3588J-based boards items: - enum: @@ -236,6 +248,11 @@ properties: - firefly,roc-rk3399-pc-plus - const: rockchip,rk3399 + - description: Firefly ROC-RK3576-PC + items: + - const: firefly,roc-rk3576-pc + - const: rockchip,rk3576 + - description: Firefly Station M2 items: - const: firefly,rk3566-roc-pc @@ -862,6 +879,11 @@ properties: - const: radxa,rock-4c-plus - const: rockchip,rk3399 + - description: Radxa ROCK 4D + items: + - const: radxa,rock-4d + - const: rockchip,rk3576 + - description: Radxa ROCK 4SE items: - const: radxa,rock-4se @@ -1136,11 +1158,12 @@ properties: - const: xunlong,orangepi-3b - const: rockchip,rk3566 - - description: Xunlong Orange Pi 5 Max/Plus + - description: Xunlong Orange Pi 5 Max/Plus/Ultra items: - enum: - xunlong,orangepi-5-max - xunlong,orangepi-5-plus + - xunlong,orangepi-5-ultra - const: rockchip,rk3588 - description: Xunlong Orange Pi R1 Plus / LTS diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml index 932f981265cc..52016a141227 100644 --- a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml @@ -53,11 +53,17 @@ properties: reg: maxItems: 1 + power-controller: + type: object + + reboot-mode: + type: object + required: - compatible - reg -additionalProperties: true +additionalProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml index d083d8ad48b7..ed97652c8492 100644 --- a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml @@ -21,6 +21,8 @@ properties: - st,stm32f4-gcan - st,stm32mp151-pwr-mcu - st,stm32mp157-syscfg + - st,stm32mp21-syscfg + - st,stm32mp23-syscfg - st,stm32mp25-syscfg - const: syscon - items: diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index b6c56d4ce6b9..5fee2f38ff25 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -51,9 +51,16 @@ properties: - st,stm32mp135f-dk - const: st,stm32mp135 + - description: ST STM32MP133 based Boards + items: + - enum: + - pri,prihmb # Priva E-Measuringbox board + - const: st,stm32mp133 + - description: ST STM32MP151 based Boards items: - enum: + - ply,plyaqm # Plymovent AQM board - prt,mecio1r0 # Protonic MECIO1r0 - prt,mect1s # Protonic MECT1S - prt,prtt1a # Protonic PRTT1A @@ -94,6 +101,8 @@ properties: - description: Octavo OSD32MP153 System-in-Package based boards items: - enum: + - lxa,stm32mp153c-fairytux2-gen1 # Linux Automation FairyTux 2 (Generation 1) + - lxa,stm32mp153c-fairytux2-gen2 # Linux Automation FairyTux 2 (Generation 2) - lxa,stm32mp153c-tac-gen3 # Linux Automation TAC (Generation 3) - const: oct,stm32mp153x-osd32 - const: st,stm32mp153 @@ -178,9 +187,22 @@ properties: - description: ST STM32MP257 based Boards items: - enum: + - st,stm32mp257f-dk - st,stm32mp257f-ev1 - const: st,stm32mp257 + - description: ST STM32MP235 based Boards + items: + - enum: + - st,stm32mp235f-dk + - const: st,stm32mp235 + + - description: ST STM32MP215 based Boards + items: + - enum: + - st,stm32mp215f-dk + - const: st,stm32mp215 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 046536d02706..f536cdd2c1a6 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -589,6 +589,11 @@ properties: - const: emlid,neutis-n5h3 - const: allwinner,sun8i-h3 + - description: NetCube Systems Kumquat + items: + - const: netcube,kumquat + - const: allwinner,sun8i-v3s + - description: NextThing Co. CHIP items: - const: nextthing,chip diff --git a/Documentation/devicetree/bindings/arm/ti/omap.yaml b/Documentation/devicetree/bindings/arm/ti/omap.yaml index 93e04a109a12..3603edd7361d 100644 --- a/Documentation/devicetree/bindings/arm/ti/omap.yaml +++ b/Documentation/devicetree/bindings/arm/ti/omap.yaml @@ -141,6 +141,13 @@ properties: - const: ti,omap4430 - const: ti,omap4 + - description: OMAP4 PandaBoard Revision A4 and later + items: + - const: ti,omap4-panda-a4 + - const: ti,omap4-panda + - const: ti,omap4430 + - const: ti,omap4 + - description: OMAP4 DuoVero with Parlor expansion board/daughter board items: - const: gumstix,omap4-duovero-parlor diff --git a/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml b/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml index 9952e0ef7767..6ad78429dc74 100644 --- a/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml +++ b/Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml @@ -163,11 +163,9 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/xlnx-zynqmp-clk.h> #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/power/xlnx-zynqmp-power.h> #include <dt-bindings/reset/xlnx-zynqmp-resets.h> - #include <dt-bindings/clock/xlnx-zynqmp-clk.h> #include <dt-bindings/phy/phy.h> sata: ahci@fd0c0000 { @@ -175,7 +173,7 @@ examples: reg = <0xfd0c0000 0x200>; interrupt-parent = <&gic>; interrupts = <0 133 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&zynqmp_clk SATA_REF>; + clocks = <&zynqmp_clk 22>; ceva,p0-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>; ceva,p0-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>; ceva,p0-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>; diff --git a/Documentation/devicetree/bindings/ata/fsl,pq-sata.yaml b/Documentation/devicetree/bindings/ata/fsl,pq-sata.yaml new file mode 100644 index 000000000000..1d19ee832f0c --- /dev/null +++ b/Documentation/devicetree/bindings/ata/fsl,pq-sata.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/fsl,pq-sata.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale 8xxx/3.0 Gb/s SATA nodes + +maintainers: + - J. Neuschäfer <j.ne@posteo.net> + +description: + SATA nodes are defined to describe on-chip Serial ATA controllers. + Each SATA controller should have its own node. + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,mpc8377-sata + - fsl,mpc8536-sata + - fsl,mpc8315-sata + - fsl,mpc8379-sata + - const: fsl,pq-sata + - const: fsl,pq-sata-v2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + cell-index: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 3, 4] + description: | + 1 for controller @ 0x18000 + 2 for controller @ 0x19000 + 3 for controller @ 0x1a000 + 4 for controller @ 0x1b000 + +required: + - compatible + - interrupts + - cell-index + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + sata@18000 { + compatible = "fsl,mpc8379-sata", "fsl,pq-sata"; + reg = <0x18000 0x1000>; + cell-index = <1>; + interrupts = <44 IRQ_TYPE_LEVEL_LOW>; + }; + +... diff --git a/Documentation/devicetree/bindings/ata/fsl-sata.txt b/Documentation/devicetree/bindings/ata/fsl-sata.txt deleted file mode 100644 index fd63bb3becc9..000000000000 --- a/Documentation/devicetree/bindings/ata/fsl-sata.txt +++ /dev/null @@ -1,28 +0,0 @@ -* Freescale 8xxx/3.0 Gb/s SATA nodes - -SATA nodes are defined to describe on-chip Serial ATA controllers. -Each SATA port should have its own node. - -Required properties: -- compatible : compatible list, contains 2 entries, first is - "fsl,CHIP-sata", where CHIP is the processor - (mpc8315, mpc8379, etc.) and the second is - "fsl,pq-sata" -- interrupts : <interrupt mapping for SATA IRQ> -- cell-index : controller index. - 1 for controller @ 0x18000 - 2 for controller @ 0x19000 - 3 for controller @ 0x1a000 - 4 for controller @ 0x1b000 - -Optional properties: -- reg : <registers mapping> - -Example: - sata@18000 { - compatible = "fsl,mpc8379-sata", "fsl,pq-sata"; - reg = <0x18000 0x1000>; - cell-index = <1>; - interrupts = <2c 8>; - interrupt-parent = < &ipic >; - }; 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,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml index 0858fd635282..4cdff6161bf0 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml @@ -8,6 +8,7 @@ title: Qualcomm Graphics Clock & Reset Controller maintainers: - Taniya Das <quic_tdas@quicinc.com> + - Imran Shaik <quic_imrashai@quicinc.com> description: | Qualcomm graphics clock control module provides the clocks, resets and power @@ -23,10 +24,12 @@ description: | include/dt-bindings/clock/qcom,gpucc-sm8150.h include/dt-bindings/clock/qcom,gpucc-sm8250.h include/dt-bindings/clock/qcom,gpucc-sm8350.h + include/dt-bindings/clock/qcom,qcs8300-gpucc.h properties: compatible: enum: + - qcom,qcs8300-gpucc - qcom,sdm845-gpucc - qcom,sa8775p-gpucc - qcom,sc7180-gpucc 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,sa8775p-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sa8775p-camcc.yaml index 36a60d8f5ae3..81623f59d11d 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sa8775p-camcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sa8775p-camcc.yaml @@ -8,16 +8,20 @@ title: Qualcomm Camera Clock & Reset Controller on SA8775P maintainers: - Taniya Das <quic_tdas@quicinc.com> + - Imran Shaik <quic_imrashai@quicinc.com> description: | Qualcomm camera clock control module provides the clocks, resets and power domains on SA8775p. - See also: include/dt-bindings/clock/qcom,sa8775p-camcc.h + See also: + include/dt-bindings/clock/qcom,qcs8300-camcc.h + include/dt-bindings/clock/qcom,sa8775p-camcc.h properties: compatible: enum: + - qcom,qcs8300-camcc - qcom,sa8775p-camcc clocks: diff --git a/Documentation/devicetree/bindings/clock/qcom,sa8775p-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sa8775p-videocc.yaml index 928131bff4c1..07e5d811d816 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sa8775p-videocc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,sa8775p-videocc.yaml @@ -18,6 +18,7 @@ description: | properties: compatible: enum: + - qcom,qcs8300-videocc - qcom,sa8775p-videocc clocks: 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,rk3528-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3528-cru.yaml new file mode 100644 index 000000000000..5a3ec902351c --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3528-cru.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/rockchip,rk3528-cru.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3528 Clock and Reset Controller + +maintainers: + - Yao Zi <ziyao@disroot.org> + +description: | + The RK3528 clock controller generates the clock and also implements a reset + controller for SoC peripherals. For example, it provides SCLK_UART0 and + PCLK_UART0 as well as SRST_P_UART0 and SRST_S_UART0 for the first UART + module. + Each clock is assigned an identifier, consumer nodes can use it to specify + the clock. All available clock and reset IDs are defined in dt-binding + headers. + +properties: + compatible: + const: rockchip,rk3528-cru + + reg: + maxItems: 1 + + clocks: + items: + - description: External 24MHz oscillator clock + - description: > + 50MHz clock generated by PHY module, for generating GMAC0 clocks only. + + clock-names: + items: + - const: xin24m + - const: gmac0 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - "#clock-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + clock-controller@ff4a0000 { + compatible = "rockchip,rk3528-cru"; + reg = <0xff4a0000 0x30000>; + clocks = <&xin24m>, <&gmac0_clk>; + clock-names = "xin24m", "gmac0"; + #clock-cells = <1>; + #reset-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/samsung,exynos990-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos990-clock.yaml index 9e7944b5f13b..c15cc1752b02 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos990-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos990-clock.yaml @@ -31,6 +31,7 @@ properties: compatible: enum: - samsung,exynos990-cmu-hsi0 + - samsung,exynos990-cmu-peris - samsung,exynos990-cmu-top clocks: @@ -83,6 +84,24 @@ allOf: properties: compatible: contains: + const: samsung,exynos990-cmu-peris + + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: CMU_PERIS BUS clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: bus + + - if: + properties: + compatible: + contains: const: samsung,exynos990-cmu-top then: 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/connector/gocontroll,moduline-module-slot.yaml b/Documentation/devicetree/bindings/connector/gocontroll,moduline-module-slot.yaml new file mode 100644 index 000000000000..a16ae2762d16 --- /dev/null +++ b/Documentation/devicetree/bindings/connector/gocontroll,moduline-module-slot.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/connector/gocontroll,moduline-module-slot.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GOcontroll Moduline Module slot + +maintainers: + - Maud Spierings <maudspierings@gocontroll.com> + +description: + The GOcontroll Moduline module slot represents a connector that fullfills the + Moduline slot specification, and can thus house any IO module that is also + built to this spec. + +properties: + compatible: + const: gocontroll,moduline-module-slot + + reg: + maxItems: 1 + + interrupts: + description: indicates readiness, high means busy. + maxItems: 1 + reset-gpios: + description: resets the module, active low. + maxItems: 1 + sync-gpios: + description: sync line between all module slots. + maxItems: 1 + + vdd-supply: + description: low power 3v3 supply generally for the microcontroller. + vddp-supply: + description: medium power 5v0 supply for on module low power peripherals. + vddhpp-supply: + description: high power 6v-8v supply for on module high power peripherals. + power-supply: + description: high power 6v-30v supply for high power module circuits. + + i2c-bus: + description: i2c bus shared between module slots and the SoC + $ref: /schemas/types.yaml#/definitions/phandle + + slot-number: + description: + The number of the module slot representing the location of on the pcb. + This enables access to the modules based on slot location. + $ref: /schemas/types.yaml#/definitions/uint32 + + spi-max-frequency: true + +required: + - compatible + - reg + - reset-gpios + - interrupts + - sync-gpios + - i2c-bus + - slot-number + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + connector@0 { + reg = <0>; + compatible = "gocontroll,moduline-module-slot"; + reset-gpios = <&gpio5 10 GPIO_ACTIVE_LOW>; + sync-gpios = <&gpio4 16 GPIO_ACTIVE_HIGH>; + interrupt-parent = <&gpio4>; + interrupts = <5 IRQ_TYPE_EDGE_FALLING>; + vdd-supply = <®_3v3_per>; + vddp-supply = <®_5v0>; + vddhpp-supply = <®_6v4>; + i2c-bus = <&i2c2>; + slot-number = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml index e937eb7355e7..e0242bed3342 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml @@ -34,6 +34,7 @@ properties: - description: v2 of CPUFREQ HW (EPSS) items: - enum: + - qcom,qcs8300-cpufreq-epss - qcom,qdu1000-cpufreq-epss - qcom,sa8255p-cpufreq-epss - qcom,sa8775p-cpufreq-epss @@ -111,22 +112,20 @@ allOf: enum: - qcom,qcm2290-cpufreq-hw - qcom,sar2130p-cpufreq-epss + - qcom,sdx75-cpufreq-epss then: properties: reg: - minItems: 1 maxItems: 1 reg-names: - minItems: 1 maxItems: 1 interrupts: - minItems: 1 maxItems: 1 interrupt-names: - minItems: 1 + maxItems: 1 - if: properties: @@ -135,6 +134,7 @@ allOf: enum: - qcom,qdu1000-cpufreq-epss - qcom,sa8255p-cpufreq-epss + - qcom,sa8775p-cpufreq-epss - qcom,sc7180-cpufreq-hw - qcom,sc8180x-cpufreq-hw - qcom,sc8280xp-cpufreq-epss @@ -160,12 +160,14 @@ allOf: interrupt-names: minItems: 2 + maxItems: 2 - if: properties: compatible: contains: enum: + - qcom,qcs8300-cpufreq-epss - qcom,sc7280-cpufreq-epss - qcom,sm8250-cpufreq-epss - qcom,sm8350-cpufreq-epss @@ -187,6 +189,7 @@ allOf: interrupt-names: minItems: 3 + maxItems: 3 - if: properties: @@ -211,7 +214,31 @@ allOf: interrupt-names: minItems: 2 + maxItems: 2 + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8650-cpufreq-epss + then: + properties: + reg: + minItems: 4 + maxItems: 4 + + reg-names: + minItems: 4 + maxItems: 4 + + interrupts: + minItems: 4 + maxItems: 4 + + interrupt-names: + minItems: 4 + maxItems: 4 examples: - | 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/powertip,hx8238a.yaml b/Documentation/devicetree/bindings/display/panel/powertip,hx8238a.yaml new file mode 100644 index 000000000000..b7d74faeb5d5 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/powertip,hx8238a.yaml @@ -0,0 +1,29 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/powertip,hx8238a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Powertip Electronic Technology Co. 320 x 240 LCD panel + +maintainers: + - Lukasz Majewski <lukma@denx.de> + +allOf: + - $ref: panel-dpi.yaml# + +properties: + compatible: + items: + - const: powertip,hx8238a + - {} # panel-dpi, but not listed here to avoid false select + + height-mm: true + panel-timing: true + port: true + power-supply: true + width-mm: true + +additionalProperties: false + +... diff --git a/Documentation/devicetree/bindings/display/panel/powertip,st7272.yaml b/Documentation/devicetree/bindings/display/panel/powertip,st7272.yaml new file mode 100644 index 000000000000..f3622800f13f --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/powertip,st7272.yaml @@ -0,0 +1,29 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/powertip,st7272.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Powertip Electronic Technology Co. 320 x 240 LCD panel + +maintainers: + - Lukasz Majewski <lukma@denx.de> + +allOf: + - $ref: panel-dpi.yaml# + +properties: + compatible: + items: + - const: powertip,st7272 + - {} # panel-dpi, but not listed here to avoid false select + + height-mm: true + panel-timing: true + port: true + power-supply: true + width-mm: true + +additionalProperties: false + +... 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/display/tegra/nvidia,tegra114-mipi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml index f448624dd779..193ddb105283 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml @@ -17,6 +17,7 @@ properties: compatible: enum: - nvidia,tegra114-mipi + - nvidia,tegra124-mipi - nvidia,tegra210-mipi - nvidia,tegra186-mipi diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index 55e3e490d0e6..31c4ffcb599c 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -23,7 +23,7 @@ properties: compatible: enum: - ti,am625-dss - - ti,am62a7,dss + - ti,am62a7-dss - ti,am65x-dss reg: diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml index ac3198953b8e..b5399c65a731 100644 --- a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml +++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml @@ -75,7 +75,6 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/xlnx-zynqmp-clk.h> fpd_dma_chan1: dma-controller@fd500000 { compatible = "xlnx,zynqmp-dma-1.0"; @@ -84,7 +83,7 @@ examples: interrupts = <0 117 0x4>; #dma-cells = <1>; clock-names = "clk_main", "clk_apb"; - clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>; + clocks = <&zynqmp_clk 19>, <&zynqmp_clk 31>; xlnx,bus-width = <128>; dma-coherent; }; 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/firmware/fsl,scu.yaml b/Documentation/devicetree/bindings/firmware/fsl,scu.yaml index 557e524786c2..f9ba18f06369 100644 --- a/Documentation/devicetree/bindings/firmware/fsl,scu.yaml +++ b/Documentation/devicetree/bindings/firmware/fsl,scu.yaml @@ -45,6 +45,18 @@ properties: Keys provided by the SCU $ref: /schemas/input/fsl,scu-key.yaml + reset-controller: + type: object + properties: + compatible: + const: fsl,imx-scu-reset + '#reset-cells': + const: 1 + required: + - compatible + - '#reset-cells' + additionalProperties: false + mboxes: description: A list of phandles of TX MU channels followed by a list of phandles of diff --git a/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml b/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml new file mode 100644 index 000000000000..2cdad1bbae73 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/google,gs101-acpm-ipc.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2024 Linaro Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/google,gs101-acpm-ipc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos ACPM mailbox protocol + +maintainers: + - Tudor Ambarus <tudor.ambarus@linaro.org> + +description: | + ACPM (Alive Clock and Power Manager) is a firmware that operates on the + APM (Active Power Management) module that handles overall power management + activities. ACPM and masters regard each other as independent hardware + component and communicate with each other using mailbox messages and + shared memory. + + This binding is intended to define the interface the firmware implementing + ACPM provides for OSPM in the device tree. + +properties: + compatible: + const: google,gs101-acpm-ipc + + mboxes: + maxItems: 1 + + shmem: + description: + List of phandle pointing to the shared memory (SHM) area. The memory + contains channels configuration data and the TX/RX ring buffers that + are used for passing messages to/from the ACPM firmware. + maxItems: 1 + +required: + - compatible + - mboxes + - shmem + +additionalProperties: false + +examples: + - | + power-management { + compatible = "google,gs101-acpm-ipc"; + mboxes = <&ap2apm_mailbox>; + shmem = <&apm_sram>; + }; diff --git a/Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml b/Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml new file mode 100644 index 000000000000..bbc183200400 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/thead,th1520-aon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: T-HEAD TH1520 AON (Always-On) Firmware + +description: | + The Always-On (AON) subsystem in the TH1520 SoC is responsible for managing + low-power states, system wakeup events, and power management tasks. It is + designed to operate independently in a dedicated power domain, allowing it to + remain functional even during the SoC's deep sleep states. + + At the heart of the AON subsystem is the E902, a low-power core that executes + firmware responsible for coordinating tasks such as power domain control, + clock management, and system wakeup signaling. Communication between the main + SoC and the AON subsystem is handled through a mailbox interface, which + enables message-based interactions with the AON firmware. + +maintainers: + - Michal Wilczynski <m.wilczynski@samsung.com> + +properties: + compatible: + const: thead,th1520-aon + + mboxes: + maxItems: 1 + + mbox-names: + items: + - const: aon + + "#power-domain-cells": + const: 1 + +required: + - compatible + - mboxes + - mbox-names + - "#power-domain-cells" + +additionalProperties: false + +examples: + - | + aon: aon { + compatible = "thead,th1520-aon"; + mboxes = <&mbox_910t 1>; + mbox-names = "aon"; + #power-domain-cells = <1>; + }; 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/gpio/aspeed,ast2400-gpio.yaml b/Documentation/devicetree/bindings/gpio/aspeed,ast2400-gpio.yaml index b9afd07a9d24..b16273e69dfe 100644 --- a/Documentation/devicetree/bindings/gpio/aspeed,ast2400-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/aspeed,ast2400-gpio.yaml @@ -46,6 +46,12 @@ properties: minimum: 12 maximum: 232 +patternProperties: + "-hog(-[0-9]+)?$": + type: object + required: + - gpio-hog + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml b/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml index 33d4e4716516..7ed5f9c4dde9 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml @@ -72,6 +72,9 @@ properties: "#gpio-cells": const: 2 + gpio-ranges: + maxItems: 1 + marvell,pwm-offset: $ref: /schemas/types.yaml#/definitions/uint32 description: Offset in the register map for the pwm registers (in bytes) @@ -96,6 +99,13 @@ properties: - const: axi minItems: 1 +patternProperties: + "^(.+-hog(-[0-9]+)?)$": + type: object + + required: + - gpio-hog + required: - compatible - gpio-controller diff --git a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml index cabda2eab4a2..4fb32e9aec0a 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml @@ -28,6 +28,7 @@ properties: - items: - enum: - fsl,imx93-gpio + - fsl,imx94-gpio - fsl,imx95-gpio - const: fsl,imx8ulp-gpio diff --git a/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml index cf3b1b270aa8..b68159600e2b 100644 --- a/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml @@ -20,7 +20,10 @@ properties: - loongson,ls2k2000-gpio1 - loongson,ls2k2000-gpio2 - loongson,ls3a5000-gpio + - loongson,ls3a6000-gpio # Loongson-3A6000 node GPIO - loongson,ls7a-gpio + - loongson,ls7a2000-gpio1 # LS7A2000 chipset GPIO + - loongson,ls7a2000-gpio2 # LS7A2000 ACPI GPIO - items: - const: loongson,ls2k1000-gpio - const: loongson,ls2k-gpio diff --git a/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml index 3718103e966a..8bca574bb66d 100644 --- a/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml +++ b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml @@ -73,6 +73,43 @@ properties: wakeup-source: true + reset-gpios: + maxItems: 1 + description: + GPIO controlling the (reset active LOW) RESET# pin. + + The active polarity of the GPIO must translate to the low state of the + RESET# pin on the IC, i.e. if a GPIO is directly routed to the RESET# pin + without any inverter, GPIO_ACTIVE_LOW is expected. + + Performing a reset makes all lines initialized to their input (pulled-up) + state. + +allOf: + - if: + properties: + compatible: + not: + contains: + enum: + - nxp,pca9670 + - nxp,pca9671 + - nxp,pca9672 + - nxp,pca9673 + then: + properties: + reset-gpios: false + + # lines-initial-states XOR reset-gpios + # Performing a reset reinitializes all lines to a known state which + # may not match passed lines-initial-states + - if: + required: + - lines-initial-states + then: + properties: + reset-gpios: false + patternProperties: "^(.+-hog(-[0-9]+)?)$": type: object 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/hwinfo/samsung,exynos-chipid.yaml b/Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml index 385aac7161a0..383020450d78 100644 --- a/Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml +++ b/Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml @@ -19,9 +19,11 @@ properties: - enum: - samsung,exynos5433-chipid - samsung,exynos7-chipid + - samsung,exynos7870-chipid - const: samsung,exynos4210-chipid - items: - enum: + - samsung,exynos2200-chipid - samsung,exynos7885-chipid - samsung,exynos8895-chipid - samsung,exynos9810-chipid diff --git a/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml b/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml index ce7f8ce9da0a..236d8b52ef85 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,ad741x.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/adi,ad741x.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml index fd79bf2e0d16..ddb72857c846 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/adi,adm1275.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc2991.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc2991.yaml index 011e5b65c79c..1ff44cb22ef4 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,ltc2991.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,ltc2991.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/adi,ltc2991.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml b/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml index 7f30cfc87350..4faebbb4c7ab 100644 --- a/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml +++ b/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml @@ -23,6 +23,9 @@ properties: alarm-gpios: maxItems: 1 + fan-supply: + description: Power supply for fan + gpio-fan,speed-map: $ref: /schemas/types.yaml#/definitions/uint32-matrix minItems: 2 diff --git a/Documentation/devicetree/bindings/hwmon/lltc,ltc2978.yaml b/Documentation/devicetree/bindings/hwmon/lltc,ltc2978.yaml index 37e1dc9c7dd3..aa801ef1640b 100644 --- a/Documentation/devicetree/bindings/hwmon/lltc,ltc2978.yaml +++ b/Documentation/devicetree/bindings/hwmon/lltc,ltc2978.yaml @@ -12,6 +12,8 @@ maintainers: properties: compatible: enum: + - lltc,lt7170 + - lltc,lt7171 - lltc,ltc2972 - lltc,ltc2974 - lltc,ltc2975 @@ -30,6 +32,7 @@ properties: - lltc,ltc7880 - lltc,ltm2987 - lltc,ltm4664 + - lltc,ltm4673 - lltc,ltm4675 - lltc,ltm4676 - lltc,ltm4677 @@ -46,6 +49,7 @@ properties: description: | list of regulators provided by this controller. Valid names of regulators depend on number of supplies supported per device: + * lt7170, lt7171 : vout0 * ltc2972 vout0 - vout1 * ltc2974, ltc2975 : vout0 - vout3 * ltc2977, ltc2979, ltc2980, ltm2987 : vout0 - vout7 @@ -55,6 +59,7 @@ properties: * ltc7880 : vout0 - vout1 * ltc3883 : vout0 * ltm4664 : vout0 - vout1 + * ltm4673 : vout0 - vout3 * ltm4675, ltm4676, ltm4677, ltm4678 : vout0 - vout1 * ltm4680, ltm4686 : vout0 - vout1 * ltm4700 : vout0 - vout1 diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max20730.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max20730.yaml index 93e86e3b4602..8af0d7458e62 100644 --- a/Documentation/devicetree/bindings/hwmon/maxim,max20730.yaml +++ b/Documentation/devicetree/bindings/hwmon/maxim,max20730.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/maxim,max20730.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml index 4f5837a30773..139a95e00fe5 100644 --- a/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml +++ b/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/maxim,max6639.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml index 2c26104a5e16..24c7697fdc1a 100644 --- a/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml +++ b/Documentation/devicetree/bindings/hwmon/maxim,max6650.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/maxim,max6650.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml new file mode 100644 index 000000000000..d3f06ebc19fa --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/microchip,emc2305.yaml @@ -0,0 +1,111 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/microchip,emc2305.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip EMC2305 SMBus compliant PWM fan controller + +maintainers: + - Michael Shych <michaelsh@nvidia.com> + +description: + Microchip EMC2301/2/3/5 pwm controller which supports up to five programmable + fan control circuits. + +properties: + compatible: + oneOf: + - enum: + - microchip,emc2305 + - items: + - enum: + - microchip,emc2303 + - microchip,emc2302 + - microchip,emc2301 + - const: microchip,emc2305 + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + '#pwm-cells': + const: 3 + description: | + Number of cells in a PWM specifier. + - cell 0: The PWM frequency + - cell 1: The PWM polarity: 0 or PWM_POLARITY_INVERTED + - cell 2: The PWM output config: + - 0 (Open-Drain) + - 1 (Push-Pull) + +patternProperties: + '^fan@[0-4]$': + $ref: fan-common.yaml# + unevaluatedProperties: false + properties: + reg: + description: + The fan number used to determine the associated PWM channel. + maxItems: 1 + + required: + - reg + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/pwm/pwm.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + fan_controller: fan-controller@2f { + compatible = "microchip,emc2305"; + reg = <0x2f>; + #address-cells = <1>; + #size-cells = <0>; + #pwm-cells = <3>; + + fan@0 { + reg = <0x0>; + pwms = <&fan_controller 26000 PWM_POLARITY_INVERTED 1>; + #cooling-cells = <2>; + }; + + fan@1 { + reg = <0x1>; + pwms = <&fan_controller 26000 0 1>; + #cooling-cells = <2>; + }; + + fan@2 { + reg = <0x2>; + pwms = <&fan_controller 26000 0 1>; + #cooling-cells = <2>; + }; + + fan@3 { + reg = <0x3>; + pwms = <&fan_controller 26000 0 1>; + #cooling-cells = <2>; + }; + + fan@4 { + reg = <0x4>; + pwms = <&fan_controller 26000 0 1>; + #cooling-cells = <2>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml index 6e59c8fdef30..4feb76919404 100644 --- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml +++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml @@ -32,6 +32,9 @@ properties: - national,lm89 - national,lm90 - national,lm99 + - nuvoton,nct7716 + - nuvoton,nct7717 + - nuvoton,nct7718 - nxp,sa56004 - onnn,nct1008 - ti,tmp451 @@ -120,6 +123,8 @@ allOf: - dallas,max6659 - dallas,max6695 - dallas,max6696 + - nuvoton,nct7716 + - nuvoton,nct7717 then: patternProperties: "^channel@([0-2])$": @@ -155,6 +160,7 @@ allOf: - national,lm89 - national,lm90 - national,lm99 + - nuvoton,nct7718 - nxp,sa56004 - winbond,w83l771 then: diff --git a/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml index 3d0146e20d3e..b8e500e6cd9f 100644 --- a/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml +++ b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml @@ -76,7 +76,7 @@ properties: - const: murata,ncp03wf104 - const: murata,ncp15xh103 - const: samsung,1404-001221 - # Deprecated "ntp," compatible strings + # Deprecated "ntc," compatible strings - const: ntc,ncp15wb473 deprecated: true - const: ntc,ncp18wb473 diff --git a/Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml b/Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml index e3db642878d4..244470282890 100644 --- a/Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml +++ b/Documentation/devicetree/bindings/hwmon/nuvoton,nct6775.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/nuvoton,nct6775.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7363.yaml b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7363.yaml index c1e5dedc2f6a..625fcf5d3b54 100644 --- a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7363.yaml +++ b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7363.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/nuvoton,nct7363.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml index cd8dcd797031..c16a33227e94 100644 --- a/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml +++ b/Documentation/devicetree/bindings/hwmon/nuvoton,nct7802.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/nuvoton,nct7802.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml index e8feee38c76c..f8bea1c0e94a 100644 --- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml +++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml @@ -28,6 +28,15 @@ properties: reg: maxItems: 1 + gpio-controller: true + + gpio-line-names: + minItems: 84 + maxItems: 84 + + '#gpio-cells': + const: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml b/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml index a32035409cee..78e3d97e2ae5 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,adc128d818.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/ti,adc128d818.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml b/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml index 926be9a29044..fb80456120e1 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,ads7828.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/ti,ads7828.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml index 05a9cb36cd82..bc03781342c0 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/ti,ina2xx.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# @@ -27,6 +26,7 @@ properties: - ti,ina226 - ti,ina230 - ti,ina231 + - ti,ina233 - ti,ina237 - ti,ina238 - ti,ina260 @@ -75,12 +75,41 @@ properties: the alert polarity to active-high. $ref: /schemas/types.yaml#/definitions/flag + ti,maximum-expected-current-microamp: + description: | + This value indicates the maximum current in microamps that you can + expect to measure with ina233 in your circuit. + + This value will be used to calculate the Current_LSB and current/power + coefficient for the pmbus and to calibrate the IC. + minimum: 32768 + maximum: 4294967295 + default: 32768000 + required: - compatible - reg allOf: - $ref: hwmon-common.yaml# + - if: + properties: + compatible: + contains: + enum: + - silergy,sy24655 + - ti,ina209 + - ti,ina219 + - ti,ina220 + - ti,ina226 + - ti,ina230 + - ti,ina231 + - ti,ina237 + - ti,ina238 + - ti,ina260 + then: + properties: + ti,maximum-expected-current-microamp: false unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml b/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml index f553235a7321..63d8cf467806 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,lm87.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/ti,lm87.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml index 227858e76058..cba5b4a1b81f 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/ti,tmp513.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml index f58248c29e22..ee7de53e1918 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/ti,tps23861.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# diff --git a/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml b/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml index 31ce77a4b087..6971ecb314eb 100644 --- a/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml +++ b/Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml @@ -1,7 +1,6 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- - $id: http://devicetree.org/schemas/hwmon/winbond,w83781d.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# 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,ad7606.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml index ab5881d0d017..52d3f1ce3367 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml @@ -146,6 +146,7 @@ properties: maxItems: 2 pwm-names: + minItems: 1 items: - const: convst1 - const: convst2 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/adc/xlnx,zynqmp-ams.yaml b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml index 8cbad7e792b6..a403392fb263 100644 --- a/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml +++ b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml @@ -193,7 +193,6 @@ additionalProperties: false examples: - | - #include <dt-bindings/clock/xlnx-zynqmp-clk.h> bus { #address-cells = <2>; @@ -204,7 +203,7 @@ examples: interrupt-parent = <&gic>; interrupts = <0 56 4>; reg = <0x0 0xffa50000 0x0 0x800>; - clocks = <&zynqmp_clk AMS_REF>; + clocks = <&zynqmp_clk 70>; #address-cells = <1>; #size-cells = <1>; #io-channel-cells = <1>; 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/imagis,ist3038c.yaml b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml index e24cbd960993..bd8ede3a4ad8 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml @@ -19,6 +19,7 @@ properties: - imagis,ist3038 - imagis,ist3038b - imagis,ist3038c + - imagis,ist3038h reg: maxItems: 1 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/allwinner,sun7i-a20-sc-nmi.yaml b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml index f49b43f45f3d..06e3621a8c06 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml @@ -26,6 +26,7 @@ properties: deprecated: true - const: allwinner,sun7i-a20-sc-nmi - const: allwinner,sun9i-a80-nmi + - const: allwinner,sun55i-a523-nmi - items: - enum: - allwinner,sun8i-v3s-nmi diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml index a93744763787..3d60d9e9e208 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml @@ -35,6 +35,9 @@ properties: - amlogic,meson-sm1-gpio-intc - amlogic,meson-a1-gpio-intc - amlogic,meson-s4-gpio-intc + - amlogic,a4-gpio-intc + - amlogic,a4-gpio-ao-intc + - amlogic,a5-gpio-intc - amlogic,c3-gpio-intc - amlogic,t7-gpio-intc - const: amlogic,meson-gpio-intc @@ -49,7 +52,7 @@ properties: amlogic,channel-interrupts: description: Array with the upstream hwirq numbers - minItems: 8 + minItems: 2 maxItems: 12 $ref: /schemas/types.yaml#/definitions/uint32-array @@ -60,6 +63,20 @@ required: - "#interrupt-cells" - amlogic,channel-interrupts +if: + properties: + compatible: + contains: + const: amlogic,a4-gpio-ao-intc +then: + properties: + amlogic,channel-interrupts: + maxItems: 2 +else: + properties: + amlogic,channel-interrupts: + minItems: 8 + additionalProperties: false examples: 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/microchip,lan966x-oic.yaml b/Documentation/devicetree/bindings/interrupt-controller/microchip,lan966x-oic.yaml index b2adc7174177..dca16e202da9 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/microchip,lan966x-oic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/microchip,lan966x-oic.yaml @@ -14,9 +14,8 @@ allOf: description: | The Microchip LAN966x outband interrupt controller (OIC) maps the internal - interrupt sources of the LAN966x device to an external interrupt. - When the LAN966x device is used as a PCI device, the external interrupt is - routed to the PCI interrupt. + interrupt sources of the LAN966x device to a PCI interrupt when the LAN966x + device is used as a PCI device. properties: compatible: 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/interrupt-controller/renesas,rzv2h-icu.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzv2h-icu.yaml index d7ef4f1323a7..3f99c8645767 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,rzv2h-icu.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rzv2h-icu.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/interrupt-controller/renesas,rzv2h-icu.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/V2H(P) Interrupt Control Unit +title: Renesas RZ/{G3E,V2H(P)} Interrupt Control Unit maintainers: - Fabrizio Castro <fabrizio.castro.jz@renesas.com> @@ -20,7 +20,9 @@ description: properties: compatible: - const: renesas,r9a09g057-icu # RZ/V2H(P) + enum: + - renesas,r9a09g047-icu # RZ/G3E + - renesas,r9a09g057-icu # RZ/V2H(P) '#interrupt-cells': description: The first cell is the SPI number of the NMI or the diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml index 190a6499c932..bef00521d5da 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml @@ -91,6 +91,14 @@ properties: Firmware must configure interrupt delegation registers based on interrupt delegation list. + riscv,hart-indexes: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 16384 + description: + A list of hart indexes that APLIC should use to address each hart + that is mentioned in the "interrupts-extended" + dependencies: riscv,delegation: [ "riscv,children" ] diff --git a/Documentation/devicetree/bindings/interrupt-controller/sophgo,sg2042-msi.yaml b/Documentation/devicetree/bindings/interrupt-controller/sophgo,sg2042-msi.yaml new file mode 100644 index 000000000000..e1ffd55fa7bf --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/sophgo,sg2042-msi.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/sophgo,sg2042-msi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sophgo SG2042 MSI Controller + +maintainers: + - Chen Wang <unicorn_wang@outlook.com> + +description: + This interrupt controller is in Sophgo SG2042 for transforming interrupts from + PCIe MSI to PLIC interrupts. + +allOf: + - $ref: /schemas/interrupt-controller/msi-controller.yaml# + +properties: + compatible: + const: sophgo,sg2042-msi + + reg: + items: + - description: clear register + - description: msi doorbell address + + reg-names: + items: + - const: clr + - const: doorbell + + msi-controller: true + + msi-ranges: + maxItems: 1 + + "#msi-cells": + const: 0 + +required: + - compatible + - reg + - reg-names + - msi-controller + - msi-ranges + - "#msi-cells" + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + msi-controller@30000000 { + compatible = "sophgo,sg2042-msi"; + reg = <0x30000000 0x4>, <0x30000008 0x4>; + reg-names = "clr", "doorbell"; + msi-controller; + #msi-cells = <0>; + msi-ranges = <&plic 64 IRQ_TYPE_LEVEL_HIGH 32>; + }; diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 032fdc27127b..7b9d5507d6cc 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -90,6 +90,7 @@ properties: - enum: - qcom,qcm2290-smmu-500 - qcom,qcs615-smmu-500 + - qcom,qcs8300-smmu-500 - qcom,sa8255p-smmu-500 - qcom,sa8775p-smmu-500 - qcom,sar2130p-smmu-500 @@ -397,6 +398,7 @@ allOf: compatible: contains: enum: + - qcom,qcs8300-smmu-500 - qcom,sa8775p-smmu-500 - qcom,sc7280-smmu-500 - qcom,sc8280xp-smmu-500 @@ -581,7 +583,6 @@ allOf: - cavium,smmu-v2 - marvell,ap806-smmu-500 - nvidia,smmu-500 - - qcom,qcs8300-smmu-500 - qcom,qdu1000-smmu-500 - qcom,sa8255p-smmu-500 - qcom,sc7180-smmu-500 diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml b/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml index 5ae9a628261f..3e5623edd207 100644 --- a/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.yaml @@ -22,6 +22,7 @@ properties: - enum: - qcom,msm8916-iommu - qcom,msm8917-iommu + - qcom,msm8937-iommu - qcom,msm8953-iommu - const: qcom,msm-iommu-v1 - items: 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/aspeed,video-engine.yaml b/Documentation/devicetree/bindings/media/aspeed,video-engine.yaml new file mode 100644 index 000000000000..682bba20778c --- /dev/null +++ b/Documentation/devicetree/bindings/media/aspeed,video-engine.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/aspeed,video-engine.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASPEED Video Engine + +maintainers: + - Eddie James <eajames@linux.ibm.com> + +description: + The Video Engine (VE) embedded in the ASPEED SOCs can be configured to + capture and compress video data from digital or analog sources. + +properties: + compatible: + enum: + - aspeed,ast2400-video-engine + - aspeed,ast2500-video-engine + - aspeed,ast2600-video-engine + + reg: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: vclk + - const: eclk + + resets: + maxItems: 1 + + interrupts: + maxItems: 1 + + memory-region: + maxItems: 1 + description: | + Phandle to the reserved memory nodes to be associated with the + VE. VE will acquires memory space for 3 purposes: + 1. JPEG header + 2. Compressed result + 3. Temporary transformed image data + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/ast2600-clock.h> + + video@1e700000 { + compatible = "aspeed,ast2600-video-engine"; + reg = <0x1e700000 0x1000>; + clocks = <&syscon ASPEED_CLK_GATE_VCLK>, + <&syscon ASPEED_CLK_GATE_ECLK>; + clock-names = "vclk", "eclk"; + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/media/aspeed-video.txt b/Documentation/devicetree/bindings/media/aspeed-video.txt deleted file mode 100644 index d2ca32512272..000000000000 --- a/Documentation/devicetree/bindings/media/aspeed-video.txt +++ /dev/null @@ -1,33 +0,0 @@ -* Device tree bindings for Aspeed Video Engine - -The Video Engine (VE) embedded in the Aspeed AST2400/2500/2600 SOCs can -capture and compress video data from digital or analog sources. - -Required properties: - - compatible: "aspeed,ast2400-video-engine" or - "aspeed,ast2500-video-engine" or - "aspeed,ast2600-video-engine" - - reg: contains the offset and length of the VE memory region - - clocks: clock specifiers for the syscon clocks associated with - the VE (ordering must match the clock-names property) - - clock-names: "vclk" and "eclk" - - resets: reset specifier for the syscon reset associated with - the VE - - interrupts: the interrupt associated with the VE on this platform - -Optional properties: - - memory-region: - phandle to a memory region to allocate from, as defined in - Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt - -Example: - -video-engine@1e700000 { - compatible = "aspeed,ast2500-video-engine"; - reg = <0x1e700000 0x20000>; - clocks = <&syscon ASPEED_CLK_GATE_VCLK>, <&syscon ASPEED_CLK_GATE_ECLK>; - clock-names = "vclk", "eclk"; - resets = <&syscon ASPEED_RESET_VIDEO>; - interrupts = <7>; - memory-region = <&video_engine_memory>; -}; diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml index 4371a0ef2761..9ee1483775f6 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml +++ b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml @@ -49,6 +49,10 @@ properties: Indicates that the output is a BT.656-4 compatible stream. type: boolean + interrupts: + items: + - description: The GPIO connected to the INTRQ pin. + port: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml b/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml index b68141264c0e..4d40e75b4e1e 100644 --- a/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml +++ b/Documentation/devicetree/bindings/media/i2c/st,st-mipid02.yaml @@ -71,7 +71,7 @@ properties: description: Any lane can be inverted or not. minItems: 1 - maxItems: 2 + maxItems: 3 required: - data-lanes 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/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml index 5865e6f0be89..bf8082d87ac0 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml @@ -4,52 +4,70 @@ $id: http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Mediatek Video Decode Accelerator With Multi Hardware +title: MediaTek Video Decode Accelerator With Multi Hardware maintainers: - Yunfei Dong <yunfei.dong@mediatek.com> description: | - Mediatek Video Decode is the video decode hardware present in Mediatek - SoCs which supports high resolution decoding functionalities. Required - parent and child device node. - - About the Decoder Hardware Block Diagram, please check below: - - +------------------------------------------------+-------------------------------------+ - | | | - | input -> lat soc HW -> lat HW -> lat buffer --|--> lat buffer -> core HW -> output | - | || || | || | - +------------||-------------||-------------------+---------------------||--------------+ - || lat || | core workqueue <parent> - -------------||-------------||-------------------|---------------------||--------------- - ||<------------||----------------HW index---------------->|| <child> - \/ \/ \/ - +-------------------------------------------------------------+ - | enable/disable | - | clk power irq iommu | - | (lat/lat soc/core0/core1) | - +-------------------------------------------------------------+ - - As above, there are parent and child devices, child mean each hardware. The child device - controls the information of each hardware independent which include clk/power/irq. - - There are two workqueues in parent device: lat workqueue and core workqueue. They are used - to lat and core hardware decoder. Lat workqueue need to get input bitstream and lat buffer, - then enable lat to decode, writing the result to lat buffer, dislabe hardware when lat decode - done. Core workqueue need to get lat buffer and output buffer, then enable core to decode, - writing the result to output buffer, disable hardware when core decode done. These two - hardwares will decode each frame cyclically. - - For the smi common may not the same for each hardware, can't combine all hardware in one node, - or leading to iommu fault when access dram data. - - Lat soc is a hardware which is related with some larb(local arbiter) ports. For mt8195 - platform, there are some ports like RDMA, UFO in lat soc larb, need to enable its power and - clock when lat start to work, don't have interrupt. - - mt8195: lat soc HW + lat HW + core HW - mt8192: lat HW + core HW + MediaTek Video Decode Accelerator is the video decoding hardware present in + MediaTek SoCs that supports high-resolution decoding functionalities. + It consists of parent and child nodes. + + The decoder hardware block diagram is shown below: + + +------------------------------------------------+------------------------------+ + | | | + | input -> LAT-SoC HW -> LAT HW -> LAT buffer --|--> Core HW -> output buffer | + | || || | || | + +--------------||-----------||-------------------+-------||---------------------+ + LAT Workqueue | Core Workqueue <parent> + ---------------||-----------||-------------------|-------||---------------------- + ||<----------||---------HW index--------->|| <child> + \/ \/ \/ + +-------------------------------------------------------------+ + | enable/disable | + | clk power irq iommu | + | (lat/lat-soc/core0/core1) | + +-------------------------------------------------------------+ + + The child nodes represent the individual hardware blocks within the decoding + pipeline, such as LAT-SoC, LAT and Core. + Each child node is responsible for managing the dedicated resources of the + hardware, such as clocks, power domains, interrupts and IOMMUs. + + The parent node is a central point of control for the child nodes. + It identifies the specific video decoding pipeline architecture used by the + SoC, manages the shared resources like workqueues and platform data, and + handles V4L2 API calls on behalf of the underlying hardware. + + The parent utilizes two workqueues to manage the decoding process. + 1. LAT Workqueue, for LAT-SoC and LAT decoder: + Its workers take input bitstream and LAT buffer, enable the hardware for + decoding tasks, write the result to LAT buffer, and disable the hardware + after the LAT decoding is done. + 2. Core Workqueue, for Core decoder: + Its workers take LAT buffer and output buffer, enable the hardware for + decoding tasks, write the result to output buffer, and disable the hardware + after the Core decoding is done. + + These hardware decode each frame cyclically. + + The hardware might be associated with different SMI-common devices. + To prevent IOMMU faults during DRAM access in such cases, each hardware with + the unique SMI-common device must be placed under a separate parent node in + the device tree. + + LAT-SoC refers to another hardware block that connected to additional LARB + (local arbiter) ports, such as RDMA and UFO. + It requires independent power and clock control to work with LAT decoder, and + it doesn't have a dedicated interrupt. + + The used video decoding pipeline architecture across various Mediatek SoC: + MT8195: LAT-SoC + LAT + Core + MT8192: LAT + Core + MT8188: LAT + Core + MT8186: Core properties: compatible: diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml index cfabf360f278..a4aacd3eb189 100644 --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml @@ -44,7 +44,8 @@ properties: maxItems: 1 iommus: - maxItems: 2 + minItems: 2 + maxItems: 32 description: | Points to the respective IOMMU block with master port as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml index 83c020a673d6..5b15f8977f67 100644 --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml @@ -39,7 +39,7 @@ properties: iommus: minItems: 2 - maxItems: 4 + maxItems: 32 description: | Points to the respective IOMMU block with master port as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml index e11141b812a0..ee35e3bc97ff 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7280-camss.yaml @@ -55,8 +55,8 @@ properties: - const: csiphy3_timer - const: csiphy4 - const: csiphy4_timer - - const: gcc_camera_ahb - - const: gcc_cam_hf_axi + - const: gcc_axi_hf + - const: gcc_axi_sf - const: icp_ahb - const: vfe0 - const: vfe0_axi @@ -310,8 +310,8 @@ examples: <&camcc CAM_CC_CSI3PHYTIMER_CLK>, <&camcc CAM_CC_CSIPHY4_CLK>, <&camcc CAM_CC_CSI4PHYTIMER_CLK>, - <&gcc GCC_CAMERA_AHB_CLK>, <&gcc GCC_CAMERA_HF_AXI_CLK>, + <&gcc GCC_CAMERA_SF_AXI_CLK>, <&camcc CAM_CC_ICP_AHB_CLK>, <&camcc CAM_CC_IFE_0_CLK>, <&camcc CAM_CC_IFE_0_AXI_CLK>, @@ -343,8 +343,8 @@ examples: "csiphy3_timer", "csiphy4", "csiphy4_timer", - "gcc_camera_ahb", - "gcc_cam_hf_axi", + "gcc_axi_hf", + "gcc_axi_sf", "icp_ahb", "vfe0", "vfe0_axi", diff --git a/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml new file mode 100644 index 000000000000..35c40fe22376 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml @@ -0,0 +1,318 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,sdm670-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SDM670 Camera Subsystem (CAMSS) + +maintainers: + - Richard Acayan <mailingradian@gmail.com> + +description: + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. + +properties: + compatible: + const: qcom,sdm670-camss + + reg: + maxItems: 9 + + reg-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: vfe0 + - const: vfe1 + - const: vfe_lite + + interrupts: + maxItems: 9 + + interrupt-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: vfe0 + - const: vfe1 + - const: vfe_lite + + clocks: + maxItems: 22 + + clock-names: + items: + - const: camnoc_axi + - const: cpas_ahb + - const: csi0 + - const: csi1 + - const: csi2 + - const: csiphy0 + - const: csiphy0_timer + - const: csiphy1 + - const: csiphy1_timer + - const: csiphy2 + - const: csiphy2_timer + - const: gcc_camera_ahb + - const: gcc_camera_axi + - const: soc_ahb + - const: vfe0 + - const: vfe0_axi + - const: vfe0_cphy_rx + - const: vfe1 + - const: vfe1_axi + - const: vfe1_cphy_rx + - const: vfe_lite + - const: vfe_lite_cphy_rx + + iommus: + maxItems: 4 + + power-domains: + items: + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. + - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller. + + power-domain-names: + items: + - const: ife0 + - const: ife1 + - const: top + + vdda-phy-supply: + description: + Phandle to a regulator supply to PHY core block. + + vdda-pll-supply: + description: + Phandle to 1.8V regulator supply to PHY refclk pll block. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + description: + CSI input ports. + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data from CSIPHY0. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data from CSIPHY1. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@2: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data from CSIPHY2. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - clocks + - clock-names + - iommus + - power-domains + - power-domain-names + - vdda-phy-supply + - vdda-pll-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,camcc-sdm845.h> + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + isp@acb3000 { + compatible = "qcom,sdm670-camss"; + + reg = <0 0x0acb3000 0 0x1000>, + <0 0x0acba000 0 0x1000>, + <0 0x0acc8000 0 0x1000>, + <0 0x0ac65000 0 0x1000>, + <0 0x0ac66000 0 0x1000>, + <0 0x0ac67000 0 0x1000>, + <0 0x0acaf000 0 0x4000>, + <0 0x0acb6000 0 0x4000>, + <0 0x0acc4000 0 0x4000>; + reg-names = "csid0", + "csid1", + "csid2", + "csiphy0", + "csiphy1", + "csiphy2", + "vfe0", + "vfe1", + "vfe_lite"; + + interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 467 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "csid0", + "csid1", + "csid2", + "csiphy0", + "csiphy1", + "csiphy2", + "vfe0", + "vfe1", + "vfe_lite"; + + clocks = <&camcc CAM_CC_CAMNOC_AXI_CLK>, + <&camcc CAM_CC_CPAS_AHB_CLK>, + <&camcc CAM_CC_IFE_0_CSID_CLK>, + <&camcc CAM_CC_IFE_1_CSID_CLK>, + <&camcc CAM_CC_IFE_LITE_CSID_CLK>, + <&camcc CAM_CC_CSIPHY0_CLK>, + <&camcc CAM_CC_CSI0PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY1_CLK>, + <&camcc CAM_CC_CSI1PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY2_CLK>, + <&camcc CAM_CC_CSI2PHYTIMER_CLK>, + <&gcc GCC_CAMERA_AHB_CLK>, + <&gcc GCC_CAMERA_AXI_CLK>, + <&camcc CAM_CC_SOC_AHB_CLK>, + <&camcc CAM_CC_IFE_0_CLK>, + <&camcc CAM_CC_IFE_0_AXI_CLK>, + <&camcc CAM_CC_IFE_0_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_1_CLK>, + <&camcc CAM_CC_IFE_1_AXI_CLK>, + <&camcc CAM_CC_IFE_1_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_LITE_CLK>, + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>; + clock-names = "camnoc_axi", + "cpas_ahb", + "csi0", + "csi1", + "csi2", + "csiphy0", + "csiphy0_timer", + "csiphy1", + "csiphy1_timer", + "csiphy2", + "csiphy2_timer", + "gcc_camera_ahb", + "gcc_camera_axi", + "soc_ahb", + "vfe0", + "vfe0_axi", + "vfe0_cphy_rx", + "vfe1", + "vfe1_axi", + "vfe1_cphy_rx", + "vfe_lite", + "vfe_lite_cphy_rx"; + + iommus = <&apps_smmu 0x808 0x0>, + <&apps_smmu 0x810 0x8>, + <&apps_smmu 0xc08 0x0>, + <&apps_smmu 0xc10 0x8>; + + power-domains = <&camcc IFE_0_GDSC>, + <&camcc IFE_1_GDSC>, + <&camcc TITAN_TOP_GDSC>; + power-domain-names = "ife0", + "ife1", + "top"; + + vdda-phy-supply = <&vreg_l1a_1p225>; + vdda-pll-supply = <&vreg_l8a_1p8>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + csiphy_ep0: endpoint { + clock-lanes = <7>; + data-lanes = <0 1 2 3>; + remote-endpoint = <&front_sensor_ep>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml new file mode 100644 index 000000000000..cd34f14916b4 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml @@ -0,0 +1,597 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,sm8550-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM8550 Camera Subsystem (CAMSS) + +maintainers: + - Depeng Shao <quic_depengs@quicinc.com> + +description: + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. + +properties: + compatible: + const: qcom,sm8550-camss + + reg: + maxItems: 19 + + reg-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid_lite0 + - const: csid_lite1 + - const: csid_wrapper + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy3 + - const: csiphy4 + - const: csiphy5 + - const: csiphy6 + - const: csiphy7 + - const: vfe0 + - const: vfe1 + - const: vfe2 + - const: vfe_lite0 + - const: vfe_lite1 + + clocks: + maxItems: 36 + + clock-names: + items: + - const: camnoc_axi + - const: cpas_ahb + - const: cpas_fast_ahb_clk + - const: cpas_ife_lite + - const: cpas_vfe0 + - const: cpas_vfe1 + - const: cpas_vfe2 + - const: csid + - const: csiphy0 + - const: csiphy0_timer + - const: csiphy1 + - const: csiphy1_timer + - const: csiphy2 + - const: csiphy2_timer + - const: csiphy3 + - const: csiphy3_timer + - const: csiphy4 + - const: csiphy4_timer + - const: csiphy5 + - const: csiphy5_timer + - const: csiphy6 + - const: csiphy6_timer + - const: csiphy7 + - const: csiphy7_timer + - const: csiphy_rx + - const: gcc_axi_hf + - const: vfe0 + - const: vfe0_fast_ahb + - const: vfe1 + - const: vfe1_fast_ahb + - const: vfe2 + - const: vfe2_fast_ahb + - const: vfe_lite + - const: vfe_lite_ahb + - const: vfe_lite_cphy_rx + - const: vfe_lite_csid + + interrupts: + maxItems: 18 + + interrupt-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid_lite0 + - const: csid_lite1 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy3 + - const: csiphy4 + - const: csiphy5 + - const: csiphy6 + - const: csiphy7 + - const: vfe0 + - const: vfe1 + - const: vfe2 + - const: vfe_lite0 + - const: vfe_lite1 + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: ahb + - const: hf_0_mnoc + + iommus: + maxItems: 1 + + power-domains: + items: + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE2 GDSC - Image Front End, Global Distributed Switch Controller. + - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller. + + power-domain-names: + items: + - const: ife0 + - const: ife1 + - const: ife2 + - const: top + + vdda-phy-supply: + description: + Phandle to a regulator supply to PHY core block. + + vdda-pll-supply: + description: + Phandle to 1.2V regulator supply to PHY refclk pll block. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + description: + CSI input ports. + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI0. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI1. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@2: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI2. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@3: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI3. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@4: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI4. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@5: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI5. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@6: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI6. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + + port@7: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data on CSI7. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - clock-lanes + - data-lanes + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - interrupts + - interrupt-names + - interconnects + - interconnect-names + - iommus + - power-domains + - power-domain-names + - vdda-phy-supply + - vdda-pll-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/clock/qcom,sm8550-camcc.h> + #include <dt-bindings/clock/qcom,sm8550-gcc.h> + #include <dt-bindings/interconnect/qcom,icc.h> + #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + isp@acb7000 { + compatible = "qcom,sm8550-camss"; + + reg = <0 0x0acb7000 0 0xd00>, + <0 0x0acb9000 0 0xd00>, + <0 0x0acbb000 0 0xd00>, + <0 0x0acca000 0 0xa00>, + <0 0x0acce000 0 0xa00>, + <0 0x0acb6000 0 0x1000>, + <0 0x0ace4000 0 0x2000>, + <0 0x0ace6000 0 0x2000>, + <0 0x0ace8000 0 0x2000>, + <0 0x0acea000 0 0x2000>, + <0 0x0acec000 0 0x2000>, + <0 0x0acee000 0 0x2000>, + <0 0x0acf0000 0 0x2000>, + <0 0x0acf2000 0 0x2000>, + <0 0x0ac62000 0 0xf000>, + <0 0x0ac71000 0 0xf000>, + <0 0x0ac80000 0 0xf000>, + <0 0x0accb000 0 0x1800>, + <0 0x0accf000 0 0x1800>; + reg-names = "csid0", + "csid1", + "csid2", + "csid_lite0", + "csid_lite1", + "csid_wrapper", + "csiphy0", + "csiphy1", + "csiphy2", + "csiphy3", + "csiphy4", + "csiphy5", + "csiphy6", + "csiphy7", + "vfe0", + "vfe1", + "vfe2", + "vfe_lite0", + "vfe_lite1"; + + clocks = <&camcc CAM_CC_CAMNOC_AXI_CLK>, + <&camcc CAM_CC_CPAS_AHB_CLK>, + <&camcc CAM_CC_CPAS_FAST_AHB_CLK>, + <&camcc CAM_CC_CPAS_IFE_LITE_CLK>, + <&camcc CAM_CC_CPAS_IFE_0_CLK>, + <&camcc CAM_CC_CPAS_IFE_1_CLK>, + <&camcc CAM_CC_CPAS_IFE_2_CLK>, + <&camcc CAM_CC_CSID_CLK>, + <&camcc CAM_CC_CSIPHY0_CLK>, + <&camcc CAM_CC_CSI0PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY1_CLK>, + <&camcc CAM_CC_CSI1PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY2_CLK>, + <&camcc CAM_CC_CSI2PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY3_CLK>, + <&camcc CAM_CC_CSI3PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY4_CLK>, + <&camcc CAM_CC_CSI4PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY5_CLK>, + <&camcc CAM_CC_CSI5PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY6_CLK>, + <&camcc CAM_CC_CSI6PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY7_CLK>, + <&camcc CAM_CC_CSI7PHYTIMER_CLK>, + <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>, + <&gcc GCC_CAMERA_HF_AXI_CLK>, + <&camcc CAM_CC_IFE_0_CLK>, + <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>, + <&camcc CAM_CC_IFE_1_CLK>, + <&camcc CAM_CC_IFE_1_FAST_AHB_CLK>, + <&camcc CAM_CC_IFE_2_CLK>, + <&camcc CAM_CC_IFE_2_FAST_AHB_CLK>, + <&camcc CAM_CC_IFE_LITE_CLK>, + <&camcc CAM_CC_IFE_LITE_AHB_CLK>, + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_LITE_CSID_CLK>; + clock-names = "camnoc_axi", + "cpas_ahb", + "cpas_fast_ahb_clk", + "cpas_ife_lite", + "cpas_vfe0", + "cpas_vfe1", + "cpas_vfe2", + "csid", + "csiphy0", + "csiphy0_timer", + "csiphy1", + "csiphy1_timer", + "csiphy2", + "csiphy2_timer", + "csiphy3", + "csiphy3_timer", + "csiphy4", + "csiphy4_timer", + "csiphy5", + "csiphy5_timer", + "csiphy6", + "csiphy6_timer", + "csiphy7", + "csiphy7_timer", + "csiphy_rx", + "gcc_axi_hf", + "vfe0", + "vfe0_fast_ahb", + "vfe1", + "vfe1_fast_ahb", + "vfe2", + "vfe2_fast_ahb", + "vfe_lite", + "vfe_lite_ahb", + "vfe_lite_cphy_rx", + "vfe_lite_csid"; + + interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 376 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 278 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 277 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 602 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 604 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 688 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "csid0", + "csid1", + "csid2", + "csid_lite0", + "csid_lite1", + "csiphy0", + "csiphy1", + "csiphy2", + "csiphy3", + "csiphy4", + "csiphy5", + "csiphy6", + "csiphy7", + "vfe0", + "vfe1", + "vfe2", + "vfe_lite0", + "vfe_lite1"; + + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY + &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>, + <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>; + interconnect-names = "ahb", + "hf_0_mnoc"; + + iommus = <&apps_smmu 0x800 0x20>; + + power-domains = <&camcc CAM_CC_IFE_0_GDSC>, + <&camcc CAM_CC_IFE_1_GDSC>, + <&camcc CAM_CC_IFE_2_GDSC>, + <&camcc CAM_CC_TITAN_TOP_GDSC>; + power-domain-names = "ife0", + "ife1", + "ife2", + "top"; + + vdda-phy-supply = <&vreg_l1e_0p88>; + vdda-pll-supply = <&vreg_l3e_1p2>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + csiphy_ep0: endpoint@0 { + reg = <0>; + clock-lanes = <7>; + data-lanes = <0 1>; + remote-endpoint = <&sensor_ep>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml new file mode 100644 index 000000000000..e424ea84c211 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml @@ -0,0 +1,158 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,sm8550-iris.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm iris video encode and decode accelerators + +maintainers: + - Vikash Garodia <quic_vgarodia@quicinc.com> + - Dikshita Agarwal <quic_dikshita@quicinc.com> + +description: + The iris video processing unit is a video encode and decode accelerator + present on Qualcomm platforms. + +allOf: + - $ref: qcom,venus-common.yaml# + +properties: + compatible: + const: qcom,sm8550-iris + + power-domains: + maxItems: 4 + + power-domain-names: + items: + - const: venus + - const: vcodec0 + - const: mxc + - const: mmcx + + clocks: + maxItems: 3 + + clock-names: + items: + - const: iface + - const: core + - const: vcodec0_core + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: cpu-cfg + - const: video-mem + + resets: + maxItems: 1 + + reset-names: + items: + - const: bus + + iommus: + maxItems: 2 + + dma-coherent: true + + operating-points-v2: true + + opp-table: + type: object + +required: + - compatible + - power-domain-names + - interconnects + - interconnect-names + - resets + - reset-names + - iommus + - dma-coherent + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/clock/qcom,sm8550-gcc.h> + #include <dt-bindings/clock/qcom,sm8450-videocc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interconnect/qcom,icc.h> + #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h> + #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/power/qcom,rpmhpd.h> + + video-codec@aa00000 { + compatible = "qcom,sm8550-iris"; + reg = <0x0aa00000 0xf0000>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + + power-domains = <&videocc VIDEO_CC_MVS0C_GDSC>, + <&videocc VIDEO_CC_MVS0_GDSC>, + <&rpmhpd RPMHPD_MXC>, + <&rpmhpd RPMHPD_MMCX>; + power-domain-names = "venus", "vcodec0", "mxc", "mmcx"; + + clocks = <&gcc GCC_VIDEO_AXI0_CLK>, + <&videocc VIDEO_CC_MVS0C_CLK>, + <&videocc VIDEO_CC_MVS0_CLK>; + clock-names = "iface", "core", "vcodec0_core"; + + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS + &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ALWAYS>, + <&mmss_noc MASTER_VIDEO QCOM_ICC_TAG_ALWAYS + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>; + interconnect-names = "cpu-cfg", "video-mem"; + + memory-region = <&video_mem>; + + resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>; + reset-names = "bus"; + + iommus = <&apps_smmu 0x1940 0x0000>, + <&apps_smmu 0x1947 0x0000>; + dma-coherent; + + operating-points-v2 = <&iris_opp_table>; + + iris_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-240000000 { + opp-hz = /bits/ 64 <240000000>; + required-opps = <&rpmhpd_opp_svs>, + <&rpmhpd_opp_low_svs>; + }; + + opp-338000000 { + opp-hz = /bits/ 64 <338000000>; + required-opps = <&rpmhpd_opp_svs>, + <&rpmhpd_opp_svs>; + }; + + opp-366000000 { + opp-hz = /bits/ 64 <366000000>; + required-opps = <&rpmhpd_opp_svs_l1>, + <&rpmhpd_opp_svs_l1>; + }; + + opp-444000000 { + opp-hz = /bits/ 64 <444000000>; + required-opps = <&rpmhpd_opp_turbo>, + <&rpmhpd_opp_turbo>; + }; + + opp-533333334 { + opp-hz = /bits/ 64 <533333334>; + required-opps = <&rpmhpd_opp_turbo_l1>, + <&rpmhpd_opp_turbo_l1>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml new file mode 100644 index 000000000000..510e94e9ca3a --- /dev/null +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Device Tree bindings for Synopsys DesignWare HDMI RX Controller + +--- +$id: http://devicetree.org/schemas/media/snps,dw-hdmi-rx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare HDMI RX Controller + +maintainers: + - Shreeya Patel <shreeya.patel@collabora.com> + +description: + Synopsys DesignWare HDMI Input Controller preset on RK3588 SoCs + allowing devices to receive and decode high-resolution video streams + from external sources like media players, cameras, laptops, etc. + +properties: + compatible: + items: + - const: rockchip,rk3588-hdmirx-ctrler + - const: snps,dw-hdmi-rx + + reg: + maxItems: 1 + + interrupts: + maxItems: 3 + + interrupt-names: + items: + - const: cec + - const: hdmi + - const: dma + + clocks: + maxItems: 7 + + clock-names: + items: + - const: aclk + - const: audio + - const: cr_para + - const: pclk + - const: ref + - const: hclk_s_hdmirx + - const: hclk_vo1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 4 + + reset-names: + items: + - const: axi + - const: apb + - const: ref + - const: biu + + memory-region: + maxItems: 1 + + hpd-gpios: + description: GPIO specifier for HPD. + maxItems: 1 + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of the syscon node for the general register file + containing HDMIRX PHY status bits. + + rockchip,vo1-grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of the syscon node for the Video Output GRF register + to enable EDID transfer through SDAIN and SCLIN. + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + - resets + - pinctrl-0 + - hpd-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rockchip,rk3588-cru.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/power/rk3588-power.h> + #include <dt-bindings/reset/rockchip,rk3588-cru.h> + hdmi_receiver: hdmi-receiver@fdee0000 { + compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx"; + reg = <0xfdee0000 0x6000>; + interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH 0>, + <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH 0>, + <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH 0>; + interrupt-names = "cec", "hdmi", "dma"; + clocks = <&cru ACLK_HDMIRX>, + <&cru CLK_HDMIRX_AUD>, + <&cru CLK_CR_PARA>, + <&cru PCLK_HDMIRX>, + <&cru CLK_HDMIRX_REF>, + <&cru PCLK_S_HDMIRX>, + <&cru HCLK_VO1>; + clock-names = "aclk", + "audio", + "cr_para", + "pclk", + "ref", + "hclk_s_hdmirx", + "hclk_vo1"; + power-domains = <&power RK3588_PD_VO1>; + resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>, + <&cru SRST_HDMIRX_REF>, <&cru SRST_A_HDMIRX_BIU>; + reset-names = "axi", "apb", "ref", "biu"; + memory-region = <&hdmi_receiver_cma>; + pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>; + pinctrl-names = "default"; + hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>; + }; diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-csi.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-csi.yaml index 33bedfe41924..e9fa3cfea5d2 100644 --- a/Documentation/devicetree/bindings/media/st,stm32mp25-csi.yaml +++ b/Documentation/devicetree/bindings/media/st,stm32mp25-csi.yaml @@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics STM32 CSI controller description: - The STM32 CSI controller allows connecting a CSI based - camera to the DCMIPP camera pipeline. + The STM32 CSI controller, coupled with a D-PHY allows connecting a CSI-2 + based camera to the DCMIPP camera pipeline. maintainers: - Alain Volmat <alain.volmat@foss.st.com> @@ -109,7 +109,6 @@ examples: endpoint { remote-endpoint = <&imx335_ep>; data-lanes = <1 2>; - bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>; }; }; 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/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt index 190230216de8..f00827c9b67f 100644 --- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt +++ b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt @@ -31,6 +31,10 @@ node must be named "audio-codec". Required properties for the audio-codec subnode: - #sound-dai-cells = <1>; +- interrupts : should contain jack detection interrupts, with headset + detect interrupt matching "hs" and microphone bias 2 + detect interrupt matching "mb2" in interrupt-names. +- interrupt-names : Contains "hs", "mb2" The audio-codec provides two DAIs. The first one is connected to the Stereo HiFi DAC and the second one is connected to the Voice DAC. @@ -52,6 +56,8 @@ Example: audio-codec { #sound-dai-cells = <1>; + interrupts-extended = <&cpcap 9 0>, <&cpcap 10 0>; + interrupt-names = "hs", "mb2"; /* HiFi */ port@0 { 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 4d67ff26d445..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 @@ -103,6 +106,7 @@ select: - rockchip,rk3288-qos - rockchip,rk3368-qos - rockchip,rk3399-qos + - rockchip,rk3528-qos - rockchip,rk3562-qos - rockchip,rk3568-qos - rockchip,rk3576-qos @@ -126,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 @@ -189,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 @@ -202,6 +209,7 @@ properties: - rockchip,rk3288-qos - rockchip,rk3368-qos - rockchip,rk3399-qos + - rockchip,rk3528-qos - rockchip,rk3562-qos - rockchip,rk3568-qos - rockchip,rk3576-qos 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/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt deleted file mode 100644 index b159dc2298b6..000000000000 --- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt +++ /dev/null @@ -1,50 +0,0 @@ -* Atmel SSC driver. - -Required properties: -- compatible: "atmel,at91rm9200-ssc" or "atmel,at91sam9g45-ssc" - - atmel,at91rm9200-ssc: support pdc transfer - - atmel,at91sam9g45-ssc: support dma transfer -- reg: Should contain SSC registers location and length -- interrupts: Should contain SSC interrupt -- clock-names: tuple listing input clock names. - Required elements: "pclk" -- clocks: phandles to input clocks. - - -Required properties for devices compatible with "atmel,at91sam9g45-ssc": -- dmas: DMA specifier, consisting of a phandle to DMA controller node, - the memory interface and SSC DMA channel ID (for tx and rx). - See Documentation/devicetree/bindings/dma/atmel,at91sam9g45-dma.yaml for details. -- dma-names: Must be "tx", "rx". - -Optional properties: - - atmel,clk-from-rk-pin: bool property. - - When SSC works in slave mode, according to the hardware design, the - clock can get from TK pin, and also can get from RK pin. So, add - this parameter to choose where the clock from. - - By default the clock is from TK pin, if the clock from RK pin, this - property is needed. - - #sound-dai-cells: Should contain <0>. - - This property makes the SSC into an automatically registered DAI. - -Examples: -- PDC transfer: -ssc0: ssc@fffbc000 { - compatible = "atmel,at91rm9200-ssc"; - reg = <0xfffbc000 0x4000>; - interrupts = <14 4 5>; - clocks = <&ssc0_clk>; - clock-names = "pclk"; -}; - -- DMA transfer: -ssc0: ssc@f0010000 { - compatible = "atmel,at91sam9g45-ssc"; - reg = <0xf0010000 0x4000>; - interrupts = <28 4 5>; - dmas = <&dma0 1 13>, - <&dma0 1 14>; - dma-names = "tx", "rx"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>; -}; diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml index 0ccd632d5620..9f3b1edacaa0 100644 --- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml @@ -30,38 +30,34 @@ properties: - const: allwinner,sun50i-a100-emmc - const: allwinner,sun50i-a100-mmc - items: - - const: allwinner,sun8i-a83t-mmc + - enum: + - allwinner,sun8i-a83t-mmc + - allwinner,suniv-f1c100s-mmc - const: allwinner,sun7i-a20-mmc - items: - - const: allwinner,sun8i-r40-emmc + - enum: + - allwinner,sun8i-r40-emmc + - allwinner,sun50i-h5-emmc + - allwinner,sun50i-h6-emmc - const: allwinner,sun50i-a64-emmc - items: - - const: allwinner,sun8i-r40-mmc + - enum: + - allwinner,sun8i-r40-mmc + - allwinner,sun50i-h5-mmc + - allwinner,sun50i-h6-mmc - const: allwinner,sun50i-a64-mmc - items: - - const: allwinner,sun50i-h5-emmc - - const: allwinner,sun50i-a64-emmc - - items: - - const: allwinner,sun50i-h5-mmc - - const: allwinner,sun50i-a64-mmc - - items: - - const: allwinner,sun50i-h6-emmc - - const: allwinner,sun50i-a64-emmc - - items: - - const: allwinner,sun50i-h6-mmc - - const: allwinner,sun50i-a64-mmc - - items: - - const: allwinner,sun20i-d1-emmc - - const: allwinner,sun50i-a100-emmc - - items: - - const: allwinner,sun50i-h616-emmc + - enum: + - allwinner,sun20i-d1-emmc + - allwinner,sun50i-h616-emmc + - allwinner,sun55i-a523-emmc - const: allwinner,sun50i-a100-emmc - items: - const: allwinner,sun50i-h616-mmc - const: allwinner,sun50i-a100-mmc - items: - - const: allwinner,suniv-f1c100s-mmc - - const: allwinner,sun7i-a20-mmc + - const: allwinner,sun55i-a523-mmc + - const: allwinner,sun20i-d1-mmc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.yaml b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.yaml index 022682a977c6..0d4d9ca6a8d9 100644 --- a/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.yaml +++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-mx-sdio.yaml @@ -60,6 +60,9 @@ patternProperties: bus-width: enum: [1, 4] + required: + - compatible + unevaluatedProperties: false required: diff --git a/Documentation/devicetree/bindings/mmc/atmel,hsmci.yaml b/Documentation/devicetree/bindings/mmc/atmel,hsmci.yaml new file mode 100644 index 000000000000..151b414b9d27 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/atmel,hsmci.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/atmel,hsmci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel High-Speed MultiMedia Card Interface (HSMCI) + +description: + The Atmel HSMCI controller provides an interface for MMC, SD, and SDIO memory + cards. + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Aubin Constans <aubin.constans@microchip.com> + +allOf: + - $ref: mmc-controller.yaml + +properties: + compatible: + const: atmel,hsmci + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + dmas: + maxItems: 1 + + dma-names: + const: rxtx + + clocks: + maxItems: 1 + + clock-names: + const: mci_clk + + "#address-cells": + const: 1 + description: Used for slot IDs. + + "#size-cells": + const: 0 + +patternProperties: + "slot@[0-2]$": + $ref: mmc-slot.yaml + description: A slot node representing an MMC, SD, or SDIO slot. + + properties: + reg: + enum: [0, 1] + + required: + - reg + - bus-width + + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - "#address-cells" + - "#size-cells" + +anyOf: + - required: + - slot@0 + - required: + - slot@1 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/at91.h> + mmc@f0008000 { + compatible = "atmel,hsmci"; + reg = <0xf0008000 0x600>; + interrupts = <12 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mci0_clk>; + clock-names = "mci_clk"; + #address-cells = <1>; + #size-cells = <0>; + + slot@0 { + reg = <0>; + bus-width = <4>; + cd-gpios = <&pioD 15 0>; + cd-inverted; + }; + + slot@1 { + reg = <1>; + bus-width = <4>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt b/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt deleted file mode 100644 index 07ad02075a93..000000000000 --- a/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt +++ /dev/null @@ -1,73 +0,0 @@ -* Atmel High Speed MultiMedia Card Interface - -This controller on atmel products provides an interface for MMC, SD and SDIO -types of memory cards. - -This file documents differences between the core properties described -by mmc.txt and the properties used by the atmel-mci driver. - -1) MCI node - -Required properties: -- compatible: should be "atmel,hsmci" -- #address-cells: should be one. The cell is the slot id. -- #size-cells: should be zero. -- at least one slot node -- clock-names: tuple listing input clock names. - Required elements: "mci_clk" -- clocks: phandles to input clocks. - -The node contains child nodes for each slot that the platform uses - -Example MCI node: - -mmc0: mmc@f0008000 { - compatible = "atmel,hsmci"; - reg = <0xf0008000 0x600>; - interrupts = <12 4>; - #address-cells = <1>; - #size-cells = <0>; - clock-names = "mci_clk"; - clocks = <&mci0_clk>; - - [ child node definitions...] -}; - -2) slot nodes - -Required properties: -- reg: should contain the slot id. -- bus-width: number of data lines connected to the controller - -Optional properties: -- cd-gpios: specify GPIOs for card detection -- cd-inverted: invert the value of external card detect gpio line -- wp-gpios: specify GPIOs for write protection - -Example slot node: - -slot@0 { - reg = <0>; - bus-width = <4>; - cd-gpios = <&pioD 15 0> - cd-inverted; -}; - -Example full MCI node: -mmc0: mmc@f0008000 { - compatible = "atmel,hsmci"; - reg = <0xf0008000 0x600>; - interrupts = <12 4>; - #address-cells = <1>; - #size-cells = <0>; - slot@0 { - reg = <0>; - bus-width = <4>; - cd-gpios = <&pioD 15 0> - cd-inverted; - }; - slot@1 { - reg = <1>; - bus-width = <4>; - }; -}; diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index b9b999570529..b98a84f93277 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -57,6 +57,7 @@ properties: - fsl,imx8mp-usdhc - fsl,imx8ulp-usdhc - fsl,imx93-usdhc + - fsl,imx94-usdhc - fsl,imx95-usdhc - const: fsl,imx8mm-usdhc - items: diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml index 9d7a1298c455..26e4f0f8dc1c 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml @@ -24,7 +24,7 @@ properties: $nodename: pattern: "^mmc(@.*)?$" -unevaluatedProperties: true +additionalProperties: true examples: - | diff --git a/Documentation/devicetree/bindings/mmc/mmc-slot.yaml b/Documentation/devicetree/bindings/mmc/mmc-slot.yaml index 1f0667828063..ca3d0114bfc6 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-slot.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-slot.yaml @@ -29,7 +29,6 @@ properties: maxItems: 1 required: - - compatible - reg unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml index af378b9ff3f4..773baa6c2656 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -68,6 +68,9 @@ properties: - renesas,sdhi-r9a08g045 # RZ/G3S - renesas,sdhi-r9a09g011 # RZ/V2M - const: renesas,rzg2l-sdhi + - items: + - const: renesas,sdhi-r9a09g047 # RZ/G3E + - const: renesas,sdhi-r9a09g057 # RZ/V2H(P) reg: maxItems: 1 @@ -211,6 +214,19 @@ allOf: sectioned off to be run by a separate second clock source to allow the main core clock to be turned off to save power. + - if: + properties: + compatible: + contains: + const: renesas,sdhi-r9a09g057 + then: + properties: + vqmmc-regulator: + type: object + description: VQMMC SD regulator + $ref: /schemas/regulator/regulator.yaml# + unevaluatedProperties: false + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml index 06df1269f247..bf273115235b 100644 --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml @@ -38,6 +38,8 @@ properties: - rockchip,rk3328-dw-mshc - rockchip,rk3368-dw-mshc - rockchip,rk3399-dw-mshc + - rockchip,rk3528-dw-mshc + - rockchip,rk3562-dw-mshc - rockchip,rk3568-dw-mshc - rockchip,rk3588-dw-mshc - rockchip,rv1108-dw-mshc diff --git a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml index ef2d1d7c92fc..e8bd49d46794 100644 --- a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml +++ b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml @@ -24,6 +24,8 @@ properties: - samsung,exynos5420-dw-mshc-smu - samsung,exynos7-dw-mshc - samsung,exynos7-dw-mshc-smu + - samsung,exynos7870-dw-mshc + - samsung,exynos7870-dw-mshc-smu - items: - enum: - samsung,exynos5433-dw-mshc-smu diff --git a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml index c3d5e0230af1..e6e604072d3c 100644 --- a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml @@ -14,7 +14,10 @@ properties: compatible: oneOf: - items: - - const: rockchip,rk3576-dwcmshc + - enum: + - rockchip,rk3528-dwcmshc + - rockchip,rk3562-dwcmshc + - rockchip,rk3576-dwcmshc - const: rockchip,rk3588-dwcmshc - enum: - rockchip,rk3568-dwcmshc diff --git a/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml index 15b63bbb82a2..b90d3b48c2f2 100644 --- a/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml @@ -42,7 +42,7 @@ required: - clock-names - interrupts -unevaluatedProperties: true +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/mtd/atmel,dataflash.yaml b/Documentation/devicetree/bindings/mtd/atmel,dataflash.yaml new file mode 100644 index 000000000000..8c72fa346e36 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/atmel,dataflash.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/atmel,dataflash.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel DataFlash + +maintainers: + - Nayab Sayed <nayabbasha.sayed@microchip.com> + +description: + The Atmel DataFlash is a low pin-count serial interface sequential access + Flash memory, compatible with SPI standard. The device tree may optionally + contain sub-nodes describing partitions of the address space. + +properties: + compatible: + oneOf: + - items: + - enum: + - atmel,at45db321d + - atmel,at45db041e + - atmel,at45db642d + - atmel,at45db021d + - const: atmel,at45 + - const: atmel,dataflash + - items: + - const: atmel,at45 + - const: atmel,dataflash + + reg: + maxItems: 1 + +required: + - compatible + - reg + +allOf: + - $ref: mtd.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + flash@1 { + compatible = "atmel,at45db321d", "atmel,at45", "atmel,dataflash"; + reg = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/atmel-dataflash.txt b/Documentation/devicetree/bindings/mtd/atmel-dataflash.txt deleted file mode 100644 index 1889a4db5b7c..000000000000 --- a/Documentation/devicetree/bindings/mtd/atmel-dataflash.txt +++ /dev/null @@ -1,17 +0,0 @@ -* Atmel Data Flash - -Required properties: -- compatible : "atmel,<model>", "atmel,<series>", "atmel,dataflash". - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Example: - -flash@1 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "atmel,at45db321d", "atmel,at45", "atmel,dataflash"; - spi-max-frequency = <25000000>; - reg = <1>; -}; diff --git a/Documentation/devicetree/bindings/mtd/cdns,hp-nfc.yaml b/Documentation/devicetree/bindings/mtd/cdns,hp-nfc.yaml index 0bed37a994c3..e1f4d7c35a88 100644 --- a/Documentation/devicetree/bindings/mtd/cdns,hp-nfc.yaml +++ b/Documentation/devicetree/bindings/mtd/cdns,hp-nfc.yaml @@ -33,6 +33,10 @@ properties: clocks: maxItems: 1 + clock-names: + items: + - const: nf_clk + dmas: maxItems: 1 @@ -51,6 +55,7 @@ required: - reg-names - interrupts - clocks + - clock-names unevaluatedProperties: false @@ -66,7 +71,8 @@ examples: #address-cells = <1>; #size-cells = <0>; interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&nf_clk>; + clocks = <&clk>; + clock-names = "nf_clk"; cdns,board-delay-ps = <4830>; nand@0 { diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml index f9eb1868ca1f..0badb2e978c7 100644 --- a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml @@ -29,7 +29,14 @@ properties: - enum: - fsl,imx8mm-gpmi-nand - fsl,imx8mn-gpmi-nand + - fsl,imx8mp-gpmi-nand + - fsl,imx8mq-gpmi-nand - const: fsl,imx7d-gpmi-nand + - items: + - enum: + - fsl,imx8dxl-gpmi-nand + - fsl,imx8qm-gpmi-nand + - const: fsl,imx8qxp-gpmi-nand reg: items: diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml index 18f6733408b4..1b375dee83b0 100644 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml @@ -122,6 +122,8 @@ properties: '#size-cells': const: 1 + ranges: true + big-endian: true little-endian: true @@ -143,8 +145,7 @@ then: required: - syscon -# FIXME: A parent bus may define timing properties -additionalProperties: true +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml index cf4198e43d7f..bd8f7b683953 100644 --- a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml @@ -14,8 +14,12 @@ allOf: properties: compatible: - const: fsl,imx27-nand - + oneOf: + - const: fsl,imx27-nand + - items: + - enum: + - fsl,imx31-nand + - const: fsl,imx27-nand reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml index c578637c5826..0fdd11265417 100644 --- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml @@ -63,6 +63,14 @@ properties: "#size-cells": const: 0 + airoha,npu: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the node used to configure the NPU module. + The Airoha Network Processor Unit (NPU) provides a configuration + interface to implement hardware flow offloading programming Packet + Processor Engine (PPE) flow table. + patternProperties: "^ethernet@[1-4]$": type: object @@ -132,6 +140,8 @@ examples: <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>; + airoha,npu = <&npu>; + #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml new file mode 100644 index 000000000000..76dd97c3fb40 --- /dev/null +++ b/Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/airoha,en7581-npu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Airoha Network Processor Unit for EN7581 SoC + +maintainers: + - Lorenzo Bianconi <lorenzo@kernel.org> + +description: + The Airoha Network Processor Unit (NPU) provides a configuration interface + to implement wired and wireless hardware flow offloading programming Packet + Processor Engine (PPE) flow table. + +properties: + compatible: + enum: + - airoha,en7581-npu + + reg: + maxItems: 1 + + interrupts: + items: + - description: mbox host irq line + - description: watchdog0 irq line + - description: watchdog1 irq line + - description: watchdog2 irq line + - description: watchdog3 irq line + - description: watchdog4 irq line + - description: watchdog5 irq line + - description: watchdog6 irq line + - description: watchdog7 irq line + - description: wlan irq line0 + - description: wlan irq line1 + - description: wlan irq line2 + - description: wlan irq line3 + - description: wlan irq line4 + - description: wlan irq line5 + + memory-region: + maxItems: 1 + description: + Memory used to store NPU firmware binary. + +required: + - compatible + - reg + - interrupts + - memory-region + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + soc { + #address-cells = <2>; + #size-cells = <2>; + + npu@1e900000 { + compatible = "airoha,en7581-npu"; + reg = <0 0x1e900000 0 0x313000>; + interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>; + memory-region = <&npu_binary>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index 798a4c19f18c..0cd78d71768c 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -152,6 +152,12 @@ properties: The second range is is for the Amlogic specific configuration (for example the PRG_ETHERNET register range on Meson8b and newer) + interrupts: + maxItems: 1 + + interrupt-names: + const: macirq + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml index 0a2d7baf5db3..d02e9dd847ef 100644 --- a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml +++ b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml @@ -17,6 +17,9 @@ description: maintainers: - Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> +allOf: + - $ref: bluetooth-controller.yaml# + properties: compatible: enum: @@ -40,10 +43,20 @@ properties: Host-To-Chip power save mechanism is driven by this GPIO connected to BT_WAKE_IN pin of the NXP chipset. + nxp,wakein-pin: + $ref: /schemas/types.yaml#/definitions/uint8 + description: + The GPIO number of the NXP chipset used for BT_WAKE_IN. + + nxp,wakeout-pin: + $ref: /schemas/types.yaml#/definitions/uint8 + description: + The GPIO number of the NXP chipset used for BT_WAKE_OUT. + required: - compatible -additionalProperties: false +unevaluatedProperties: false examples: - | @@ -54,5 +67,8 @@ examples: fw-init-baudrate = <3000000>; firmware-name = "uartuart8987_bt_v0.bin"; device-wakeup-gpios = <&gpio 11 GPIO_ACTIVE_HIGH>; + nxp,wakein-pin = /bits/ 8 <18>; + nxp,wakeout-pin = /bits/ 8 <19>; + local-bd-address = [66 55 44 33 22 11]; }; }; diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml index a72152f7e29b..6353a336f382 100644 --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml @@ -19,6 +19,7 @@ properties: - qcom,qca2066-bt - qcom,qca6174-bt - qcom,qca9377-bt + - qcom,wcn3950-bt - qcom,wcn3988-bt - qcom,wcn3990-bt - qcom,wcn3991-bt @@ -138,6 +139,7 @@ allOf: compatible: contains: enum: + - qcom,wcn3950-bt - qcom,wcn3988-bt - qcom,wcn3990-bt - qcom,wcn3991-bt diff --git a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml index 97dd1a7c5ed2..f81d56f7c12a 100644 --- a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml +++ b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml @@ -10,9 +10,6 @@ title: maintainers: - Marc Kleine-Budde <mkl@pengutronix.de> -allOf: - - $ref: can-controller.yaml# - properties: compatible: oneOf: @@ -28,6 +25,7 @@ properties: - fsl,vf610-flexcan - fsl,ls1021ar2-flexcan - fsl,lx2160ar1-flexcan + - nxp,s32g2-flexcan - items: - enum: - fsl,imx53-flexcan @@ -43,12 +41,25 @@ properties: - enum: - fsl,ls1028ar1-flexcan - const: fsl,lx2160ar1-flexcan + - items: + - enum: + - nxp,s32g3-flexcan + - const: nxp,s32g2-flexcan + - items: + - enum: + - fsl,imx94-flexcan + - const: fsl,imx95-flexcan reg: maxItems: 1 interrupts: - maxItems: 1 + minItems: 1 + maxItems: 4 + + interrupt-names: + minItems: 1 + maxItems: 4 clocks: maxItems: 2 @@ -70,6 +81,9 @@ properties: xceiver-supply: description: Regulator that powers the CAN transceiver. + phys: + maxItems: 1 + big-endian: $ref: /schemas/types.yaml#/definitions/flag description: | @@ -136,6 +150,41 @@ required: - reg - interrupts +allOf: + - $ref: can-controller.yaml# + - if: + properties: + compatible: + contains: + const: nxp,s32g2-flexcan + then: + properties: + interrupts: + items: + - description: Message Buffer interrupt for mailboxes 0-7 and Enhanced RX FIFO + - description: Device state change + - description: Bus Error detection + - description: Message Buffer interrupt for mailboxes 8-127 + interrupt-names: + items: + - const: mb-0 + - const: state + - const: berr + - const: mb-1 + required: + - interrupt-names + else: + properties: + interrupts: + maxItems: 1 + interrupt-names: false + - if: + required: + - xceiver-supply + then: + properties: + phys: false + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml index 2a98b26630cb..c155c9c6db39 100644 --- a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml +++ b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml @@ -40,7 +40,7 @@ properties: microchip,rx-int-gpios: description: - GPIO phandle of GPIO connected to to INT1 pin of the MCP251XFD, which + GPIO phandle of GPIO connected to INT1 pin of the MCP251XFD, which signals a pending RX interrupt. maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml index 7c5ac5d2e880..f6884f6e59e7 100644 --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml @@ -170,7 +170,7 @@ allOf: const: renesas,r8a779h0-canfd then: patternProperties: - "^channel[5-7]$": false + "^channel[4-7]$": false else: if: not: diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml b/Documentation/devicetree/bindings/net/cdns,macb.yaml index 3c30dd23cd4e..8d69846b2e09 100644 --- a/Documentation/devicetree/bindings/net/cdns,macb.yaml +++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml @@ -197,7 +197,6 @@ examples: }; - | - #include <dt-bindings/clock/xlnx-zynqmp-clk.h> #include <dt-bindings/power/xlnx-zynqmp-power.h> #include <dt-bindings/reset/xlnx-zynqmp-resets.h> #include <dt-bindings/phy/phy.h> @@ -210,9 +209,9 @@ examples: interrupt-parent = <&gic>; interrupts = <0 59 4>, <0 59 4>; reg = <0x0 0xff0c0000 0x0 0x1000>; - clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM1_REF>, - <&zynqmp_clk GEM1_TX>, <&zynqmp_clk GEM1_RX>, - <&zynqmp_clk GEM_TSU>; + clocks = <&zynqmp_clk 31>, <&zynqmp_clk 105>, + <&zynqmp_clk 51>, <&zynqmp_clk 50>, + <&zynqmp_clk 44>; clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk"; #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml index 4c78c546343f..d6c957a33b48 100644 --- a/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml +++ b/Documentation/devicetree/bindings/net/dsa/brcm,b53.yaml @@ -16,6 +16,7 @@ properties: compatible: oneOf: - const: brcm,bcm5325 + - const: brcm,bcm53101 - const: brcm,bcm53115 - const: brcm,bcm53125 - const: brcm,bcm53128 @@ -77,6 +78,7 @@ allOf: contains: enum: - brcm,bcm5325 + - brcm,bcm53101 - brcm,bcm53115 - brcm,bcm53125 - brcm,bcm53128 diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index 2c71454ae8e3..824bbe4333b7 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -232,6 +232,12 @@ properties: PHY's that have configurable TX internal delays. If this property is present then the PHY applies the TX delay. + tx-amplitude-100base-tx-percent: + description: + Transmit amplitude gain applied for 100BASE-TX. 100% matches 2V + peak-to-peak specified in ANSI X3.263. When omitted, the PHYs default + will be left as is. + leds: type: object diff --git a/Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml b/Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml index 9bcbacb6640d..55d6a8379025 100644 --- a/Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml +++ b/Documentation/devicetree/bindings/net/faraday,ftgmac100.yaml @@ -44,6 +44,9 @@ properties: phy-mode: enum: - rgmii + - rgmii-id + - rgmii-rxid + - rgmii-txid - rmii phy-handle: true diff --git a/Documentation/devicetree/bindings/net/fsl,gianfar-mdio.yaml b/Documentation/devicetree/bindings/net/fsl,gianfar-mdio.yaml new file mode 100644 index 000000000000..03c819bc701b --- /dev/null +++ b/Documentation/devicetree/bindings/net/fsl,gianfar-mdio.yaml @@ -0,0 +1,112 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/fsl,gianfar-mdio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Gianfar (TSEC) MDIO Device + +description: + This binding describes the MDIO is a bus to which the PHY devices are + connected. For each device that exists on this bus, a child node should be + created. + + Some TSECs are associated with an internal Ten-Bit Interface (TBI) PHY. This + PHY is accessed through the local MDIO bus. These buses are defined similarly + to the mdio buses, except they are compatible with "fsl,gianfar-tbi". The TBI + PHYs underneath them are similar to normal PHYs, but the reg property is + considered instructive, rather than descriptive. The reg property should be + chosen so it doesn't interfere with other PHYs on the bus. + +maintainers: + - J. Neuschäfer <j.ne@posteo.net> + +# This is needed to distinguish gianfar.yaml and gianfar-mdio.yaml, because +# both use compatible = "gianfar" (with different device_type values) +select: + oneOf: + - properties: + compatible: + contains: + const: gianfar + device_type: + const: mdio + required: + - device_type + + - properties: + compatible: + contains: + enum: + - fsl,gianfar-tbi + - fsl,gianfar-mdio + - fsl,etsec2-tbi + - fsl,etsec2-mdio + - fsl,ucc-mdio + - ucc_geth_phy + + required: + - compatible + +properties: + compatible: + enum: + - fsl,gianfar-tbi + - fsl,gianfar-mdio + - fsl,etsec2-tbi + - fsl,etsec2-mdio + - fsl,ucc-mdio + - gianfar + - ucc_geth_phy + + reg: + minItems: 1 + items: + - description: + Offset and length of the register set for the device + + - description: + Optionally, the offset and length of the TBIPA register (TBI PHY + address register). If TBIPA register is not specified, the driver + will attempt to infer it from the register set specified (your + mileage may vary). + + device_type: + const: mdio + +required: + - reg + - "#address-cells" + - "#size-cells" + +allOf: + - $ref: mdio.yaml# + + - if: + properties: + compatible: + contains: + const: ucc_geth_phy + then: + required: + - device_type + +unevaluatedProperties: false + +examples: + - | + soc { + #address-cells = <1>; + #size-cells = <1>; + + mdio@24520 { + reg = <0x24520 0x20>; + compatible = "fsl,gianfar-mdio"; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@0 { + reg = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/fsl,gianfar.yaml b/Documentation/devicetree/bindings/net/fsl,gianfar.yaml new file mode 100644 index 000000000000..f92f284aa05b --- /dev/null +++ b/Documentation/devicetree/bindings/net/fsl,gianfar.yaml @@ -0,0 +1,248 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/fsl,gianfar.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Three-Speed Ethernet Controller (TSEC), "Gianfar" + +maintainers: + - J. Neuschäfer <j.ne@posteo.net> + +# This is needed to distinguish gianfar.yaml and gianfar-mdio.yaml, because +# both use compatible = "gianfar" (with different device_type values) +select: + oneOf: + - properties: + compatible: + contains: + const: gianfar + device_type: + const: network + required: + - device_type + + - properties: + compatible: + const: fsl,etsec2 + + required: + - compatible + +properties: + compatible: + enum: + - gianfar + - fsl,etsec2 + + device_type: + const: network + + model: + enum: + - FEC + - TSEC + - eTSEC + + reg: + maxItems: 1 + + ranges: true + + "#address-cells": + enum: [ 1, 2 ] + + "#size-cells": + enum: [ 1, 2 ] + + cell-index: + $ref: /schemas/types.yaml#/definitions/uint32 + + interrupts: + minItems: 1 + items: + - description: Transmit interrupt or single combined interrupt + - description: Receive interrupt + - description: Error interrupt + + dma-coherent: true + + fsl,magic-packet: + type: boolean + description: + If present, indicates that the hardware supports waking up via magic packet. + + fsl,wake-on-filer: + type: boolean + description: + If present, indicates that the hardware supports waking up by Filer + General Purpose Interrupt (FGPI) asserted on the Rx int line. This is + an advanced power management capability allowing certain packet types + (user) defined by filer rules to wake up the system. + + bd-stash: + type: boolean + description: + If present, indicates that the hardware supports stashing buffer + descriptors in the L2. + + rx-stash-len: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Denotes the number of bytes of a received buffer to stash in the L2. + + rx-stash-idx: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Denotes the index of the first byte from the received buffer to stash in + the L2. + + fsl,num_rx_queues: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of receive queues + const: 8 + + fsl,num_tx_queues: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of transmit queues + const: 8 + + tbi-handle: + $ref: /schemas/types.yaml#/definitions/phandle + description: Reference (phandle) to the TBI node + +required: + - compatible + - model + +patternProperties: + "^mdio@[0-9a-f]+$": + $ref: /schemas/net/fsl,gianfar-mdio.yaml# + +allOf: + - $ref: ethernet-controller.yaml# + + # eTSEC2 controller nodes have "queue group" subnodes and don't need a "reg" + # property. + - if: + properties: + compatible: + contains: + const: fsl,etsec2 + then: + patternProperties: + "^queue-group@[0-9a-f]+$": + type: object + + properties: + reg: + maxItems: 1 + + interrupts: + items: + - description: Transmit interrupt + - description: Receive interrupt + - description: Error interrupt + + required: + - reg + - interrupts + + additionalProperties: false + else: + required: + - reg + + # TSEC and eTSEC devices require three interrupts + - if: + properties: + model: + contains: + enum: [ TSEC, eTSEC ] + then: + properties: + interrupts: + items: + - description: Transmit interrupt + - description: Receive interrupt + - description: Error interrupt + + + +unevaluatedProperties: false + +examples: + - | + ethernet@24000 { + device_type = "network"; + model = "TSEC"; + compatible = "gianfar"; + reg = <0x24000 0x1000>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <29 2>, <30 2>, <34 2>; + interrupt-parent = <&mpic>; + phy-handle = <&phy0>; + }; + + - | + #include <dt-bindings/interrupt-controller/irq.h> + + ethernet@24000 { + compatible = "gianfar"; + reg = <0x24000 0x1000>; + ranges = <0x0 0x24000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + cell-index = <0>; + device_type = "network"; + model = "eTSEC"; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <32 IRQ_TYPE_LEVEL_LOW>, + <33 IRQ_TYPE_LEVEL_LOW>, + <34 IRQ_TYPE_LEVEL_LOW>; + interrupt-parent = <&ipic>; + + mdio@520 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,gianfar-mdio"; + reg = <0x520 0x20>; + }; + }; + + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + bus { + #address-cells = <2>; + #size-cells = <2>; + + ethernet { + compatible = "fsl,etsec2"; + ranges; + device_type = "network"; + #address-cells = <2>; + #size-cells = <2>; + interrupt-parent = <&gic>; + model = "eTSEC"; + fsl,magic-packet; + dma-coherent; + + queue-group@2d10000 { + reg = <0x0 0x2d10000 0x0 0x1000>; + interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>; + }; + + queue-group@2d14000 { + reg = <0x0 0x2d14000 0x0 0x1000>; + interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt index 9c9668c1b6a2..b18bb4c997ea 100644 --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt @@ -1,88 +1,14 @@ * MDIO IO device -The MDIO is a bus to which the PHY devices are connected. For each -device that exists on this bus, a child node should be created. See -the definition of the PHY node in booting-without-of.txt for an example -of how to define a PHY. - -Required properties: - - reg : Offset and length of the register set for the device, and optionally - the offset and length of the TBIPA register (TBI PHY address - register). If TBIPA register is not specified, the driver will - attempt to infer it from the register set specified (your mileage may - vary). - - compatible : Should define the compatible device type for the - mdio. Currently supported strings/devices are: - - "fsl,gianfar-tbi" - - "fsl,gianfar-mdio" - - "fsl,etsec2-tbi" - - "fsl,etsec2-mdio" - - "fsl,ucc-mdio" - - "fsl,fman-mdio" - When device_type is "mdio", the following strings are also considered: - - "gianfar" - - "ucc_geth_phy" - -Example: - - mdio@24520 { - reg = <24520 20>; - compatible = "fsl,gianfar-mdio"; - - ethernet-phy@0 { - ...... - }; - }; +Refer to Documentation/devicetree/bindings/net/fsl,gianfar-mdio.yaml * TBI Internal MDIO bus -As of this writing, every tsec is associated with an internal TBI PHY. -This PHY is accessed through the local MDIO bus. These buses are defined -similarly to the mdio buses, except they are compatible with "fsl,gianfar-tbi". -The TBI PHYs underneath them are similar to normal PHYs, but the reg property -is considered instructive, rather than descriptive. The reg property should -be chosen so it doesn't interfere with other PHYs on the bus. +Refer to Documentation/devicetree/bindings/net/fsl,gianfar-mdio.yaml * Gianfar-compatible ethernet nodes -Properties: - - - device_type : Should be "network" - - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC" - - compatible : Should be "gianfar" - - reg : Offset and length of the register set for the device - - interrupts : For FEC devices, the first interrupt is the device's - interrupt. For TSEC and eTSEC devices, the first interrupt is - transmit, the second is receive, and the third is error. - - phy-handle : See ethernet.txt file in the same directory. - - fixed-link : See fixed-link.txt in the same directory. - - phy-connection-type : See ethernet.txt file in the same directory. - This property is only really needed if the connection is of type - "rgmii-id", as all other connection types are detected by hardware. - - fsl,magic-packet : If present, indicates that the hardware supports - waking up via magic packet. - - fsl,wake-on-filer : If present, indicates that the hardware supports - waking up by Filer General Purpose Interrupt (FGPI) asserted on the - Rx int line. This is an advanced power management capability allowing - certain packet types (user) defined by filer rules to wake up the system. - - bd-stash : If present, indicates that the hardware supports stashing - buffer descriptors in the L2. - - rx-stash-len : Denotes the number of bytes of a received buffer to stash - in the L2. - - rx-stash-idx : Denotes the index of the first byte from the received - buffer to stash in the L2. - -Example: - ethernet@24000 { - device_type = "network"; - model = "TSEC"; - compatible = "gianfar"; - reg = <0x24000 0x1000>; - local-mac-address = [ 00 E0 0C 00 73 00 ]; - interrupts = <29 2 30 2 34 2>; - interrupt-parent = <&mpic>; - phy-handle = <&phy0> - }; +Refer to Documentation/devicetree/bindings/net/fsl,gianfar.yaml * Gianfar PTP clock nodes diff --git a/Documentation/devicetree/bindings/net/ieee802154/ca8210.txt b/Documentation/devicetree/bindings/net/ieee802154/ca8210.txt index a1046e636fa1..f1bd07a0097d 100644 --- a/Documentation/devicetree/bindings/net/ieee802154/ca8210.txt +++ b/Documentation/devicetree/bindings/net/ieee802154/ca8210.txt @@ -20,7 +20,7 @@ Example: reg = <0>; spi-max-frequency = <3000000>; spi-cpol; - reset-gpio = <&gpio1 1 GPIO_ACTIVE_HIGH>; + reset-gpio = <&gpio1 1 GPIO_ACTIVE_LOW>; irq-gpio = <&gpio1 2 GPIO_ACTIVE_HIGH>; extclock-enable; extclock-freq = 16000000; diff --git a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml index 42a0bc94312c..62c1da36a2b5 100644 --- a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml +++ b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml @@ -41,6 +41,12 @@ properties: - const: ptp_ref - const: tx_clk + interrupts: + maxItems: 1 + + interrupt-names: + const: macirq + required: - compatible - clocks diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml index ed9d845f6008..3aab21b8e8de 100644 --- a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml @@ -64,6 +64,12 @@ properties: - const: rmii_internal - const: mac_cg + interrupts: + maxItems: 1 + + interrupt-names: + const: macirq + power-domains: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml index 87bc4416eadf..e5db346beca9 100644 --- a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml +++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml @@ -56,6 +56,14 @@ properties: - tx - mem + interrupts: + maxItems: 2 + + interrupt-names: + items: + - const: macirq + - const: eth_wake_irq + intf_mode: $ref: /schemas/types.yaml#/definitions/phandle-array items: diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index 1a46d80a66e8..b4a79912d473 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -210,70 +210,70 @@ additionalProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,rpmh.h> - #include <dt-bindings/interconnect/qcom,sdm845.h> - - smp2p-mpss { - compatible = "qcom,smp2p"; - interrupts = <GIC_SPI 576 IRQ_TYPE_EDGE_RISING>; - mboxes = <&apss_shared 6>; - qcom,smem = <94>, <432>; - qcom,local-pid = <0>; - qcom,remote-pid = <5>; - - ipa_smp2p_out: ipa-ap-to-modem { - qcom,entry-name = "ipa"; - #qcom,smem-state-cells = <1>; - }; - - ipa_smp2p_in: ipa-modem-to-ap { - qcom,entry-name = "ipa"; - interrupt-controller; - #interrupt-cells = <2>; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/interconnect/qcom,sdm845.h> + + smp2p-mpss { + compatible = "qcom,smp2p"; + interrupts = <GIC_SPI 576 IRQ_TYPE_EDGE_RISING>; + mboxes = <&apss_shared 6>; + qcom,smem = <94>, <432>; + qcom,local-pid = <0>; + qcom,remote-pid = <5>; + + ipa_smp2p_out: ipa-ap-to-modem { + qcom,entry-name = "ipa"; + #qcom,smem-state-cells = <1>; }; - ipa@1e40000 { - compatible = "qcom,sc7180-ipa"; - - qcom,gsi-loader = "self"; - memory-region = <&ipa_fw_mem>; - firmware-name = "qcom/sc7180-trogdor/modem/modem.mbn"; - - iommus = <&apps_smmu 0x440 0x0>, - <&apps_smmu 0x442 0x0>; - reg = <0x1e40000 0x7000>, - <0x1e47000 0x2000>, - <0x1e04000 0x2c000>; - reg-names = "ipa-reg", - "ipa-shared", - "gsi"; - - interrupts-extended = <&intc GIC_SPI 311 IRQ_TYPE_EDGE_RISING>, - <&intc GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH>, - <&ipa_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, - <&ipa_smp2p_in 1 IRQ_TYPE_EDGE_RISING>; - interrupt-names = "ipa", - "gsi", - "ipa-clock-query", - "ipa-setup-ready"; - - clocks = <&rpmhcc RPMH_IPA_CLK>; - clock-names = "core"; - - interconnects = - <&aggre2_noc MASTER_IPA 0 &mc_virt SLAVE_EBI1 0>, - <&aggre2_noc MASTER_IPA 0 &system_noc SLAVE_IMEM 0>, - <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_IPA_CFG 0>; - interconnect-names = "memory", - "imem", - "config"; - - qcom,qmp = <&aoss_qmp>; - - qcom,smem-states = <&ipa_smp2p_out 0>, - <&ipa_smp2p_out 1>; - qcom,smem-state-names = "ipa-clock-enabled-valid", - "ipa-clock-enabled"; + ipa_smp2p_in: ipa-modem-to-ap { + qcom,entry-name = "ipa"; + interrupt-controller; + #interrupt-cells = <2>; }; + }; + + ipa@1e40000 { + compatible = "qcom,sc7180-ipa"; + + qcom,gsi-loader = "self"; + memory-region = <&ipa_fw_mem>; + firmware-name = "qcom/sc7180-trogdor/modem/modem.mbn"; + + iommus = <&apps_smmu 0x440 0x0>, + <&apps_smmu 0x442 0x0>; + reg = <0x1e40000 0x7000>, + <0x1e47000 0x2000>, + <0x1e04000 0x2c000>; + reg-names = "ipa-reg", + "ipa-shared", + "gsi"; + + interrupts-extended = <&intc GIC_SPI 311 IRQ_TYPE_EDGE_RISING>, + <&intc GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH>, + <&ipa_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&ipa_smp2p_in 1 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "ipa", + "gsi", + "ipa-clock-query", + "ipa-setup-ready"; + + clocks = <&rpmhcc RPMH_IPA_CLK>; + clock-names = "core"; + + interconnects = + <&aggre2_noc MASTER_IPA 0 &mc_virt SLAVE_EBI1 0>, + <&aggre2_noc MASTER_IPA 0 &system_noc SLAVE_IMEM 0>, + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_IPA_CFG 0>; + interconnect-names = "memory", + "imem", + "config"; + + qcom,qmp = <&aoss_qmp>; + + qcom,smem-states = <&ipa_smp2p_out 0>, + <&ipa_smp2p_out 1>; + qcom,smem-state-names = "ipa-clock-enabled-valid", + "ipa-clock-enabled"; + }; diff --git a/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml b/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml new file mode 100644 index 000000000000..02e4e33e9969 --- /dev/null +++ b/Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/realtek,rtl9301-mdio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek RTL9300 MDIO Controller + +maintainers: + - Chris Packham <chris.packham@alliedtelesis.co.nz> + +properties: + compatible: + oneOf: + - items: + - enum: + - realtek,rtl9302b-mdio + - realtek,rtl9302c-mdio + - realtek,rtl9303-mdio + - const: realtek,rtl9301-mdio + - const: realtek,rtl9301-mdio + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + reg: + maxItems: 1 + +patternProperties: + '^mdio-bus@[0-3]$': + $ref: mdio.yaml# + + properties: + reg: + maxItems: 1 + + required: + - reg + + patternProperties: + '^ethernet-phy@[a-f0-9]+$': + type: object + $ref: ethernet-phy.yaml# + unevaluatedProperties: false + + unevaluatedProperties: false + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + mdio-controller@ca00 { + compatible = "realtek,rtl9301-mdio"; + reg = <0xca00 0x200>; + #address-cells = <1>; + #size-cells = <0>; + + mdio-bus@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c45"; + reg = <0>; + }; + }; + + mdio-bus@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c45"; + reg = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/realtek,rtl9301-switch.yaml b/Documentation/devicetree/bindings/net/realtek,rtl9301-switch.yaml index f053303ab1e6..80eabc170669 100644 --- a/Documentation/devicetree/bindings/mfd/realtek,rtl9301-switch.yaml +++ b/Documentation/devicetree/bindings/net/realtek,rtl9301-switch.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/mfd/realtek,rtl9301-switch.yaml# +$id: http://devicetree.org/schemas/net/realtek,rtl9301-switch.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Realtek Switch with Internal CPU @@ -14,6 +14,8 @@ description: number of different peripherals are accessed through a common register block, represented here as a syscon node. +$ref: ethernet-switch.yaml#/$defs/ethernet-ports + properties: compatible: items: @@ -28,12 +30,23 @@ properties: reg: maxItems: 1 + interrupts: + maxItems: 2 + + interrupt-names: + items: + - const: switch + - const: nic + '#address-cells': const: 1 '#size-cells': const: 1 + ethernet-ports: + type: object + patternProperties: 'reboot@[0-9a-f]+$': $ref: /schemas/power/reset/syscon-reboot.yaml# @@ -41,9 +54,14 @@ patternProperties: 'i2c@[0-9a-f]+$': $ref: /schemas/i2c/realtek,rtl9301-i2c.yaml# + 'mdio-controller@[0-9a-f]+$': + $ref: realtek,rtl9301-mdio.yaml# + required: - compatible - reg + - interrupts + - interrupt-names additionalProperties: false @@ -52,6 +70,9 @@ examples: ethernet-switch@1b000000 { compatible = "realtek,rtl9301-switch", "syscon", "simple-mfd"; reg = <0x1b000000 0x10000>; + interrupt-parent = <&intc>; + interrupts = <23>, <24>; + interrupt-names = "switch", "nic"; #address-cells = <1>; #size-cells = <1>; @@ -110,5 +131,45 @@ examples: }; }; }; + + mdio-controller@ca00 { + compatible = "realtek,rtl9301-mdio"; + reg = <0xca00 0x200>; + #address-cells = <1>; + #size-cells = <0>; + + mdio-bus@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + phy1: ethernet-phy@0 { + reg = <0>; + }; + }; + mdio-bus@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + phy2: ethernet-phy@0 { + reg = <0>; + }; + }; + }; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + phy-handle = <&phy1>; + }; + port@1 { + reg = <1>; + phy-handle = <&phy2>; + }; + }; }; diff --git a/Documentation/devicetree/bindings/net/rfkill-gpio.yaml b/Documentation/devicetree/bindings/net/rfkill-gpio.yaml index 9630c8466fac..4a706a41ab38 100644 --- a/Documentation/devicetree/bindings/net/rfkill-gpio.yaml +++ b/Documentation/devicetree/bindings/net/rfkill-gpio.yaml @@ -32,6 +32,10 @@ properties: shutdown-gpios: maxItems: 1 + default-blocked: + $ref: /schemas/types.yaml#/definitions/flag + description: configure rfkill state as blocked at boot + required: - compatible - radio-type @@ -48,4 +52,5 @@ examples: label = "rfkill-pcie-wlan"; radio-type = "wlan"; shutdown-gpios = <&gpio2 25 GPIO_ACTIVE_HIGH>; + default-blocked; }; diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml index f8a576611d6c..0ac7c4b47d6b 100644 --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml @@ -24,6 +24,7 @@ select: - rockchip,rk3366-gmac - rockchip,rk3368-gmac - rockchip,rk3399-gmac + - rockchip,rk3528-gmac - rockchip,rk3568-gmac - rockchip,rk3576-gmac - rockchip,rk3588-gmac @@ -32,9 +33,6 @@ select: required: - compatible -allOf: - - $ref: snps,dwmac.yaml# - properties: compatible: oneOf: @@ -52,14 +50,25 @@ properties: - rockchip,rv1108-gmac - items: - enum: + - rockchip,rk3528-gmac - rockchip,rk3568-gmac - rockchip,rk3576-gmac - rockchip,rk3588-gmac - rockchip,rv1126-gmac - const: snps,dwmac-4.20a + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + minItems: 1 + items: + - const: macirq + - const: eth_wake_irq + clocks: - minItems: 5 + minItems: 4 maxItems: 8 clock-names: @@ -114,6 +123,36 @@ required: - compatible - clocks - clock-names + - rockchip,grf + +allOf: + - $ref: snps,dwmac.yaml# + + - if: + properties: + compatible: + contains: + enum: + - rockchip,rk3576-gmac + - rockchip,rk3588-gmac + then: + required: + - rockchip,php-grf + else: + properties: + rockchip,php-grf: false + + - if: + not: + properties: + compatible: + contains: + enum: + - rockchip,rk3528-gmac + then: + properties: + clocks: + minItems: 5 unevaluatedProperties: false 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/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 91e75eb3f329..78b3030dc56d 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -32,6 +32,7 @@ select: - snps,dwmac-4.20a - snps,dwmac-5.10a - snps,dwmac-5.20 + - snps,dwmac-5.30a - snps,dwxgmac - snps,dwxgmac-2.10 @@ -98,10 +99,13 @@ properties: - snps,dwmac-4.20a - snps,dwmac-5.10a - snps,dwmac-5.20 + - snps,dwmac-5.30a - snps,dwxgmac - snps,dwxgmac-2.10 + - sophgo,sg2044-dwmac - starfive,jh7100-dwmac - starfive,jh7110-dwmac + - tesla,fsd-ethqos - thead,th1520-gmac reg: @@ -126,7 +130,7 @@ properties: clocks: minItems: 1 - maxItems: 8 + maxItems: 10 additionalItems: true items: - description: GMAC main clock @@ -138,7 +142,7 @@ properties: clock-names: minItems: 1 - maxItems: 8 + maxItems: 10 additionalItems: true contains: enum: @@ -490,6 +494,7 @@ properties: snps,en-tx-lpi-clockgating: $ref: /schemas/types.yaml#/definitions/flag + deprecated: true description: Enable gating of the MAC TX clock during TX low-power mode @@ -631,6 +636,7 @@ allOf: - snps,dwmac-4.20a - snps,dwmac-5.10a - snps,dwmac-5.20 + - snps,dwmac-5.30a - snps,dwxgmac - snps,dwxgmac-2.10 - st,spear600-gmac diff --git a/Documentation/devicetree/bindings/net/sophgo,sg2044-dwmac.yaml b/Documentation/devicetree/bindings/net/sophgo,sg2044-dwmac.yaml new file mode 100644 index 000000000000..4dd2dc9c678b --- /dev/null +++ b/Documentation/devicetree/bindings/net/sophgo,sg2044-dwmac.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/sophgo,sg2044-dwmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sophgo SG2044 DWMAC glue layer + +maintainers: + - Inochi Amaoto <inochiama@gmail.com> + +select: + properties: + compatible: + contains: + enum: + - sophgo,sg2044-dwmac + required: + - compatible + +properties: + compatible: + items: + - const: sophgo,sg2044-dwmac + - const: snps,dwmac-5.30a + + reg: + maxItems: 1 + + clocks: + items: + - description: GMAC main clock + - description: PTP clock + - description: TX clock + + clock-names: + items: + - const: stmmaceth + - const: ptp_ref + - const: tx + + dma-noncoherent: true + + interrupts: + maxItems: 1 + + interrupt-names: + maxItems: 1 + + resets: + maxItems: 1 + + reset-names: + const: stmmaceth + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - interrupt-names + - resets + - reset-names + +allOf: + - $ref: snps,dwmac.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + ethernet@30006000 { + compatible = "sophgo,sg2044-dwmac", "snps,dwmac-5.30a"; + reg = <0x30006000 0x4000>; + clocks = <&clk 151>, <&clk 152>, <&clk 154>; + clock-names = "stmmaceth", "ptp_ref", "tx"; + interrupt-parent = <&intc>; + interrupts = <296 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq"; + resets = <&rst 30>; + reset-names = "stmmaceth"; + snps,multicast-filter-bins = <0>; + snps,perfect-filter-entries = <1>; + snps,aal; + snps,tso; + snps,txpbl = <32>; + snps,rxpbl = <32>; + snps,mtl-rx-config = <&gmac0_mtl_rx_setup>; + snps,mtl-tx-config = <&gmac0_mtl_tx_setup>; + snps,axi-config = <&gmac0_stmmac_axi_setup>; + status = "disabled"; + + gmac0_mtl_rx_setup: rx-queues-config { + snps,rx-queues-to-use = <8>; + snps,rx-sched-wsp; + queue0 {}; + queue1 {}; + queue2 {}; + queue3 {}; + queue4 {}; + queue5 {}; + queue6 {}; + queue7 {}; + }; + + gmac0_mtl_tx_setup: tx-queues-config { + snps,tx-queues-to-use = <8>; + queue0 {}; + queue1 {}; + queue2 {}; + queue3 {}; + queue4 {}; + queue5 {}; + queue6 {}; + queue7 {}; + }; + + gmac0_stmmac_axi_setup: stmmac-axi-config { + snps,blen = <16 8 4 0 0 0 0>; + snps,wr_osr_lmt = <1>; + snps,rd_osr_lmt = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index 85cea9966a27..987254900d0d 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -54,6 +54,16 @@ properties: items: - const: stmmaceth + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + minItems: 1 + items: + - const: macirq + - const: eth_wake_irq + clocks: minItems: 3 items: diff --git a/Documentation/devicetree/bindings/net/tesla,fsd-ethqos.yaml b/Documentation/devicetree/bindings/net/tesla,fsd-ethqos.yaml new file mode 100644 index 000000000000..dd7481bb16e5 --- /dev/null +++ b/Documentation/devicetree/bindings/net/tesla,fsd-ethqos.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/tesla,fsd-ethqos.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: FSD Ethernet Quality of Service + +maintainers: + - Swathi K S <swathi.ks@samsung.com> + +description: + Tesla ethernet devices based on dwmmac support Gigabit ethernet. + +allOf: + - $ref: snps,dwmac.yaml# + +properties: + compatible: + const: tesla,fsd-ethqos + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-names: + items: + - const: macirq + + clocks: + minItems: 5 + items: + - description: PTP clock + - description: Master bus clock + - description: Slave bus clock + - description: MAC TX clock + - description: MAC RX clock + - description: Master2 bus clock + - description: Slave2 bus clock + - description: RX MUX clock + - description: PHY RX clock + - description: PERIC RGMII clock + + clock-names: + minItems: 5 + items: + - const: ptp_ref + - const: master_bus + - const: slave_bus + - const: tx + - const: rx + - const: master2_bus + - const: slave2_bus + - const: eqos_rxclk_mux + - const: eqos_phyrxclk + - const: dout_peric_rgmii_clk + + iommus: + maxItems: 1 + + phy-mode: + enum: + - rgmii + - rgmii-id + - rgmii-rxid + - rgmii-txid + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - iommus + - phy-mode + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/fsd-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + soc { + #address-cells = <2>; + #size-cells = <2>; + ethernet1: ethernet@14300000 { + compatible = "tesla,fsd-ethqos"; + reg = <0x0 0x14300000 0x0 0x10000>; + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "macirq"; + clocks = <&clock_peric PERIC_EQOS_TOP_IPCLKPORT_CLK_PTP_REF_I>, + <&clock_peric PERIC_EQOS_TOP_IPCLKPORT_ACLK_I>, + <&clock_peric PERIC_EQOS_TOP_IPCLKPORT_HCLK_I>, + <&clock_peric PERIC_EQOS_TOP_IPCLKPORT_RGMII_CLK_I>, + <&clock_peric PERIC_EQOS_TOP_IPCLKPORT_CLK_RX_I>, + <&clock_peric PERIC_BUS_D_PERIC_IPCLKPORT_EQOSCLK>, + <&clock_peric PERIC_BUS_P_PERIC_IPCLKPORT_EQOSCLK>, + <&clock_peric PERIC_EQOS_PHYRXCLK_MUX>, + <&clock_peric PERIC_EQOS_PHYRXCLK>, + <&clock_peric PERIC_DOUT_RGMII_CLK>; + clock-names = "ptp_ref", "master_bus", "slave_bus","tx", + "rx", "master2_bus", "slave2_bus", "eqos_rxclk_mux", + "eqos_phyrxclk","dout_peric_rgmii_clk"; + assigned-clocks = <&clock_peric PERIC_EQOS_PHYRXCLK_MUX>, + <&clock_peric PERIC_EQOS_PHYRXCLK>; + assigned-clock-parents = <&clock_peric PERIC_EQOS_PHYRXCLK>; + pinctrl-names = "default"; + pinctrl-0 = <ð1_tx_clk>, <ð1_tx_data>, <ð1_tx_ctrl>, + <ð1_phy_intr>, <ð1_rx_clk>, <ð1_rx_data>, + <ð1_rx_ctrl>, <ð1_mdio>; + iommus = <&smmu_peric 0x0 0x1>; + phy-mode = "rgmii-id"; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml index 052f636158b3..f0f32e18fc85 100644 --- a/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml @@ -42,6 +42,12 @@ properties: - const: stmmaceth - const: phy_ref_clk + interrupts: + maxItems: 1 + + interrupt-names: + const: macirq + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml index 070c4c9b8643..f2440d39b7eb 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml @@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Technologies ath10k wireless devices maintainers: - - Kalle Valo <kvalo@kernel.org> - Jeff Johnson <jjohnson@kernel.org> description: @@ -93,20 +92,41 @@ properties: ieee80211-freq-limit: true + qcom,calibration-data: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: + Calibration data + board-specific data as a byte array. The length + can vary between hardware versions. + qcom,ath10k-calibration-data: $ref: /schemas/types.yaml#/definitions/uint8-array + deprecated: true description: Calibration data + board-specific data as a byte array. The length can vary between hardware versions. + qcom,calibration-variant: + $ref: /schemas/types.yaml#/definitions/string + description: + Unique variant identifier of the calibration data in board-2.bin + for designs with colliding bus and device specific ids + qcom,ath10k-calibration-variant: $ref: /schemas/types.yaml#/definitions/string + deprecated: true description: Unique variant identifier of the calibration data in board-2.bin for designs with colliding bus and device specific ids + qcom,pre-calibration-data: + $ref: /schemas/types.yaml#/definitions/uint8-array + description: + Pre-calibration data as a byte array. The length can vary between + hardware versions. + qcom,ath10k-pre-calibration-data: $ref: /schemas/types.yaml#/definitions/uint8-array + deprecated: true description: Pre-calibration data as a byte array. The length can vary between hardware versions. diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml index a71fdf05bc1e..653b319fee88 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml @@ -8,7 +8,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Technologies ath11k wireless devices (PCIe) maintainers: - - Kalle Valo <kvalo@kernel.org> - Jeff Johnson <jjohnson@kernel.org> description: | @@ -23,8 +22,15 @@ properties: reg: maxItems: 1 + qcom,calibration-variant: + $ref: /schemas/types.yaml#/definitions/string + description: | + string to uniquely identify variant of the calibration data for designs + with colliding bus and device ids + qcom,ath11k-calibration-variant: $ref: /schemas/types.yaml#/definitions/string + deprecated: true description: | string to uniquely identify variant of the calibration data for designs with colliding bus and device ids @@ -128,7 +134,7 @@ examples: vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>; vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>; - qcom,ath11k-calibration-variant = "LE_X13S"; + qcom,calibration-variant = "LE_X13S"; }; }; }; diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml index ff5763dc66a8..c089677702cf 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml @@ -8,7 +8,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Technologies ath11k wireless devices maintainers: - - Kalle Valo <kvalo@kernel.org> - Jeff Johnson <jjohnson@kernel.org> description: | @@ -42,8 +41,15 @@ properties: * reg * reg-names + qcom,calibration-variant: + $ref: /schemas/types.yaml#/definitions/string + description: + string to uniquely identify variant of the calibration data in the + board-2.bin for designs with colliding bus and device specific ids + qcom,ath11k-calibration-variant: $ref: /schemas/types.yaml#/definitions/string + deprecated: true description: string to uniquely identify variant of the calibration data in the board-2.bin for designs with colliding bus and device specific ids diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml index cbfb559f6b69..589960144fe1 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k-wsi.yaml @@ -9,7 +9,6 @@ title: Qualcomm Technologies ath12k wireless devices (PCIe) with WSI interface maintainers: - Jeff Johnson <jjohnson@kernel.org> - - Kalle Valo <kvalo@kernel.org> description: | Qualcomm Technologies IEEE 802.11be PCIe devices with WSI interface. @@ -53,8 +52,15 @@ properties: reg: maxItems: 1 + qcom,calibration-variant: + $ref: /schemas/types.yaml#/definitions/string + description: + String to uniquely identify variant of the calibration data for designs + with colliding bus and device ids + qcom,ath12k-calibration-variant: $ref: /schemas/types.yaml#/definitions/string + deprecated: true description: String to uniquely identify variant of the calibration data for designs with colliding bus and device ids @@ -104,7 +110,7 @@ examples: compatible = "pci17cb,1109"; reg = <0x0 0x0 0x0 0x0 0x0>; - qcom,ath12k-calibration-variant = "RDP433_1"; + qcom,calibration-variant = "RDP433_1"; ports { #address-cells = <1>; @@ -140,7 +146,7 @@ examples: compatible = "pci17cb,1109"; reg = <0x0 0x0 0x0 0x0 0x0>; - qcom,ath12k-calibration-variant = "RDP433_2"; + qcom,calibration-variant = "RDP433_2"; qcom,wsi-controller; ports { @@ -177,7 +183,7 @@ examples: compatible = "pci17cb,1109"; reg = <0x0 0x0 0x0 0x0 0x0>; - qcom,ath12k-calibration-variant = "RDP433_3"; + qcom,calibration-variant = "RDP433_3"; ports { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml index 1b5884015b15..9e557cb838c7 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml @@ -9,7 +9,6 @@ title: Qualcomm Technologies ath12k wireless devices (PCIe) maintainers: - Jeff Johnson <quic_jjohnson@quicinc.com> - - Kalle Valo <kvalo@kernel.org> description: Qualcomm Technologies IEEE 802.11be PCIe devices. diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml index d37f544ab8aa..39c209249c9c 100644 --- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml +++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml @@ -36,6 +36,7 @@ properties: - qcom,qcs404-qfprom - qcom,qcs615-qfprom - qcom,qcs8300-qfprom + - qcom,sar2130p-qfprom - qcom,sc7180-qfprom - qcom,sc7280-qfprom - qcom,sc8280xp-qfprom 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/platform/huawei,gaokun-ec.yaml b/Documentation/devicetree/bindings/platform/huawei,gaokun-ec.yaml new file mode 100644 index 000000000000..4a03b0ee3149 --- /dev/null +++ b/Documentation/devicetree/bindings/platform/huawei,gaokun-ec.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/platform/huawei,gaokun-ec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Huawei Matebook E Go Embedded Controller + +maintainers: + - Pengyu Luo <mitltlatltl@gmail.com> + +description: + Different from other Qualcomm Snapdragon sc8180x and sc8280xp-based + machines, the Huawei Matebook E Go tablets use embedded controllers + while others use a system called PMIC GLink which handles battery, + UCSI, USB Type-C DP Alt Mode. In addition, Huawei's implementation + also handles additional features, such as charging thresholds, FN + lock, smart charging, tablet lid status, thermal sensors, and more. + +properties: + compatible: + enum: + - huawei,gaokun3-ec + + reg: + const: 0x38 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + interrupts: + maxItems: 1 + +patternProperties: + '^connector@[01]$': + $ref: /schemas/connector/usb-connector.yaml# + + properties: + reg: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + embedded-controller@38 { + compatible = "huawei,gaokun3-ec"; + reg = <0x38>; + + interrupts-extended = <&tlmm 107 IRQ_TYPE_LEVEL_LOW>; + + #address-cells = <1>; + #size-cells = <0>; + + connector@0 { + compatible = "usb-c-connector"; + reg = <0>; + power-role = "dual"; + data-role = "dual"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + ucsi0_ss_in: endpoint { + remote-endpoint = <&usb_0_qmpphy_out>; + }; + }; + + port@1 { + reg = <1>; + + ucsi0_sbu: endpoint { + remote-endpoint = <&usb0_sbu_mux>; + }; + }; + }; + }; + + connector@1 { + compatible = "usb-c-connector"; + reg = <1>; + power-role = "dual"; + data-role = "dual"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + ucsi1_ss_in: endpoint { + remote-endpoint = <&usb_1_qmpphy_out>; + }; + }; + + port@1 { + reg = <1>; + + ucsi1_sbu: endpoint { + remote-endpoint = <&usb1_sbu_mux>; + }; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml b/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml index 46e2647a5d72..f578be6a3bc8 100644 --- a/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml +++ b/Documentation/devicetree/bindings/power/allwinner,sun20i-d1-ppu.yaml @@ -17,6 +17,7 @@ properties: compatible: enum: - allwinner,sun20i-d1-ppu + - allwinner,sun8i-v853-ppu reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml index 59a6af735a21..6e9a670eaf56 100644 --- a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml +++ b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml @@ -31,6 +31,11 @@ properties: compatible: items: - enum: + - apple,s5l8960x-pmgr-pwrstate + - apple,t7000-pmgr-pwrstate + - apple,s8000-pmgr-pwrstate + - apple,t8010-pmgr-pwrstate + - apple,t8015-pmgr-pwrstate - apple,t8103-pmgr-pwrstate - apple,t8112-pmgr-pwrstate - apple,t6000-pmgr-pwrstate diff --git a/Documentation/devicetree/bindings/power/qcom,kpss-acc-v2.yaml b/Documentation/devicetree/bindings/power/qcom,kpss-acc-v2.yaml index 202a5d51ee88..3fa77fe14c87 100644 --- a/Documentation/devicetree/bindings/power/qcom,kpss-acc-v2.yaml +++ b/Documentation/devicetree/bindings/power/qcom,kpss-acc-v2.yaml @@ -18,7 +18,9 @@ description: properties: compatible: - const: qcom,kpss-acc-v2 + enum: + - qcom,kpss-acc-v2 + - qcom,msm8916-acc reg: items: 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/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml index 650dc0aae6f5..ebab98987e49 100644 --- a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml @@ -132,6 +132,9 @@ $defs: A number of phandles to clocks that need to be enabled while power domain switches state. + domain-supply: + description: domain regulator supply. + pm_qos: $ref: /schemas/types.yaml#/definitions/phandle-array items: 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/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/pwm/imx-tpm-pwm.yaml b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml index ac0a35bf8648..d5a9340ff920 100644 --- a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml @@ -23,8 +23,15 @@ properties: const: 3 compatible: - enum: - - fsl,imx7ulp-pwm + oneOf: + - enum: + - fsl,imx7ulp-pwm + - items: + - enum: + - fsl,imx93-pwm + - fsl,imx94-pwm + - fsl,imx95-pwm + - const: fsl,imx7ulp-pwm reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml b/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml new file mode 100644 index 000000000000..3b40e271fe8d --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/pwm-nexus-node.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PWM Nexus node properties + +description: > + Platforms can have a standardized connector/expansion slot that exposes PWMs + signals to expansion boards. + + A nexus node allows to remap a phandle list in a consumer node through a + connector node in a generic way. With this remapping, the consumer node needs + to know only about the nexus node. Resources behind the nexus node are + decoupled by the nexus node itself. + +maintainers: + - Herve Codina <herve.codina@bootlin.com> + +select: true + +properties: + '#pwm-cells': true + + pwm-map: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + + pwm-map-mask: + $ref: /schemas/types.yaml#/definitions/uint32-array + + pwm-map-pass-thru: + $ref: /schemas/types.yaml#/definitions/uint32-array + +dependentRequired: + pwm-map: ['#pwm-cells'] + pwm-map-mask: [ pwm-map ] + pwm-map-pass-thru: [ pwm-map ] + +additionalProperties: true + +examples: + - | + pwm1: pwm@100 { + reg = <0x100 0x10>; + #pwm-cells = <3>; + }; + + pwm2: pwm@200 { + reg = <0x200 0x10>; + #pwm-cells = <3>; + }; + + connector: connector { + #pwm-cells = <3>; + pwm-map = <0 0 0 &pwm1 1 0 0>, + <1 0 0 &pwm2 4 0 0>, + <2 0 0 &pwm1 3 0 0>; + pwm-map-mask = <0xffffffff 0x0 0x0>; + pwm-map-pass-thru = <0x0 0xffffffff 0xffffffff>; + }; + + device { + pwms = <&connector 1 57000 0>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml index 65bfb492b3a4..c8cdfb723336 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml @@ -30,6 +30,8 @@ properties: - enum: - rockchip,px30-pwm - rockchip,rk3308-pwm + - rockchip,rk3528-pwm + - rockchip,rk3562-pwm - rockchip,rk3568-pwm - rockchip,rk3588-pwm - rockchip,rv1126-pwm diff --git a/Documentation/devicetree/bindings/pwm/sophgo,sg2042-pwm.yaml b/Documentation/devicetree/bindings/pwm/sophgo,sg2042-pwm.yaml new file mode 100644 index 000000000000..bbb6326d47d7 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/sophgo,sg2042-pwm.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/sophgo,sg2042-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sophgo SG2042 PWM controller + +maintainers: + - Chen Wang <unicorn_wang@outlook.com> + +description: + This controller contains 4 channels which can generate PWM waveforms. + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + const: sophgo,sg2042-pwm + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: apb + + resets: + maxItems: 1 + + "#pwm-cells": + const: 3 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/reset/sophgo,sg2042-reset.h> + + pwm@7f006000 { + compatible = "sophgo,sg2042-pwm"; + reg = <0x7f006000 0x1000>; + #pwm-cells = <3>; + clocks = <&clock 67>; + clock-names = "apb"; + resets = <&rstgen RST_PWM>; + }; diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml index 68709a7dc43f..4ffe5c3faea0 100644 --- a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml @@ -17,6 +17,9 @@ description: | Datasheet is available at https://www.nxp.com/docs/en/data-sheet/PCA9450DS.pdf + Support PF9453, Datasheet is available at + https://www.nxp.com/docs/en/data-sheet/PF9453_SDS.pdf + # The valid names for PCA9450 regulator nodes are: # BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, # LDO1, LDO2, LDO3, LDO4, LDO5 @@ -30,6 +33,7 @@ properties: - nxp,pca9450c - nxp,pca9451a - nxp,pca9452 + - nxp,pf9453 reg: maxItems: 1 @@ -42,8 +46,30 @@ properties: description: | list of regulators provided by this controller + properties: + LDO5: + type: object + $ref: regulator.yaml# + description: + Properties for single LDO5 regulator. + + properties: + nxp,sd-vsel-fixed-low: + type: boolean + description: + Let the driver know that SD_VSEL is hardwired to low level and + there is no GPIO to get the actual value from. + + sd-vsel-gpios: + description: + GPIO that can be used to read the current status of the SD_VSEL + signal in order for the driver to know if LDO5CTRL_L or LDO5CTRL_H + is used by the hardware. + + unevaluatedProperties: false + patternProperties: - "^LDO[1-5]$": + "^LDO([1-4]|-SNVS)$": type: object $ref: regulator.yaml# description: @@ -78,11 +104,6 @@ properties: additionalProperties: false - sd-vsel-gpios: - description: GPIO that is used to switch LDO5 between being configured by - LDO5CTRL_L or LDO5CTRL_H register. Use this if the SD_VSEL signal is - connected to a host GPIO. - nxp,i2c-lt-enable: type: boolean description: @@ -101,6 +122,24 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + const: nxp,pf9453 + then: + properties: + regulators: + patternProperties: + "^LDO[3-4]$": false + "^BUCK[5-6]$": false + else: + properties: + regulators: + properties: + LDO-SNVS: false + examples: - | #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml index f2fd2df68a9e..b7241ce975b9 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml @@ -22,7 +22,7 @@ description: Each sub-node is identified using the node's name, with valid values listed for each of the pmics below. - For mp5496, s1, s2 + For mp5496, s1, s2, l2, l5 For pm2250, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22 diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml index 87accc6f13b8..022c1f197364 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml @@ -39,7 +39,7 @@ properties: interrupts: maxItems: 1 - + richtek,mtp-sel-high: type: boolean description: @@ -77,6 +77,7 @@ properties: properties: richtek,fixed-microvolt: + deprecated: true description: | This property can be used to set a fixed operating voltage that lies outside the range of the regulator's adjustable mode. 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/reset/atmel,at91sam9260-reset.yaml b/Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml index 98465d26949e..c3b33bbc7319 100644 --- a/Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml +++ b/Documentation/devicetree/bindings/reset/atmel,at91sam9260-reset.yaml @@ -26,6 +26,10 @@ properties: - items: - const: atmel,sama5d3-rstc - const: atmel,at91sam9g45-rstc + - items: + - enum: + - microchip,sam9x7-rstc + - const: microchip,sam9x60-rstc reg: minItems: 1 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/riscv/spacemit.yaml b/Documentation/devicetree/bindings/riscv/spacemit.yaml index 52e55077af1a..077b94f10dca 100644 --- a/Documentation/devicetree/bindings/riscv/spacemit.yaml +++ b/Documentation/devicetree/bindings/riscv/spacemit.yaml @@ -21,6 +21,7 @@ properties: - items: - enum: - bananapi,bpi-f3 + - milkv,jupiter - const: spacemit,k1 additionalProperties: true 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/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index 7b031ef09669..54cd585f19e3 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -54,6 +54,10 @@ properties: dma-coherent: true + firmware-name: + maxItems: 1 + description: Specify the name of the QUP firmware to load. + required: - compatible - reg @@ -135,6 +139,7 @@ examples: #address-cells = <2>; #size-cells = <2>; ranges; + firmware-name = "qcom/sa8775p/qupv3fw.elf"; i2c0: i2c@a94000 { compatible = "qcom,geni-i2c"; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml index 2d3fe0b54243..4c9e78f29523 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml @@ -38,6 +38,7 @@ properties: - items: - enum: - qcom,sm8650-pmic-glink + - qcom,sm8750-pmic-glink - qcom,x1e80100-pmic-glink - const: qcom,sm8550-pmic-glink - const: qcom,pmic-glink diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml index ebbf0c9109ce..e0f7503a9f35 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,r9a09g057-sys.yaml @@ -22,7 +22,10 @@ description: | properties: compatible: - const: renesas,r9a09g057-sys + items: + - enum: + - renesas,r9a09g047-sys # RZ/G3E + - renesas,r9a09g057-sys # RZ/V2H reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml index 225c0f07ae94..51a4c48eea6d 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml @@ -493,6 +493,13 @@ properties: - renesas,r9a07g044l2 # Dual Cortex-A55 RZ/G2L - const: renesas,r9a07g044 + - items: + - enum: + # MYIR Remi Pi SBC (MYB-YG2LX-REMI) + - myir,remi-pi + - const: renesas,r9a07g044l2 + - const: renesas,r9a07g044 + - description: RZ/V2L (R9A07G054) items: - enum: @@ -552,6 +559,15 @@ properties: - renesas,r9a09g057h41 # RZ/V2H - renesas,r9a09g057h42 # RZ/V2H with Mali-G31 support - renesas,r9a09g057h44 # RZ/V2HP with Mali-G31 + Mali-C55 support + - renesas,r9a09g057h45 # RZ/V2H with cryptographic extension support + - renesas,r9a09g057h46 # RZ/V2H with Mali-G31 + cryptographic extension support + - renesas,r9a09g057h48 # RZ/V2HP with Mali-G31 + Mali-C55 + cryptographic extension support + - const: renesas,r9a09g057 + + - description: Yuridenki-Shokai RZ/V2H Kakip + items: + - const: yuridenki,kakip + - const: renesas,r9a09g057h48 - const: renesas,r9a09g057 additionalProperties: true diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index 61f38b68a4a3..2f61c1b95fea 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -15,6 +15,9 @@ properties: - items: - enum: - rockchip,rk3288-sgrf + - rockchip,rk3528-ioc-grf + - rockchip,rk3528-vo-grf + - rockchip,rk3528-vpu-grf - rockchip,rk3566-pipe-grf - rockchip,rk3568-pcie3-phy-grf - rockchip,rk3568-pipe-grf diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml index 8e6d051d8c97..204da6fe458d 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml @@ -52,6 +52,8 @@ properties: - const: syscon - items: - enum: + - samsung,exynos2200-pmu + - samsung,exynos7870-pmu - samsung,exynos7885-pmu - samsung,exynos8895-pmu - samsung,exynos9810-pmu diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml index 5b046932fbc3..cb22637091e8 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml @@ -11,11 +11,21 @@ maintainers: - Krzysztof Kozlowski <krzk@kernel.org> description: | - USI IP-core provides selectable serial protocol (UART, SPI or High-Speed I2C). - USI shares almost all internal circuits within each protocol, so only one - protocol can be chosen at a time. USI is modeled as a node with zero or more - child nodes, each representing a serial sub-node device. The mode setting - selects which particular function will be used. + The USI IP-core provides configurable support for serial protocols, enabling + different serial communication modes depending on the version. + + In USIv1, configurations are available to enable either one or two protocols + simultaneously in select combinations - High-Speed I2C0, High-Speed + I2C1, SPI, UART, High-Speed I2C0 and I2C1 or both High-Speed + I2C1 and UART. + + In USIv2, only one protocol can be active at a time, either UART, SPI, or + High-Speed I2C. + + The USI core shares internal circuits across protocols, meaning only the + selected configuration is active at any given time. USI is modeled as a node + with zero or more child nodes, each representing a serial sub-node device. The + mode setting selects which particular function will be used. properties: $nodename: @@ -31,6 +41,7 @@ properties: - const: samsung,exynos850-usi - enum: - samsung,exynos850-usi + - samsung,exynos8895-usi reg: maxItems: 1 @@ -64,7 +75,7 @@ properties: samsung,mode: $ref: /schemas/types.yaml#/definitions/uint32 - enum: [0, 1, 2, 3] + enum: [0, 1, 2, 3, 4, 5, 6] description: Selects USI function (which serial protocol to use). Refer to <include/dt-bindings/soc/samsung,exynos-usi.h> for valid USI mode values. @@ -101,37 +112,59 @@ required: - samsung,sysreg - samsung,mode -if: - properties: - compatible: - contains: - enum: - - samsung,exynos850-usi +allOf: + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos850-usi + + then: + properties: + reg: + maxItems: 1 + + clocks: + items: + - description: Bus (APB) clock + - description: Operating clock for UART/SPI/I2C protocol -then: - properties: - reg: - maxItems: 1 + clock-names: + maxItems: 2 - clocks: - items: - - description: Bus (APB) clock - - description: Operating clock for UART/SPI/I2C protocol + samsung,mode: + enum: [0, 1, 2, 3] - clock-names: - maxItems: 2 + required: + - reg + - clocks + - clock-names - required: - - reg - - clocks - - clock-names + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos8895-usi -else: - properties: - reg: false - clocks: false - clock-names: false - samsung,clkreq-on: false + then: + properties: + reg: false + + clocks: + items: + - description: Bus (APB) clock + - description: Operating clock for UART/SPI protocol + + clock-names: + maxItems: 2 + + samsung,clkreq-on: false + + required: + - clocks + - clock-names additionalProperties: false @@ -144,7 +177,7 @@ examples: compatible = "samsung,exynos850-usi"; reg = <0x138200c0 0x20>; samsung,sysreg = <&sysreg_peri 0x1010>; - samsung,mode = <USI_V2_UART>; + samsung,mode = <USI_MODE_UART>; samsung,clkreq-on; /* needed for UART mode */ #address-cells = <1>; #size-cells = <1>; @@ -158,7 +191,6 @@ examples: interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cmu_peri 32>, <&cmu_peri 31>; clock-names = "uart", "clk_uart_baud0"; - status = "disabled"; }; hsi2c_0: i2c@13820000 { diff --git a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml index a75aef240629..d27ed6c9d61e 100644 --- a/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml @@ -18,6 +18,11 @@ properties: - google,gs101-hsi2-sysreg - google,gs101-peric0-sysreg - google,gs101-peric1-sysreg + - samsung,exynos2200-cmgp-sysreg + - samsung,exynos2200-peric0-sysreg + - samsung,exynos2200-peric1-sysreg + - samsung,exynos2200-peric2-sysreg + - samsung,exynos2200-ufs-sysreg - samsung,exynos3-sysreg - samsung,exynos4-sysreg - samsung,exynos5-sysreg diff --git a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml index 131aba5ed9f4..fb5c39c79d28 100644 --- a/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml +++ b/Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml @@ -9,8 +9,8 @@ title: Xilinx Zynq Platforms maintainers: - Michal Simek <michal.simek@amd.com> -description: | - Xilinx boards with Zynq-7000 SOC or Zynq UltraScale+ MPSoC +description: + AMD/Xilinx boards with ARM 32/64bits cores properties: $nodename: @@ -187,6 +187,13 @@ properties: - const: qemu,mbv - const: amd,mbv + - description: Xilinx Versal NET VN-X revA platform + items: + enum: + - xlnx,versal-net-vnx-revA + - xlnx,versal-net-vnx + - xlnx,versal-net + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml index ccae64ce3071..b4eca702febc 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-codec.yaml @@ -102,6 +102,10 @@ properties: maxItems: 1 description: GPIO to enable the external amplifier + hp-det-gpios: + maxItems: 1 + description: GPIO for headphone/line-out detection + required: - "#sound-dai-cells" - compatible @@ -251,8 +255,10 @@ allOf: allwinner,audio-routing: items: enum: + - Headphone - LINEOUT - Line Out + - Speaker dmas: items: diff --git a/Documentation/devicetree/bindings/sound/atmel,at91-ssc.yaml b/Documentation/devicetree/bindings/sound/atmel,at91-ssc.yaml new file mode 100644 index 000000000000..a05e61431824 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/atmel,at91-ssc.yaml @@ -0,0 +1,104 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/atmel,at91-ssc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Serial Synchronous Serial (SSC) + +maintainers: + - Andrei Simion <andrei.simion@microchip.com> + +description: + The Atmel Synchronous Serial Controller (SSC) provides a versatile + synchronous communication link for audio and telecom applications, + supporting protocols like I2S, Short Frame Sync, and Long Frame Sync. + +properties: + compatible: + enum: + - atmel,at91rm9200-ssc + - atmel,at91sam9g45-ssc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: pclk + + dmas: + items: + - description: TX DMA Channel + - description: RX DMA Channel + + dma-names: + items: + - const: tx + - const: rx + + atmel,clk-from-rk-pin: + description: + Specify the clock source for the SSC (Synchronous Serial Controller) + when operating in slave mode. By default, the clock is sourced from + the TK pin. + type: boolean + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +allOf: + - $ref: dai-common.yaml# + - if: + properties: + compatible: + contains: + enum: + - atmel,at91sam9g45-ssc + then: + required: + - dmas + - dma-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/dma/at91.h> + #include <dt-bindings/interrupt-controller/irq.h> + + ssc@100000 { + compatible = "atmel,at91sam9g45-ssc"; + reg = <0x100000 0x4000>; + interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>; + dmas = <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) | + AT91_XDMAC_DT_PERID(38))>, + <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) | + AT91_XDMAC_DT_PERID(39))>; + dma-names = "tx", "rx"; + clocks = <&pmc PMC_TYPE_PERIPHERAL 28>; + clock-names = "pclk"; + #sound-dai-cells = <0>; + }; + + ssc@c00000 { + compatible = "atmel,at91rm9200-ssc"; + reg = <0xc00000 0x4000>; + interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 14>; + clock-names = "pclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/atmel,at91sam9g20ek-wm8731.yaml b/Documentation/devicetree/bindings/sound/atmel,at91sam9g20ek-wm8731.yaml new file mode 100644 index 000000000000..627da2d890b2 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/atmel,at91sam9g20ek-wm8731.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/atmel,at91sam9g20ek-wm8731.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel at91sam9g20ek wm8731 audio complex + +maintainers: + - Balakrishnan Sambath <balakrishnan.s@microchip.com> + +description: + The audio complex configuration for Atmel at91sam9g20ek with WM8731 audio codec. + +properties: + compatible: + const: atmel,at91sam9g20ek-wm8731-audio + + atmel,model: + $ref: /schemas/types.yaml#/definitions/string + description: The user-visible name of this sound complex. + + atmel,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: A list of the connections between audio components. + minItems: 2 + maxItems: 4 + items: + enum: + # Board Connectors + - Ext Spk + - Int Mic + + # CODEC Pins + - LOUT + - ROUT + - LHPOUT + - RHPOUT + - LLINEIN + - RLINEIN + - MICIN + + atmel,ssc-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of the SSC controller. + + atmel,audio-codec: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of WM8731 audio codec. + +required: + - compatible + - atmel,model + - atmel,audio-routing + - atmel,ssc-controller + - atmel,audio-codec + +additionalProperties: false + +examples: + - | + sound { + compatible = "atmel,at91sam9g20ek-wm8731-audio"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pck0_as_mck>; + atmel,model = "wm8731 @ AT91SAMG20EK"; + atmel,audio-routing = + "Ext Spk", "LHPOUT", + "Int Mic", "MICIN"; + atmel,ssc-controller = <&ssc0>; + atmel,audio-codec = <&wm8731>; + }; diff --git a/Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt b/Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt deleted file mode 100644 index 9c5a9947b64d..000000000000 --- a/Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt +++ /dev/null @@ -1,26 +0,0 @@ -* Atmel at91sam9g20ek wm8731 audio complex - -Required properties: - - compatible: "atmel,at91sam9g20ek-wm8731-audio" - - atmel,model: The user-visible name of this sound complex. - - atmel,audio-routing: A list of the connections between audio components. - - atmel,ssc-controller: The phandle of the SSC controller - - atmel,audio-codec: The phandle of the WM8731 audio codec -Optional properties: - - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt - -Example: -sound { - compatible = "atmel,at91sam9g20ek-wm8731-audio"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_pck0_as_mck>; - - atmel,model = "wm8731 @ AT91SAMG20EK"; - - atmel,audio-routing = - "Ext Spk", "LHPOUT", - "Int MIC", "MICIN"; - - atmel,ssc-controller = <&ssc0>; - atmel,audio-codec = <&wm8731>; -}; diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml b/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml index f943f90d8b15..94588353f852 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml +++ b/Documentation/devicetree/bindings/sound/audio-graph-card2.yaml @@ -37,6 +37,10 @@ properties: codec2codec: type: object description: Codec to Codec node + hp-det-gpios: + $ref: audio-graph.yaml#/properties/hp-det-gpios + widgets: + $ref: audio-graph.yaml#/properties/widgets required: - compatible diff --git a/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml index 6676406bf2de..bb92d6ca3144 100644 --- a/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml +++ b/Documentation/devicetree/bindings/sound/awinic,aw88395.yaml @@ -19,6 +19,7 @@ properties: enum: - awinic,aw88081 - awinic,aw88083 + - awinic,aw88166 - awinic,aw88261 - awinic,aw88395 - awinic,aw88399 diff --git a/Documentation/devicetree/bindings/sound/dmic-codec.yaml b/Documentation/devicetree/bindings/sound/dmic-codec.yaml index 59ef0cf6b6e5..cc3c84dd4c26 100644 --- a/Documentation/devicetree/bindings/sound/dmic-codec.yaml +++ b/Documentation/devicetree/bindings/sound/dmic-codec.yaml @@ -19,6 +19,9 @@ properties: '#sound-dai-cells': const: 0 + vref-supply: + description: Phandle to the digital microphone reference supply + dmicen-gpios: description: GPIO specifier for DMIC to control start and stop maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/everest,es8328.yaml b/Documentation/devicetree/bindings/sound/everest,es8328.yaml index ed18e40dcaac..ddddd7b143ab 100644 --- a/Documentation/devicetree/bindings/sound/everest,es8328.yaml +++ b/Documentation/devicetree/bindings/sound/everest,es8328.yaml @@ -24,9 +24,13 @@ maintainers: properties: compatible: - enum: - - everest,es8328 - - everest,es8388 + oneOf: + - enum: + - everest,es8328 + - items: + - enum: + - everest,es8388 + - const: everest,es8328 reg: maxItems: 1 @@ -56,6 +60,7 @@ properties: required: - compatible + - reg - clocks - DVDD-supply - AVDD-supply diff --git a/Documentation/devicetree/bindings/sound/fsl,audmix.yaml b/Documentation/devicetree/bindings/sound/fsl,audmix.yaml index 9413b901cf77..3ad197b3c82c 100644 --- a/Documentation/devicetree/bindings/sound/fsl,audmix.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,audmix.yaml @@ -61,13 +61,26 @@ properties: - description: serial audio input 2 maxItems: 1 + ports: + $ref: /schemas/graph.yaml#/properties/ports + patternProperties: + '^port@[0-1]': + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: Input port from SAI TX + + properties: + port@2: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: Output port to SAI RX + required: - compatible - reg - clocks - clock-names - power-domains - - dais unevaluatedProperties: false @@ -80,4 +93,50 @@ examples: clock-names = "ipg"; power-domains = <&pd_audmix>; dais = <&sai4>, <&sai5>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + playback-only; + + amix_endpoint0: endpoint { + dai-tdm-slot-num = <8>; + dai-tdm-slot-width = <32>; + dai-tdm-slot-width-map = <32 8 32>; + dai-format = "dsp_a"; + remote-endpoint = <&be00_ep>; + }; + }; + + port@1 { + reg = <1>; + playback-only; + + amix_endpoint1: endpoint { + dai-tdm-slot-num = <8>; + dai-tdm-slot-width = <32>; + dai-tdm-slot-width-map = <32 8 32>; + dai-format = "dsp_a"; + remote-endpoint = <&be01_ep>; + }; + }; + + port@2 { + reg = <2>; + capture-only; + + amix_endpoint2: endpoint { + dai-tdm-slot-num = <8>; + dai-tdm-slot-width = <32>; + dai-tdm-slot-width-map = <32 8 32>; + dai-format = "dsp_a"; + bitclock-master; + frame-master; + remote-endpoint = <&be02_ep>; + }; + }; + }; }; diff --git a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml index c454110f4281..8f1108e7e14e 100644 --- a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml @@ -80,7 +80,10 @@ required: - fsl,asrc-rate - fsl,asrc-format -additionalProperties: false +allOf: + - $ref: dai-common.yaml# + +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml b/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml index 76aa1f248488..85799f83e65f 100644 --- a/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml @@ -77,6 +77,10 @@ properties: power-domains: maxItems: 1 + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + fsl,asrc-rate: $ref: /schemas/types.yaml#/definitions/uint32 description: The mutual sample rate used by DPCM Back Ends @@ -120,6 +124,7 @@ required: - fsl,asrc-width allOf: + - $ref: dai-common.yaml# - if: properties: compatible: @@ -145,7 +150,7 @@ allOf: required: - power-domains -additionalProperties: false +unevaluatedProperties: false examples: - | @@ -173,4 +178,12 @@ examples: "txa", "txb", "txc"; fsl,asrc-rate = <48000>; fsl,asrc-width = <16>; + + port { + playback-only; + + asrc_endpoint: endpoint { + remote-endpoint = <&fe00_ep>; + }; + }; }; diff --git a/Documentation/devicetree/bindings/sound/fsl,imx95-cm7-sof.yaml b/Documentation/devicetree/bindings/sound/fsl,imx95-cm7-sof.yaml new file mode 100644 index 000000000000..f00ae3219e15 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,imx95-cm7-sof.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,imx95-cm7-sof.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP imx95 CM7 core + +maintainers: + - Daniel Baluta <daniel.baluta@nxp.com> + +description: NXP imx95 CM7 core used for audio processing + +properties: + compatible: + const: fsl,imx95-cm7-sof + + reg: + maxItems: 1 + + reg-names: + const: sram + + memory-region: + maxItems: 1 + + memory-region-names: + const: dma + + port: + description: SAI3 port + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + +required: + - compatible + - reg + - reg-names + - memory-region + - memory-region-names + - port + +allOf: + - $ref: fsl,sof-cpu.yaml# + +unevaluatedProperties: false + +examples: + - | + cm7-cpu@80000000 { + compatible = "fsl,imx95-cm7-sof"; + reg = <0x80000000 0x6100000>; + reg-names = "sram"; + mboxes = <&mu7 2 0>, <&mu7 2 1>, <&mu7 3 0>, <&mu7 3 1>; + mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1"; + memory-region = <&adma_res>; + memory-region-names = "dma"; + port { + /* SAI3-WM8962 link */ + endpoint { + remote-endpoint = <&wm8962_ep>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml b/Documentation/devicetree/bindings/sound/fsl,sai.yaml index a5d9c246cc47..0d733e5b08a4 100644 --- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml @@ -41,6 +41,10 @@ properties: - fsl,imx93-sai - fsl,imx95-sai - fsl,vf610-sai + - items: + - enum: + - fsl,imx94-sai + - const: fsl,imx95-sai reg: maxItems: 1 @@ -93,6 +97,24 @@ properties: items: - description: receive and transmit interrupt + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: port for TX and RX + + port@1: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: port for TX only + + port@2: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + description: port for RX only + big-endian: description: | required if all the SAI registers are big-endian rather than little-endian. @@ -204,4 +226,37 @@ examples: dma-names = "rx", "tx"; fsl,dataline = <1 0xff 0xff 2 0xff 0x11>; #sound-dai-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + playback-only; + + sai1_endpoint0: endpoint { + dai-tdm-slot-num = <8>; + dai-tdm-slot-width = <32>; + dai-tdm-slot-width-map = <32 8 32>; + dai-format = "dsp_a"; + bitclock-master; + frame-master; + remote-endpoint = <&mcodec01_ep>; + }; + }; + + port@2 { + reg = <2>; + capture-only; + + sai1_endpoint1: endpoint { + dai-tdm-slot-num = <8>; + dai-tdm-slot-width = <32>; + dai-tdm-slot-width-map = <32 8 32>; + dai-format = "dsp_a"; + remote-endpoint = <&fe02_ep>; + }; + }; + }; }; diff --git a/Documentation/devicetree/bindings/sound/fsl,sof-cpu.yaml b/Documentation/devicetree/bindings/sound/fsl,sof-cpu.yaml new file mode 100644 index 000000000000..31863932dbc3 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,sof-cpu.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,sof-cpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP audio processor common properties + +maintainers: + - Daniel Baluta <daniel.baluta@nxp.com> + +properties: + mboxes: + maxItems: 4 + + mbox-names: + items: + - const: txdb0 + - const: txdb1 + - const: rxdb0 + - const: rxdb1 + +required: + - mboxes + - mbox-names + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/sound/ics43432.txt b/Documentation/devicetree/bindings/sound/ics43432.txt deleted file mode 100644 index e6f05f2f6c4e..000000000000 --- a/Documentation/devicetree/bindings/sound/ics43432.txt +++ /dev/null @@ -1,19 +0,0 @@ -Invensense ICS-43432-compatible MEMS microphone with I2S output. - -There are no software configuration options for this device, indeed, the only -host connection is the I2S interface. Apart from requirements on clock -frequency (460 kHz to 3.379 MHz according to the data sheet) there must be -64 clock cycles in each stereo output frame; 24 of the 32 available bits -contain audio data. A hardware pin determines if the device outputs data -on the left or right channel of the I2S frame. - -Required properties: - - compatible: should be one of the following. - "invensense,ics43432": For the Invensense ICS43432 - "cui,cmm-4030d-261": For the CUI CMM-4030D-261-I2S-TR - -Example: - - ics43432: ics43432 { - compatible = "invensense,ics43432"; - }; diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml index f7ad5ea2491e..3c75c8c78987 100644 --- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml +++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml @@ -46,6 +46,14 @@ patternProperties: description: see tdm-slot.txt. $ref: /schemas/types.yaml#/definitions/uint32 + playback-only: + description: link is used only for playback + $ref: /schemas/types.yaml#/definitions/flag + + capture-only: + description: link is used only for capture + $ref: /schemas/types.yaml#/definitions/flag + cpu: description: Holds subnode which indicates cpu dai. type: object @@ -71,6 +79,12 @@ patternProperties: - link-name - cpu + allOf: + - not: + required: + - playback-only + - capture-only + additionalProperties: false required: diff --git a/Documentation/devicetree/bindings/sound/invensense,ics43432.yaml b/Documentation/devicetree/bindings/sound/invensense,ics43432.yaml new file mode 100644 index 000000000000..7bd984817aa9 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/invensense,ics43432.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/invensense,ics43432.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Invensense ICS-43432-compatible MEMS Microphone with I2S Output + +maintainers: + - Oleksij Rempel <o.rempel@pengutronix.de> + +description: + The ICS-43432 and compatible MEMS microphones output audio over an I2S + interface and require no software configuration. The only host connection + is the I2S bus. The microphone requires an I2S clock frequency between + 460 kHz and 3.379 MHz and 64 clock cycles per stereo frame. Each frame + contains 32-bit slots per channel, with 24 bits carrying audio data. + A hardware pin determines whether the microphone outputs audio on the + left or right channel of the I2S frame. + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - invensense,ics43432 + - cui,cmm-4030d-261 + + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + ics43432: ics43432 { + compatible = "invensense,ics43432"; + + port { + endpoint { + remote-endpoint = <&i2s1_endpoint>; + dai-format = "i2s"; + }; + }; + + }; diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml index 362e729b51b4..76d5a437dc8f 100644 --- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml @@ -40,6 +40,14 @@ properties: hardware that provides additional audio functionalities if present. The AFE will link to ADSP when the phandle is provided. + mediatek,accdet: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle to the MT6359 accessory detection block, which detects audio + jack insertion and removal. This property should only be present if the + accdet block is actually wired to the audio jack pins and to be used for + jack detection. + patternProperties: "^dai-link-[0-9]+$": type: object @@ -62,6 +70,7 @@ patternProperties: - PCM1_BE - DL_SRC_BE - UL_SRC_BE + - DMIC_BE codec: description: Holds subnode which indicates codec dai. diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml index 12c31b4b99e1..3ca9affb79a2 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml @@ -28,6 +28,7 @@ properties: - nvidia,tegra186-hda - nvidia,tegra210-hda - nvidia,tegra124-hda + - nvidia,tegra114-hda - const: nvidia,tegra30-hda - items: - const: nvidia,tegra132-hda diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd937x-sdw.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd937x-sdw.yaml index d3cf8f59cb23..c8543f969ebb 100644 --- a/Documentation/devicetree/bindings/sound/qcom,wcd937x-sdw.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,wcd937x-sdw.yaml @@ -58,6 +58,40 @@ properties: items: enum: [1, 2, 3, 4, 5] + qcom,tx-channel-mapping: + description: | + Specifies static channel mapping between slave and master tx port + channels. + In the order of slave port channels which is adc1, adc2, adc3, + dmic0, dmic1, mbhc, dmic2, dmic3, dmci4, dmic5, dmic6, dmic7. + $ref: /schemas/types.yaml#/definitions/uint8-array + minItems: 12 + maxItems: 12 + additionalItems: false + items: + enum: + - 1 # WCD9370_SWRM_CH1 + - 2 # WCD9370_SWRM_CH2 + - 3 # WCD9370_SWRM_CH3 + - 4 # WCD9370_SWRM_CH4 + + qcom,rx-channel-mapping: + description: | + Specifies static channels mapping between slave and master rx port + channels. + In the order of slave port channels, which is + hph_l, hph_r, clsh, comp_l, comp_r, lo, dsd_r, dsd_l. + $ref: /schemas/types.yaml#/definitions/uint8-array + minItems: 8 + maxItems: 8 + additionalItems: false + items: + enum: + - 1 # WCD9370_SWRM_CH1 + - 2 # WCD9370_SWRM_CH2 + - 3 # WCD9370_SWRM_CH3 + - 4 # WCD9370_SWRM_CH4 + required: - compatible - reg @@ -74,6 +108,7 @@ examples: compatible = "sdw20217010a00"; reg = <0 4>; qcom,rx-port-mapping = <1 2 3 4 5>; + qcom,rx-channel-mapping = /bits/ 8 <1 2 1 1 2 1 1 2>; }; }; @@ -85,6 +120,7 @@ examples: compatible = "sdw20217010a00"; reg = <0 3>; qcom,tx-port-mapping = <2 2 3 4>; + qcom,tx-channel-mapping = /bits/ 8 <1 2 1 1 2 3 3 4 1 2 3 4>; }; }; diff --git a/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml index c3c989ef2a2c..32dea7392e8d 100644 --- a/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml +++ b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml @@ -31,6 +31,10 @@ properties: - rockchip,rk3288-spdif - rockchip,rk3308-spdif - const: rockchip,rk3066-spdif + - items: + - enum: + - rockchip,rk3588-spdif + - const: rockchip,rk3568-spdif reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/ti,tas2770.yaml b/Documentation/devicetree/bindings/sound/ti,tas2770.yaml index 5e7aea43aced..8eab98a0f7a2 100644 --- a/Documentation/devicetree/bindings/sound/ti,tas2770.yaml +++ b/Documentation/devicetree/bindings/sound/ti,tas2770.yaml @@ -23,6 +23,7 @@ properties: compatible: enum: - ti,tas2770 + - ti,tas5770l # Apple variant reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/ti,tas27xx.yaml b/Documentation/devicetree/bindings/sound/ti,tas27xx.yaml index 5447482179c1..fcaae848e78a 100644 --- a/Documentation/devicetree/bindings/sound/ti,tas27xx.yaml +++ b/Documentation/devicetree/bindings/sound/ti,tas27xx.yaml @@ -24,6 +24,7 @@ properties: enum: - ti,tas2764 - ti,tas2780 + - ti,sn012776 # Apple variant of TAS2764 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml index 329260cf0fa0..3029a868e5e1 100644 --- a/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml +++ b/Documentation/devicetree/bindings/sound/wlf,wm8904.yaml @@ -38,6 +38,82 @@ properties: DCVDD-supply: true MICVDD-supply: true + wlf,in1l-as-dmicdat1: + type: boolean + description: + Use IN1L/DMICDAT1 as DMICDAT1, enabling the DMIC input path. + Can be used separately or together with wlf,in1r-as-dmicdat2. + + wlf,in1r-as-dmicdat2: + type: boolean + description: + Use IN1R/DMICDAT2 as DMICDAT2, enabling the DMIC input path. + Can be used separately or together with wlf,in1l-as-dmicdat1. + + wlf,gpio-cfg: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 4 + maxItems: 4 + description: + Default register values for R121/122/123/124 (GPIO Control). + If any entry has the value 0xFFFF, the related register won't be set. + default: [0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF] + + wlf,micbias-cfg: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + description: + Default register values for R6/R7 (Mic Bias Control). + default: [0, 0] + + wlf,drc-cfg-names: + $ref: /schemas/types.yaml#/definitions/string-array + description: + List of strings for the available DRC modes. + If absent, DRC is disabled. + + wlf,drc-cfg-regs: + $ref: /schemas/types.yaml#/definitions/uint16-matrix + description: + Sets of default register values for R40/41/42/43 (DRC). + Each set corresponds to a DRC mode, so the number of sets should equal + the length of wlf,drc-cfg-names. + If absent, DRC is disabled. + items: + minItems: 4 + maxItems: 4 + + wlf,retune-mobile-cfg-names: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + List of strings for the available retune modes. + If absent, retune is disabled. + + wlf,retune-mobile-cfg-hz: + description: + The list must be the same length as wlf,retune-mobile-cfg-names. + If absent, retune is disabled. + + wlf,retune-mobile-cfg-regs: + $ref: /schemas/types.yaml#/definitions/uint16-matrix + description: + Sets of default register values for R134/.../157 (EQ). + Each set corresponds to a retune mode, so the number of sets should equal + the length of wlf,retune-mobile-cfg-names. + If absent, retune is disabled. + items: + minItems: 24 + maxItems: 24 + +dependencies: + wlf,drc-cfg-names: [ 'wlf,drc-cfg-regs' ] + wlf,drc-cfg-regs: [ 'wlf,drc-cfg-names' ] + + wlf,retune-mobile-cfg-names: [ 'wlf,retune-mobile-cfg-hz', 'wlf,retune-mobile-cfg-regs' ] + wlf,retune-mobile-cfg-regs: [ 'wlf,retune-mobile-cfg-names', 'wlf,retune-mobile-cfg-hz' ] + wlf,retune-mobile-cfg-hz: [ 'wlf,retune-mobile-cfg-names', 'wlf,retune-mobile-cfg-regs' ] + required: - compatible - reg @@ -70,5 +146,58 @@ examples: DBVDD-supply = <®_1p8v>; DCVDD-supply = <®_1p8v>; MICVDD-supply = <®_1p8v>; + + wlf,drc-cfg-names = "default", "peaklimiter", "tradition", "soft", + "music"; + /* + * Config registers per name, respectively: + * KNEE_IP = 0, KNEE_OP = 0, HI_COMP = 1, LO_COMP = 1 + * KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1 + * KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1 + * KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1 + * KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1 + */ + wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>, + /bits/ 16 <0x04af 0x324b 0x0010 0x0408>, + /bits/ 16 <0x04af 0x324b 0x0028 0x0704>, + /bits/ 16 <0x04af 0x324b 0x0018 0x078c>, + /bits/ 16 <0x04af 0x324b 0x0010 0x050e>; + + /* GPIO1 = DMIC_CLK, don't touch others */ + wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>; + + /* Use IN1R as DMICDAT2, leave IN1L as an analog input path */ + wlf,in1r-as-dmicdat2; + + wlf,retune-mobile-cfg-names = "bassboost", "bassboost", "treble"; + wlf,retune-mobile-cfg-hz = <48000>, <44100>, <48000>; + /* + * Config registers per name, respectively: + * EQ_ENA, 100 Hz, 300 Hz, 875 Hz, 2400 Hz, 6900 Hz + * 1, +6 dB, +3 dB, 0 dB, 0 dB, 0 dB + * 1, +6 dB, +3 dB, 0 dB, 0 dB, 0 dB + * 1, -2 dB, -2 dB, 0 dB, 0 dB, +3 dB + * Each one uses the defaults for ReTune Mobile registers 140-157 + */ + wlf,retune-mobile-cfg-regs = /bits/ 16 <0x1 0x12 0xf 0xc 0xc 0xc + 0x0fca 0x0400 0x00d8 0x1eb5 + 0xf145 0x0bd5 0x0075 0x1c58 + 0xf3d3 0x0a54 0x0568 0x168e + 0xf829 0x07ad 0x1103 0x0564 + 0x0559 0x4000>, + + /bits/ 16 <0x1 0x12 0xf 0xc 0xc 0xc + 0x0fca 0x0400 0x00d8 0x1eb5 + 0xf145 0x0bd5 0x0075 0x1c58 + 0xf3d3 0x0a54 0x0568 0x168e + 0xf829 0x07ad 0x1103 0x0564 + 0x0559 0x4000>, + + /bits/ 16 <0x1 0xa 0xa 0xc 0xc 0xf + 0x0fca 0x0400 0x00d8 0x1eb5 + 0xf145 0x0bd5 0x0075 0x1c58 + 0xf3d3 0x0a54 0x0568 0x168e + 0xf829 0x07ad 0x1103 0x0564 + 0x0559 0x4000>; }; }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml index 62e62c335d07..3c2b9790ffcf 100644 --- a/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml +++ b/Documentation/devicetree/bindings/sound/wlf,wm8960.yaml @@ -75,6 +75,10 @@ properties: enable DACLRC pin. If shared-lrclk is present, no need to enable DAC for captrue. + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt b/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt deleted file mode 100644 index cbc93c8f4963..000000000000 --- a/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.txt +++ /dev/null @@ -1,29 +0,0 @@ -Device-Tree bindings for Xilinx PL audio formatter - -The IP core supports DMA, data formatting(AES<->PCM conversion) -of audio samples. - -Required properties: - - compatible: "xlnx,audio-formatter-1.0" - - interrupt-names: Names specified to list of interrupts in same - order mentioned under "interrupts". - List of supported interrupt names are: - "irq_mm2s" : interrupt from MM2S block - "irq_s2mm" : interrupt from S2MM block - - interrupts-parent: Phandle for interrupt controller. - - interrupts: List of Interrupt numbers. - - reg: Base address and size of the IP core instance. - - clock-names: List of input clocks. - Required elements: "s_axi_lite_aclk", "aud_mclk" - - clocks: Input clock specifier. Refer to common clock bindings. - -Example: - audio_ss_0_audio_formatter_0: audio_formatter@80010000 { - compatible = "xlnx,audio-formatter-1.0"; - interrupt-names = "irq_mm2s", "irq_s2mm"; - interrupt-parent = <&gic>; - interrupts = <0 104 4>, <0 105 4>; - reg = <0x0 0x80010000 0x0 0x1000>; - clock-names = "s_axi_lite_aclk", "aud_mclk"; - clocks = <&clk 71>, <&clk_wiz_1 0>; - }; diff --git a/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.yaml b/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.yaml new file mode 100644 index 000000000000..82fa448bd2e9 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/xlnx,audio-formatter.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/xlnx,audio-formatter.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx PL audio formatter + +description: + The IP core supports DMA, data formatting(AES<->PCM conversion) + of audio samples. + +maintainers: + - Vincenzo Frascino <vincenzo.frascino@arm.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - xlnx,audio-formatter-1.0 + + reg: + maxItems: 1 + + interrupt-names: + minItems: 1 + items: + - const: irq_mm2s + - const: irq_s2mm + + interrupts: + minItems: 1 + items: + - description: interrupt from MM2S block + - description: interrupt from S2MM block + + clock-names: + minItems: 1 + items: + - const: s_axi_lite_aclk + - const: aud_mclk + + clocks: + minItems: 1 + items: + - description: clock for the axi data stream + - description: clock for the MEMS microphone data stream + +required: + - compatible + - reg + - interrupt-names + - interrupts + - clock-names + - clocks + +additionalProperties: false + +examples: + - | + audio_formatter@80010000 { + compatible = "xlnx,audio-formatter-1.0"; + reg = <0x80010000 0x1000>; + interrupt-names = "irq_mm2s", "irq_s2mm"; + interrupt-parent = <&gic>; + interrupts = <0 104 4>, <0 105 4>; + clock-names = "s_axi_lite_aclk", "aud_mclk"; + clocks = <&clk 71>, <&clk_wiz_1 0>; + }; +... diff --git a/Documentation/devicetree/bindings/sound/xlnx,i2s.txt b/Documentation/devicetree/bindings/sound/xlnx,i2s.txt deleted file mode 100644 index 5e7c7d5bb60a..000000000000 --- a/Documentation/devicetree/bindings/sound/xlnx,i2s.txt +++ /dev/null @@ -1,28 +0,0 @@ -Device-Tree bindings for Xilinx I2S PL block - -The IP supports I2S based playback/capture audio - -Required property: - - compatible: "xlnx,i2s-transmitter-1.0" for playback and - "xlnx,i2s-receiver-1.0" for capture - -Required property common to both I2S playback and capture: - - reg: Base address and size of the IP core instance. - - xlnx,dwidth: sample data width. Can be any of 16, 24. - - xlnx,num-channels: Number of I2S streams. Can be any of 1, 2, 3, 4. - supported channels = 2 * xlnx,num-channels - -Example: - - i2s_receiver@a0080000 { - compatible = "xlnx,i2s-receiver-1.0"; - reg = <0x0 0xa0080000 0x0 0x10000>; - xlnx,dwidth = <0x18>; - xlnx,num-channels = <1>; - }; - i2s_transmitter@a0090000 { - compatible = "xlnx,i2s-transmitter-1.0"; - reg = <0x0 0xa0090000 0x0 0x10000>; - xlnx,dwidth = <0x18>; - xlnx,num-channels = <1>; - }; diff --git a/Documentation/devicetree/bindings/sound/xlnx,i2s.yaml b/Documentation/devicetree/bindings/sound/xlnx,i2s.yaml new file mode 100644 index 000000000000..3c2b0be07c53 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/xlnx,i2s.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/xlnx,i2s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx I2S PL block + +description: + The IP supports I2S based playback/capture audio. + +maintainers: + - Vincenzo Frascino <vincenzo.frascino@arm.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - xlnx,i2s-receiver-1.0 + - xlnx,i2s-transmitter-1.0 + + reg: + maxItems: 1 + + xlnx,dwidth: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 16 + - 24 + description: | + Sample data width. + + xlnx,num-channels: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 4 + description: | + Number of I2S streams. + +required: + - compatible + - reg + - xlnx,dwidth + - xlnx,num-channels + +additionalProperties: false + +examples: + - | + i2s@a0080000 { + compatible = "xlnx,i2s-receiver-1.0"; + reg = <0xa0080000 0x10000>; + xlnx,dwidth = <0x18>; + xlnx,num-channels = <1>; + }; + i2s@a0090000 { + compatible = "xlnx,i2s-transmitter-1.0"; + reg = <0xa0090000 0x10000>; + xlnx,dwidth = <0x18>; + xlnx,num-channels = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/xlnx,spdif.txt b/Documentation/devicetree/bindings/sound/xlnx,spdif.txt deleted file mode 100644 index 15c2d64d247c..000000000000 --- a/Documentation/devicetree/bindings/sound/xlnx,spdif.txt +++ /dev/null @@ -1,28 +0,0 @@ -Device-Tree bindings for Xilinx SPDIF IP - -The IP supports playback and capture of SPDIF audio - -Required properties: - - compatible: "xlnx,spdif-2.0" - - clock-names: List of input clocks. - Required elements: "s_axi_aclk", "aud_clk_i" - - clocks: Input clock specifier. Refer to common clock bindings. - - reg: Base address and address length of the IP core instance. - - interrupts-parent: Phandle for interrupt controller. - - interrupts: List of Interrupt numbers. - - xlnx,spdif-mode: 0 :- receiver mode - 1 :- transmitter mode - - xlnx,aud_clk_i: input audio clock value. - -Example: - spdif_0: spdif@80010000 { - clock-names = "aud_clk_i", "s_axi_aclk"; - clocks = <&misc_clk_0>, <&clk 71>; - compatible = "xlnx,spdif-2.0"; - interrupt-names = "spdif_interrupt"; - interrupt-parent = <&gic>; - interrupts = <0 91 4>; - reg = <0x0 0x80010000 0x0 0x10000>; - xlnx,spdif-mode = <1>; - xlnx,aud_clk_i = <49152913>; - }; diff --git a/Documentation/devicetree/bindings/sound/xlnx,spdif.yaml b/Documentation/devicetree/bindings/sound/xlnx,spdif.yaml new file mode 100644 index 000000000000..a45d8a0755fe --- /dev/null +++ b/Documentation/devicetree/bindings/sound/xlnx,spdif.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/xlnx,spdif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx SPDIF IP + +description: + The IP supports playback and capture of SPDIF audio. + +maintainers: + - Vincenzo Frascino <vincenzo.frascino@arm.com> + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + enum: + - xlnx,spdif-2.0 + + reg: + maxItems: 1 + + interrupts: + items: + - description: SPDIF audio interrupt + + clock-names: + items: + - const: aud_clk_i + - const: s_axi_aclk + + clocks: + minItems: 1 + items: + - description: input audio clock + - description: clock for the AXI data stream + + xlnx,spdif-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 + - 1 + description: | + 0 - receiver + 1 - transmitter + + xlnx,aud_clk_i: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Input audio clock frequency. It affects the sampling rate. + +required: + - compatible + - reg + - interrupts + - clock-names + - clocks + +additionalProperties: false + +examples: + - | + spdif@80010000 { + compatible = "xlnx,spdif-2.0"; + reg = <0x80010000 0x10000>; + clock-names = "aud_clk_i", "s_axi_aclk"; + clocks = <&misc_clk_0>, <&clk 71>; + interrupt-parent = <&gic>; + interrupts = <0 91 4>; + xlnx,spdif-mode = <1>; + xlnx,aud_clk_i = <49152913>; + }; + +... diff --git a/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.yaml b/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.yaml index d48faa42d025..4b3828eda6cb 100644 --- a/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.yaml +++ b/Documentation/devicetree/bindings/spi/adi,axi-spi-engine.yaml @@ -41,6 +41,26 @@ properties: - const: s_axi_aclk - const: spi_clk + trigger-sources: + description: + An array of trigger source phandles for offload instances. The index in + the array corresponds to the offload instance number. + minItems: 1 + maxItems: 32 + + dmas: + description: + DMA channels connected to the input or output stream interface of an + offload instance. + minItems: 1 + maxItems: 32 + + dma-names: + items: + pattern: "^offload(?:[12]?[0-9]|3[01])-[tr]x$" + minItems: 1 + maxItems: 32 + required: - compatible - reg @@ -59,6 +79,10 @@ examples: clocks = <&clkc 15>, <&clkc 15>; clock-names = "s_axi_aclk", "spi_clk"; + trigger-sources = <&trigger_clock>; + dmas = <&dma 0>; + dma-names = "offload0-rx"; + #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml index b6bc71d19286..53a52fb8b819 100644 --- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/spi/cdns,qspi-nor.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Cadence Quad SPI controller +title: Cadence Quad/Octal SPI controller maintainers: - Vaishnav Achath <vaishnav.a@ti.com> @@ -76,8 +76,12 @@ properties: - ti,am654-ospi - ti,k2g-qspi - xlnx,versal-ospi-1.0 + # The compatible is qspi-nor for historical reasons but such + # controllers are meant to be used with flashes of all kinds, + # ie. also NAND flashes, not only NOR flashes. - const: cdns,qspi-nor - const: cdns,qspi-nor + deprecated: true reg: items: @@ -142,6 +146,18 @@ properties: items: enum: [ qspi, qspi-ocp, rstc_ref ] +patternProperties: + "^flash@[0-9a-f]+$": + type: object + $ref: cdns,qspi-nor-peripheral-props.yaml + additionalProperties: true + required: + - cdns,read-delay + - cdns,tshsl-ns + - cdns,tsd2d-ns + - cdns,tchsh-ns + - cdns,tslch-ns + required: - compatible - reg @@ -157,7 +173,7 @@ unevaluatedProperties: false examples: - | qspi: spi@ff705000 { - compatible = "cdns,qspi-nor"; + compatible = "intel,socfpga-qspi", "cdns,qspi-nor"; #address-cells = <1>; #size-cells = <0>; reg = <0xff705000 0x1000>, @@ -173,5 +189,10 @@ examples: flash@0 { compatible = "jedec,spi-nor"; reg = <0x0>; + cdns,read-delay = <4>; + cdns,tshsl-ns = <60>; + cdns,tsd2d-ns = <60>; + cdns,tchsh-ns = <60>; + cdns,tslch-ns = <60>; }; }; diff --git a/Documentation/devicetree/bindings/spi/fsl,espi.yaml b/Documentation/devicetree/bindings/spi/fsl,espi.yaml new file mode 100644 index 000000000000..d267bbfaf02f --- /dev/null +++ b/Documentation/devicetree/bindings/spi/fsl,espi.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/fsl,espi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale eSPI (Enhanced Serial Peripheral Interface) controller + +maintainers: + - J. Neuschäfer <j.ne@posteo.net> + +properties: + compatible: + const: fsl,mpc8536-espi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + fsl,espi-num-chipselects: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 4 ] + description: The number of the chipselect signals. + + fsl,csbef: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Chip select assertion time in bits before frame starts + + fsl,csaft: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Chip select negation time in bits after frame ends + +required: + - compatible + - reg + - interrupts + - fsl,espi-num-chipselects + +allOf: + - $ref: spi-controller.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + spi@110000 { + compatible = "fsl,mpc8536-espi"; + reg = <0x110000 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <53 IRQ_TYPE_EDGE_FALLING>; + fsl,espi-num-chipselects = <4>; + fsl,csbef = <1>; + fsl,csaft = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/spi/fsl,spi.yaml b/Documentation/devicetree/bindings/spi/fsl,spi.yaml new file mode 100644 index 000000000000..d74792fc9bf2 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/fsl,spi.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/fsl,spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale SPI (Serial Peripheral Interface) controller + +maintainers: + - J. Neuschäfer <j.ne@posteo.net> + +properties: + compatible: + enum: + - fsl,spi + - aeroflexgaisler,spictrl + + reg: + maxItems: 1 + + cell-index: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + QE SPI subblock index. + 0: QE subblock SPI1 + 1: QE subblock SPI2 + + mode: + description: SPI operation mode + enum: + - cpu + - cpu-qe + + interrupts: + maxItems: 1 + + clock-frequency: + description: input clock frequency to non FSL_SOC cores + + cs-gpios: true + + fsl,spisel_boot: + $ref: /schemas/types.yaml#/definitions/flag + description: + For the MPC8306 and MPC8309, specifies that the SPISEL_BOOT signal is used + as chip select for a slave device. Use reg = <number of gpios> in the + corresponding child node, i.e. 0 if the cs-gpios property is not present. + +required: + - compatible + - reg + - mode + - interrupts + +allOf: + - $ref: spi-controller.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + spi@4c0 { + compatible = "fsl,spi"; + reg = <0x4c0 0x40>; + cell-index = <0>; + interrupts = <82 0>; + mode = "cpu"; + cs-gpios = <&gpio 18 IRQ_TYPE_EDGE_RISING // device reg=<0> + &gpio 19 IRQ_TYPE_EDGE_RISING>; // device reg=<1> + }; + +... diff --git a/Documentation/devicetree/bindings/spi/fsl-spi.txt b/Documentation/devicetree/bindings/spi/fsl-spi.txt deleted file mode 100644 index 0654380eb751..000000000000 --- a/Documentation/devicetree/bindings/spi/fsl-spi.txt +++ /dev/null @@ -1,62 +0,0 @@ -* SPI (Serial Peripheral Interface) - -Required properties: -- cell-index : QE SPI subblock index. - 0: QE subblock SPI1 - 1: QE subblock SPI2 -- compatible : should be "fsl,spi" or "aeroflexgaisler,spictrl". -- mode : the SPI operation mode, it can be "cpu" or "cpu-qe". -- reg : Offset and length of the register set for the device -- interrupts : <a b> where a is the interrupt number and b is a - field that represents an encoding of the sense and level - information for the interrupt. This should be encoded based on - the information in section 2) depending on the type of interrupt - controller you have. -- clock-frequency : input clock frequency to non FSL_SOC cores - -Optional properties: -- cs-gpios : specifies the gpio pins to be used for chipselects. - The gpios will be referred to as reg = <index> in the SPI child nodes. - If unspecified, a single SPI device without a chip select can be used. -- fsl,spisel_boot : for the MPC8306 and MPC8309, specifies that the - SPISEL_BOOT signal is used as chip select for a slave device. Use - reg = <number of gpios> in the corresponding child node, i.e. 0 if - the cs-gpios property is not present. - -Example: - spi@4c0 { - cell-index = <0>; - compatible = "fsl,spi"; - reg = <4c0 40>; - interrupts = <82 0>; - interrupt-parent = <700>; - mode = "cpu"; - cs-gpios = <&gpio 18 1 // device reg=<0> - &gpio 19 1>; // device reg=<1> - }; - - -* eSPI (Enhanced Serial Peripheral Interface) - -Required properties: -- compatible : should be "fsl,mpc8536-espi". -- reg : Offset and length of the register set for the device. -- interrupts : should contain eSPI interrupt, the device has one interrupt. -- fsl,espi-num-chipselects : the number of the chipselect signals. - -Optional properties: -- fsl,csbef: chip select assertion time in bits before frame starts -- fsl,csaft: chip select negation time in bits after frame ends - -Example: - spi@110000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "fsl,mpc8536-espi"; - reg = <0x110000 0x1000>; - interrupts = <53 0x2>; - interrupt-parent = <&mpic>; - fsl,espi-num-chipselects = <4>; - fsl,csbef = <1>; - fsl,csaft = <1>; - }; diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml index e1f5bfa4433c..ed17815263a8 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml @@ -35,6 +35,8 @@ properties: - enum: - mediatek,mt7981-spi-ipm - mediatek,mt7986-spi-ipm + - mediatek,mt7988-spi-quad + - mediatek,mt7988-spi-single - mediatek,mt8188-spi-ipm - const: mediatek,spi-ipm - items: diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qpic-snand.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qpic-snand.yaml new file mode 100644 index 000000000000..aa3f93319203 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qpic-snand.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/qcom,spi-qpic-snand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm QPIC NAND controller + +maintainers: + - Md sadre Alam <quic_mdalam@quicinc.com> + +description: + The QCOM QPIC-SPI-NAND flash controller is an extended version of + the QCOM QPIC NAND flash controller. It can work both in serial + and parallel mode. It supports typical SPI-NAND page cache + operations in single, dual or quad IO mode with pipelined ECC + encoding/decoding using the QPIC ECC HW engine. + +allOf: + - $ref: /schemas/spi/spi-controller.yaml# + +properties: + compatible: + enum: + - qcom,ipq9574-snand + + reg: + maxItems: 1 + + clocks: + maxItems: 3 + + clock-names: + items: + - const: core + - const: aon + - const: iom + + dmas: + items: + - description: tx DMA channel + - description: rx DMA channel + - description: cmd DMA channel + + dma-names: + items: + - const: tx + - const: rx + - const: cmd + +required: + - compatible + - reg + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,ipq9574-gcc.h> + spi@79b0000 { + compatible = "qcom,ipq9574-snand"; + reg = <0x1ac00000 0x800>; + + clocks = <&gcc GCC_QPIC_CLK>, + <&gcc GCC_QPIC_AHB_CLK>, + <&gcc GCC_QPIC_IO_MACRO_CLK>; + clock-names = "core", "aon", "iom"; + + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "spi-nand"; + reg = <0>; + #address-cells = <1>; + #size-cells = <1>; + nand-ecc-engine = <&qpic_nand>; + nand-ecc-strength = <4>; + nand-ecc-step-size = <512>; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml index ed1d4aa41b8c..a65a42ccaafe 100644 --- a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml +++ b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml @@ -24,6 +24,7 @@ properties: - enum: - fsl,imx8ulp-spi - fsl,imx93-spi + - fsl,imx94-spi - fsl,imx95-spi - const: fsl,imx7ulp-spi reg: diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml index 46d9d6ee0923..104f5ffdd04e 100644 --- a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml +++ b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml @@ -34,6 +34,7 @@ properties: - rockchip,rk3328-spi - rockchip,rk3368-spi - rockchip,rk3399-spi + - rockchip,rk3562-spi - rockchip,rk3568-spi - rockchip,rk3576-spi - rockchip,rk3588-spi diff --git a/Documentation/devicetree/bindings/spi/spi-sg2044-nor.yaml b/Documentation/devicetree/bindings/spi/spi-sg2044-nor.yaml new file mode 100644 index 000000000000..948ff7a09643 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-sg2044-nor.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-sg2044-nor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SG2044 SPI NOR controller + +maintainers: + - Longbin Li <looong.bin@gmail.com> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + const: sophgo,sg2044-spifmc-nor + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + spi@1000000 { + compatible = "sophgo,sg2044-spifmc-nor"; + reg = <0x1000000 0x4000000>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&clk 0>; + interrupts = <37 IRQ_TYPE_LEVEL_HIGH>; + resets = <&rst 0>; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml index 04d4d3b4916d..02cf1314367b 100644 --- a/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.yaml @@ -65,14 +65,13 @@ allOf: examples: - | - #include <dt-bindings/clock/xlnx-zynqmp-clk.h> soc { #address-cells = <2>; #size-cells = <2>; qspi: spi@ff0f0000 { compatible = "xlnx,zynqmp-qspi-1.0"; - clocks = <&zynqmp_clk QSPI_REF>, <&zynqmp_clk LPD_LSBUS>; + clocks = <&zynqmp_clk 53>, <&zynqmp_clk 82>; clock-names = "ref_clk", "pclk"; interrupts = <0 15 4>; interrupt-parent = <&gic>; diff --git a/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml b/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml new file mode 100644 index 000000000000..5f276f27dc4c --- /dev/null +++ b/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/st,stm32mp25-ospi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STM32 Octal Serial Peripheral Interface (OSPI) + +maintainers: + - Patrice Chotard <patrice.chotard@foss.st.com> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + const: st,stm32mp25-ospi + + reg: + maxItems: 1 + + memory-region: + description: + Memory region to be used for memory-map read access. + In memory-mapped mode, read access are performed from the memory + device using the direct mapping. + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + + resets: + items: + - description: phandle to OSPI block reset + - description: phandle to delay block reset + + dmas: + maxItems: 2 + + dma-names: + items: + - const: tx + - const: rx + + st,syscfg-dlyb: + description: configure OCTOSPI delay block. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - description: phandle to syscfg + - description: register offset within syscfg + + access-controllers: + description: phandle to the rifsc device to check access right + and in some cases, an additional phandle to the rcc device for + secure clock control. + items: + - description: phandle to bus controller + - description: phandle to clock controller + minItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + - st,syscfg-dlyb + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/st,stm32mp25-rcc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/reset/st,stm32mp25-rcc.h> + + spi@40430000 { + compatible = "st,stm32mp25-ospi"; + reg = <0x40430000 0x400>; + memory-region = <&mm_ospi1>; + interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&hpdma 2 0x62 0x00003121 0x0>, + <&hpdma 2 0x42 0x00003112 0x0>; + dma-names = "tx", "rx"; + clocks = <&scmi_clk CK_SCMI_OSPI1>; + resets = <&scmi_reset RST_SCMI_OSPI1>, <&scmi_reset RST_SCMI_OSPI1DLL>; + access-controllers = <&rifsc 74>; + power-domains = <&CLUSTER_PD>; + st,syscfg-dlyb = <&syscfg 0x1000>; + + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + spi-rx-bus-width = <4>; + spi-max-frequency = <108000000>; + }; + }; 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/timer/arm,twd-timer.yaml b/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml index 5684df6448ef..eb1127352c7b 100644 --- a/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml +++ b/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml @@ -50,7 +50,7 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> timer@2c000600 { - compatible = "arm,arm11mp-twd-timer"; - reg = <0x2c000600 0x20>; - interrupts = <GIC_PPI 13 0xf01>; + compatible = "arm,arm11mp-twd-timer"; + reg = <0x2c000600 0x20>; + interrupts = <GIC_PPI 13 0xf01>; }; diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.yaml b/Documentation/devicetree/bindings/timer/renesas,cmt.yaml index 5e09c04da30e..260b05f213e6 100644 --- a/Documentation/devicetree/bindings/timer/renesas,cmt.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.yaml @@ -178,29 +178,29 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/power/r8a7790-sysc.h> cmt0: timer@ffca0000 { - compatible = "renesas,r8a7790-cmt0", "renesas,rcar-gen2-cmt0"; - reg = <0xffca0000 0x1004>; - interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 124>; - clock-names = "fck"; - power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; - resets = <&cpg 124>; + compatible = "renesas,r8a7790-cmt0", "renesas,rcar-gen2-cmt0"; + reg = <0xffca0000 0x1004>; + interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 124>; + clock-names = "fck"; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 124>; }; cmt1: timer@e6130000 { - compatible = "renesas,r8a7790-cmt1", "renesas,rcar-gen2-cmt1"; - reg = <0xe6130000 0x1004>; - interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 329>; - clock-names = "fck"; - power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; - resets = <&cpg 329>; + compatible = "renesas,r8a7790-cmt1", "renesas,rcar-gen2-cmt1"; + reg = <0xe6130000 0x1004>; + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 329>; + clock-names = "fck"; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 329>; }; diff --git a/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml b/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml index 233d74d5402c..a7385d865bca 100644 --- a/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,em-sti.yaml @@ -38,9 +38,9 @@ examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> timer@e0180000 { - compatible = "renesas,em-sti"; - reg = <0xe0180000 0x54>; - interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&sti_sclk>; - clock-names = "sclk"; + compatible = "renesas,em-sti"; + reg = <0xe0180000 0x54>; + interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&sti_sclk>; + clock-names = "sclk"; }; diff --git a/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml b/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml index 15d8dddf4ae9..e56c12f03f72 100644 --- a/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,mtu2.yaml @@ -66,11 +66,11 @@ examples: #include <dt-bindings/clock/r7s72100-clock.h> #include <dt-bindings/interrupt-controller/arm-gic.h> mtu2: timer@fcff0000 { - compatible = "renesas,mtu2-r7s72100", "renesas,mtu2"; - reg = <0xfcff0000 0x400>; - interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "tgi0a"; - clocks = <&mstp3_clks R7S72100_CLK_MTU2>; - clock-names = "fck"; - power-domains = <&cpg_clocks>; + compatible = "renesas,mtu2-r7s72100", "renesas,mtu2"; + reg = <0xfcff0000 0x400>; + interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "tgi0a"; + clocks = <&mstp3_clks R7S72100_CLK_MTU2>; + clock-names = "fck"; + power-domains = <&cpg_clocks>; }; diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml index e8c642166462..9ba858f094ab 100644 --- a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml @@ -71,9 +71,9 @@ examples: #include <dt-bindings/clock/r7s72100-clock.h> #include <dt-bindings/interrupt-controller/arm-gic.h> ostm0: timer@fcfec000 { - compatible = "renesas,r7s72100-ostm", "renesas,ostm"; - reg = <0xfcfec000 0x30>; - interrupts = <GIC_SPI 102 IRQ_TYPE_EDGE_RISING>; - clocks = <&mstp5_clks R7S72100_CLK_OSTM0>; - power-domains = <&cpg_clocks>; + compatible = "renesas,r7s72100-ostm", "renesas,ostm"; + reg = <0xfcfec000 0x30>; + interrupts = <GIC_SPI 102 IRQ_TYPE_EDGE_RISING>; + clocks = <&mstp5_clks R7S72100_CLK_OSTM0>; + power-domains = <&cpg_clocks>; }; diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml index 75b0e7c70b62..b1229595acfb 100644 --- a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml @@ -122,15 +122,15 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/power/r8a7779-sysc.h> tmu0: timer@ffd80000 { - compatible = "renesas,tmu-r8a7779", "renesas,tmu"; - reg = <0xffd80000 0x30>; - interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "tuni0", "tuni1", "tuni2", "ticpi2"; - clocks = <&mstp0_clks R8A7779_CLK_TMU0>; - clock-names = "fck"; - power-domains = <&sysc R8A7779_PD_ALWAYS_ON>; - #renesas,channels = <3>; + compatible = "renesas,tmu-r8a7779", "renesas,tmu"; + reg = <0xffd80000 0x30>; + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "tuni0", "tuni1", "tuni2", "ticpi2"; + clocks = <&mstp0_clks R8A7779_CLK_TMU0>; + clock-names = "fck"; + power-domains = <&sysc R8A7779_PD_ALWAYS_ON>; + #renesas,channels = <3>; }; diff --git a/Documentation/devicetree/bindings/timer/renesas,tpu.yaml b/Documentation/devicetree/bindings/timer/renesas,tpu.yaml index 01554dff23d8..7a473b302775 100644 --- a/Documentation/devicetree/bindings/timer/renesas,tpu.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,tpu.yaml @@ -49,8 +49,8 @@ additionalProperties: false examples: - | tpu: tpu@ffffe0 { - compatible = "renesas,tpu"; - reg = <0xffffe0 16>, <0xfffff0 12>; - clocks = <&pclk>; - clock-names = "fck"; + compatible = "renesas,tpu"; + reg = <0xffffe0 16>, <0xfffff0 12>; + clocks = <&pclk>; + clock-names = "fck"; }; diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml index 02d1c355808e..10578f544581 100644 --- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.yaml @@ -27,6 +27,7 @@ properties: - enum: - axis,artpec8-mct - google,gs101-mct + - samsung,exynos2200-mct-peris - samsung,exynos3250-mct - samsung,exynos5250-mct - samsung,exynos5260-mct @@ -34,6 +35,7 @@ properties: - samsung,exynos5433-mct - samsung,exynos850-mct - samsung,exynos8895-mct + - samsung,exynos990-mct - tesla,fsd-mct - const: samsung,exynos4210-mct @@ -130,11 +132,13 @@ allOf: enum: - axis,artpec8-mct - google,gs101-mct + - samsung,exynos2200-mct-peris - samsung,exynos5260-mct - samsung,exynos5420-mct - samsung,exynos5433-mct - samsung,exynos850-mct - samsung,exynos8895-mct + - samsung,exynos990-mct then: properties: interrupts: diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml index 76d83aea4e2b..653e2e0ca878 100644 --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml @@ -37,6 +37,12 @@ properties: - starfive,jh8100-clint # StarFive JH8100 - const: sifive,clint0 # SiFive CLINT v0 IP block - items: + - {} + - const: sifive,clint2 # SiFive CLINT v2 IP block + description: + SiFive CLINT v2 is the HRT that supports the Zicntr. The control of sifive,clint2 + differs from that of sifive,clint0, making them incompatible. + - items: - enum: - allwinner,sun20i-d1-clint - sophgo,cv1800b-clint @@ -62,6 +68,22 @@ properties: minItems: 1 maxItems: 4095 + sifive,fine-ctr-bits: + maximum: 15 + description: The width in bits of the fine counter. + +if: + properties: + compatible: + contains: + const: sifive,clint2 +then: + required: + - sifive,fine-ctr-bits +else: + properties: + sifive,fine-ctr-bits: false + additionalProperties: false required: @@ -77,6 +99,6 @@ examples: <&cpu2intc 3>, <&cpu2intc 7>, <&cpu3intc 3>, <&cpu3intc 7>, <&cpu4intc 3>, <&cpu4intc 7>; - reg = <0x2000000 0x10000>; + reg = <0x2000000 0x10000>; }; ... diff --git a/Documentation/devicetree/bindings/trigger-source/pwm-trigger.yaml b/Documentation/devicetree/bindings/trigger-source/pwm-trigger.yaml new file mode 100644 index 000000000000..1eac20031dc3 --- /dev/null +++ b/Documentation/devicetree/bindings/trigger-source/pwm-trigger.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/trigger-source/pwm-trigger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic trigger source using PWM + +description: Remaps a PWM channel as a trigger source. + +maintainers: + - David Lechner <dlechner@baylibre.com> + +properties: + compatible: + const: pwm-trigger + + '#trigger-source-cells': + const: 0 + + pwms: + maxItems: 1 + +required: + - compatible + - '#trigger-source-cells' + - pwms + +additionalProperties: false + +examples: + - | + trigger { + compatible = "pwm-trigger"; + #trigger-source-cells = <0>; + pwms = <&pwm 0 1000000 0>; + }; diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index fadbd3c041c8..8da408107e55 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -185,10 +185,20 @@ 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 + - meas,htu31 # Measurement Specialities I2C pressure and temperature sensor - meas,ms5637 # Measurement Specialities I2C pressure and temperature sensor @@ -380,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 @@ -387,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/ufs/renesas,ufs.yaml b/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml index 1949a15e73d2..ac11ac7d1d12 100644 --- a/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/renesas,ufs.yaml @@ -33,6 +33,16 @@ properties: resets: maxItems: 1 + nvmem-cells: + maxItems: 1 + + nvmem-cell-names: + items: + - const: calibration + +dependencies: + nvmem-cells: [ nvmem-cell-names ] + required: - compatible - reg @@ -58,4 +68,6 @@ examples: freq-table-hz = <200000000 200000000>, <38400000 38400000>; power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>; resets = <&cpg 1514>; + nvmem-cells = <&ufs_tune>; + nvmem-cell-names = "calibration"; }; diff --git a/Documentation/devicetree/bindings/ufs/rockchip,rk3576-ufshc.yaml b/Documentation/devicetree/bindings/ufs/rockchip,rk3576-ufshc.yaml new file mode 100644 index 000000000000..c7d17cf4dc42 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/rockchip,rk3576-ufshc.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/rockchip,rk3576-ufshc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip UFS Host Controller + +maintainers: + - Shawn Lin <shawn.lin@rock-chips.com> + +allOf: + - $ref: ufs-common.yaml + +properties: + compatible: + const: rockchip,rk3576-ufshc + + reg: + maxItems: 5 + + reg-names: + items: + - const: hci + - const: mphy + - const: hci_grf + - const: mphy_grf + - const: hci_apb + + clocks: + maxItems: 4 + + clock-names: + items: + - const: core + - const: pclk + - const: pclk_mphy + - const: ref_out + + power-domains: + maxItems: 1 + + resets: + maxItems: 4 + + reset-names: + items: + - const: biu + - const: sys + - const: ufs + - const: grf + + reset-gpios: + maxItems: 1 + description: | + GPIO specifiers for host to reset the whole UFS device including PHY and + memory. This gpio is active low and should choose the one whose high output + voltage is lower than 1.5V based on the UFS spec. + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - interrupts + - power-domains + - resets + - reset-names + - reset-gpios + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/rockchip,rk3576-cru.h> + #include <dt-bindings/reset/rockchip,rk3576-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/rockchip,rk3576-power.h> + #include <dt-bindings/pinctrl/rockchip.h> + #include <dt-bindings/gpio/gpio.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + ufshc: ufshc@2a2d0000 { + compatible = "rockchip,rk3576-ufshc"; + reg = <0x0 0x2a2d0000 0x0 0x10000>, + <0x0 0x2b040000 0x0 0x10000>, + <0x0 0x2601f000 0x0 0x1000>, + <0x0 0x2603c000 0x0 0x1000>, + <0x0 0x2a2e0000 0x0 0x10000>; + reg-names = "hci", "mphy", "hci_grf", "mphy_grf", "hci_apb"; + clocks = <&cru ACLK_UFS_SYS>, <&cru PCLK_USB_ROOT>, <&cru PCLK_MPHY>, + <&cru CLK_REF_UFS_CLKOUT>; + clock-names = "core", "pclk", "pclk_mphy", "ref_out"; + interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&power RK3576_PD_USB>; + resets = <&cru SRST_A_UFS_BIU>, <&cru SRST_A_UFS_SYS>, <&cru SRST_A_UFS>, + <&cru SRST_P_UFS_GRF>; + reset-names = "biu", "sys", "ufs", "grf"; + reset-gpios = <&gpio4 RK_PD0 GPIO_ACTIVE_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml index 00f87a558c7d..b5843f4d17d8 100644 --- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml +++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml @@ -101,7 +101,6 @@ examples: #include <dt-bindings/dma/xlnx-zynqmp-dpdma.h> #include <dt-bindings/power/xlnx-zynqmp-power.h> #include <dt-bindings/reset/xlnx-zynqmp-resets.h> - #include <dt-bindings/clock/xlnx-zynqmp-clk.h> #include <dt-bindings/reset/xlnx-zynqmp-resets.h> #include <dt-bindings/phy/phy.h> axi { @@ -113,7 +112,7 @@ examples: #size-cells = <0x2>; compatible = "xlnx,zynqmp-dwc3"; reg = <0x0 0xff9d0000 0x0 0x100>; - clocks = <&zynqmp_clk USB0_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>; + clocks = <&zynqmp_clk 32>, <&zynqmp_clk 34>; clock-names = "bus_clk", "ref_clk"; power-domains = <&zynqmp_firmware PD_USB_0>; resets = <&zynqmp_reset ZYNQMP_RESET_USB1_CORERESET>, 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/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml index ef3143f4b794..004d3ebec091 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml @@ -106,6 +106,10 @@ properties: - description: USB3/SS(P) PHY - description: USB2/HS PHY + port: + $ref: /schemas/graph.yaml#/properties/port + description: Super Speed (SS) Output endpoint to a Type-C connector + vusb33-supply: description: Regulator of USB AVDD3.3v diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml index d4e187c78a0b..21fc6bbe954f 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml @@ -155,6 +155,18 @@ properties: property is used. See graph.txt $ref: /schemas/graph.yaml#/properties/port + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: High Speed (HS) data bus. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Super Speed (SS) data bus. + enable-manual-drd: $ref: /schemas/types.yaml#/definitions/flag description: 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 5079ca6ce1d1..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 @@ -147,6 +147,8 @@ patternProperties: description: Arctic Sand "^arcx,.*": description: arcx Inc. / Archronix Inc. + "^ariaboard,.*": + description: Shanghai Novotech Co., Ltd. (Ariaboard) "^aries,.*": description: Aries Embedded GmbH "^arm,.*": @@ -338,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,.*": @@ -593,6 +597,8 @@ patternProperties: description: GlobalTop Technology, Inc. "^gmt,.*": description: Global Mixed-mode Technology, Inc. + "^gocontroll,.*": + description: GOcontroll Modular Embedded Electronics B.V. "^goldelico,.*": description: Golden Delicious Computers GmbH & Co. KG "^goodix,.*": @@ -1031,6 +1037,8 @@ patternProperties: description: Neofidelity Inc. "^neonode,.*": description: Neonode Inc. + "^netcube,.*": + description: NetCube Systems Austria "^netgear,.*": description: NETGEAR "^netlogic,.*": @@ -1202,6 +1210,8 @@ patternProperties: description: Primux Trading, S.L. "^probox2,.*": description: PROBOX2 (by W2COMP Co., Ltd.) + "^pri,.*": + description: Priva "^prt,.*": description: Protonic Holland "^pulsedlight,.*": @@ -1267,7 +1277,7 @@ patternProperties: "^riscv,.*": description: RISC-V Foundation "^rockchip,.*": - description: Fuzhou Rockchip Electronics Co., Ltd + description: Rockchip Electronics Co., Ltd. "^rocktech,.*": description: ROCKTECH DISPLAYS LIMITED "^rohm,.*": @@ -1737,6 +1747,8 @@ patternProperties: description: Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. "^ysoft,.*": description: Y Soft Corporation a.s. + "^yuridenki,.*": + description: Yuridenki-Shokai Co. Ltd. "^zarlink,.*": description: Zarlink Semiconductor "^zealz,.*": 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/firmware/firmware-usage-guidelines.rst b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst index fdcfce42c6d2..336e912281c3 100644 --- a/Documentation/driver-api/firmware/firmware-usage-guidelines.rst +++ b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst @@ -42,3 +42,8 @@ then of course these rules will not apply strictly.) deprecating old major versions, then this should only be done as a last option, and be stated clearly in all communications. +* Firmware files that affect the User API (UAPI) shall not introduce + changes that break existing userspace programs. Updates to such firmware + must ensure backward compatibility with existing userspace applications. + This includes maintaining consistent interfaces and behaviors that + userspace programs rely on. diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst index 71ccc30e586b..e826f16ea43d 100644 --- a/Documentation/driver-api/generic-counter.rst +++ b/Documentation/driver-api/generic-counter.rst @@ -467,7 +467,7 @@ Counter sysfs Translates counter data to the standard Counter sysfs interface format and vice versa. -Please refer to the ``Documentation/ABI/testing/sysfs-bus-counter`` file +Please refer to the Documentation/ABI/testing/sysfs-bus-counter file for a detailed breakdown of the available Generic Counter interface sysfs attributes. @@ -483,7 +483,7 @@ Sysfs Interface Several sysfs attributes are generated by the Generic Counter interface, and reside under the ``/sys/bus/counter/devices/counterX`` directory, where ``X`` is to the respective counter device id. Please see -``Documentation/ABI/testing/sysfs-bus-counter`` for detailed information +Documentation/ABI/testing/sysfs-bus-counter for detailed information on each Generic Counter interface sysfs attribute. Through these sysfs attributes, programs and scripts may interact with diff --git a/Documentation/driver-api/iio/core.rst b/Documentation/driver-api/iio/core.rst index dfe438dc91a7..42b580fb2989 100644 --- a/Documentation/driver-api/iio/core.rst +++ b/Documentation/driver-api/iio/core.rst @@ -60,7 +60,7 @@ directory. Common attributes are: * :file:`sampling_frequency_available`, available discrete set of sampling frequency values for device. * Available standard attributes for IIO devices are described in the - :file:`Documentation/ABI/testing/sysfs-bus-iio` file in the Linux kernel + :file:Documentation/ABI/testing/sysfs-bus-iio file in the Linux kernel sources. IIO device channels diff --git a/Documentation/driver-api/infiniband.rst b/Documentation/driver-api/infiniband.rst index 30e142ccbee9..10d8be9e74fe 100644 --- a/Documentation/driver-api/infiniband.rst +++ b/Documentation/driver-api/infiniband.rst @@ -77,14 +77,14 @@ iSCSI Extensions for RDMA (iSER) :internal: .. kernel-doc:: drivers/infiniband/ulp/iser/iscsi_iser.c - :functions: iscsi_iser_pdu_alloc iser_initialize_task_headers \ - iscsi_iser_task_init iscsi_iser_mtask_xmit iscsi_iser_task_xmit \ - iscsi_iser_cleanup_task iscsi_iser_check_protection \ - iscsi_iser_conn_create iscsi_iser_conn_bind \ - iscsi_iser_conn_start iscsi_iser_conn_stop \ - iscsi_iser_session_destroy iscsi_iser_session_create \ - iscsi_iser_set_param iscsi_iser_ep_connect iscsi_iser_ep_poll \ - iscsi_iser_ep_disconnect + :functions: iscsi_iser_pdu_alloc iser_initialize_task_headers + iscsi_iser_task_init iscsi_iser_mtask_xmit iscsi_iser_task_xmit + iscsi_iser_cleanup_task iscsi_iser_check_protection + iscsi_iser_conn_create iscsi_iser_conn_bind + iscsi_iser_conn_start iscsi_iser_conn_stop + iscsi_iser_session_destroy iscsi_iser_session_create + iscsi_iser_set_param iscsi_iser_ep_connect iscsi_iser_ep_poll + iscsi_iser_ep_disconnect .. kernel-doc:: drivers/infiniband/ulp/iser/iser_initiator.c :internal: diff --git a/Documentation/driver-api/infrastructure.rst b/Documentation/driver-api/infrastructure.rst index 3d52dfdfa9fd..35e36fee4238 100644 --- a/Documentation/driver-api/infrastructure.rst +++ b/Documentation/driver-api/infrastructure.rst @@ -41,6 +41,12 @@ Device Drivers Base .. kernel-doc:: drivers/base/class.c :export: +.. kernel-doc:: include/linux/device/faux.h + :internal: + +.. kernel-doc:: drivers/base/faux.c + :export: + .. kernel-doc:: drivers/base/node.c :internal: diff --git a/Documentation/driver-api/media/drivers/zoran.rst b/Documentation/driver-api/media/drivers/zoran.rst index b205e10c3154..3e05b7f0442a 100644 --- a/Documentation/driver-api/media/drivers/zoran.rst +++ b/Documentation/driver-api/media/drivers/zoran.rst @@ -222,7 +222,7 @@ The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong, Ireland, Nigeria, South Africa. The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate, -and is used in Argentinia, Uruguay, an a few others +and is used in Argentina, Uruguay, an a few others We do not talk about how the audio is broadcast ! diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst index ffc712a5f632..ad96a89ee916 100644 --- a/Documentation/driver-api/media/maintainer-entry-profile.rst +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst @@ -116,7 +116,7 @@ CEC drivers ``cec-compliance`` .. [3] The ``v4l2-compliance`` also covers the media controller usage inside V4L2 drivers. -Other compilance tools are under development to check other parts of the +Other compliance tools are under development to check other parts of the subsystem. Those tests need to pass before the patches go upstream. diff --git a/Documentation/driver-api/media/tx-rx.rst b/Documentation/driver-api/media/tx-rx.rst index c71003f74b1c..0b8c9cde8ee4 100644 --- a/Documentation/driver-api/media/tx-rx.rst +++ b/Documentation/driver-api/media/tx-rx.rst @@ -49,6 +49,13 @@ Link frequency The :ref:`V4L2_CID_LINK_FREQ <v4l2-cid-link-freq>` control is used to tell the receiver the frequency of the bus (i.e. it is not the same as the symbol rate). +Drivers that do not have user-configurable link frequency should report it +through the ``.get_mbus_config()`` subdev pad operation, in the ``link_freq`` +field of struct v4l2_mbus_config, instead of through controls. + +Receiver drivers should use :c:func:`v4l2_get_link_freq` helper to obtain the +link frequency from the transmitter sub-device. + ``.enable_streams()`` and ``.disable_streams()`` callbacks ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -58,6 +65,15 @@ to control the transmitter driver's streaming state. These callbacks may not be called directly, but by using ``v4l2_subdev_enable_streams()`` and ``v4l2_subdev_disable_streams()``. +Stopping the transmitter +^^^^^^^^^^^^^^^^^^^^^^^^ + +A transmitter stops sending the stream of images as a result of +calling the ``.disable_streams()`` callback. Some transmitters may stop the +stream at a frame boundary whereas others stop immediately, +effectively leaving the current frame unfinished. The receiver driver +should not make assumptions either way, but function properly in both +cases. CSI-2 transmitter drivers ------------------------- @@ -126,13 +142,3 @@ device, so this should be only done when it is needed. Receiver drivers that do not need explicit LP-11 or LP-111 state setup are waived from calling the two callbacks. - -Stopping the transmitter -^^^^^^^^^^^^^^^^^^^^^^^^ - -A transmitter stops sending the stream of images as a result of -calling the ``.disable_streams()`` callback. Some transmitters may stop the -stream at a frame boundary whereas others stop immediately, -effectively leaving the current frame unfinished. The receiver driver -should not make assumptions either way, but function properly in both -cases. diff --git a/Documentation/driver-api/nvdimm/nvdimm.rst b/Documentation/driver-api/nvdimm/nvdimm.rst index ca16b5acbf30..c205efa4d45b 100644 --- a/Documentation/driver-api/nvdimm/nvdimm.rst +++ b/Documentation/driver-api/nvdimm/nvdimm.rst @@ -535,12 +535,12 @@ internally with a static identifier:: char devname[50]; snprintf(devname, sizeof(devname), "namespace%d.%d", - ndctl_region_get_id(region), paramaters->id); + ndctl_region_get_id(region), parameters->id); ndctl_namespace_set_alt_name(ndns, devname); /* 'uuid' must be set prior to setting size! */ - ndctl_namespace_set_uuid(ndns, paramaters->uuid); - ndctl_namespace_set_size(ndns, paramaters->size); + ndctl_namespace_set_uuid(ndns, parameters->uuid); + ndctl_namespace_set_size(ndns, parameters->size); /* unlike pmem namespaces, blk namespaces have a sector size */ if (parameters->lbasize) ndctl_namespace_set_sector_size(ndns, parameters->lbasize); 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/pm/devices.rst b/Documentation/driver-api/pm/devices.rst index d448cb57df86..8d86d5da4023 100644 --- a/Documentation/driver-api/pm/devices.rst +++ b/Documentation/driver-api/pm/devices.rst @@ -358,7 +358,7 @@ the phases are: ``prepare``, ``suspend``, ``suspend_late``, ``suspend_noirq``. is probed against the device in question by passing them to the :c:func:`dev_pm_set_driver_flags` helper function.] If the first of these flags is set, the PM core will not apply the direct-complete - procedure described above to the given device and, consequenty, to any + procedure described above to the given device and, consequently, to any of its ancestors. The second flag, when set, informs the middle layer code (bus types, device types, PM domains, classes) that it should take the return value of the ``->prepare`` callback provided by the driver 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/edac/features.rst b/Documentation/edac/features.rst new file mode 100644 index 000000000000..3f283de297c7 --- /dev/null +++ b/Documentation/edac/features.rst @@ -0,0 +1,103 @@ +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-no-invariants-or-later + +================= +EDAC/RAS features +================= + +Copyright (c) 2024-2025 HiSilicon Limited. + +:Author: Shiju Jose <shiju.jose@huawei.com> +:License: The GNU Free Documentation License, Version 1.2 without + Invariant Sections, Front-Cover Texts nor Back-Cover Texts. + (dual licensed under the GPL v2) + +- Written for: 6.15 + +Introduction +------------ + +EDAC/RAS components plugging and high-level design: + +1. Scrub control + +2. Error Check Scrub (ECS) control + +3. ACPI RAS2 features + +4. Post Package Repair (PPR) control + +5. Memory Sparing Repair control + +High level design is illustrated in the following diagram:: + + +-----------------------------------------------+ + | Userspace - Rasdaemon | + | +-------------+ | + | | RAS CXL mem | +---------------+ | + | |error handler|---->| | | + | +-------------+ | RAS dynamic | | + | +-------------+ | scrub, memory | | + | | RAS memory |---->| repair control| | + | |error handler| +----|----------+ | + | +-------------+ | | + +--------------------------|--------------------+ + | + | + +-------------------------------|------------------------------+ + | Kernel EDAC extension for | controlling RAS Features | + |+------------------------------|----------------------------+ | + || EDAC Core Sysfs EDAC| Bus | | + || +--------------------------|---------------------------+| | + || |/sys/bus/edac/devices/<dev>/scrubX/ | | EDAC device || | + || |/sys/bus/edac/devices/<dev>/ecsX/ |<->| EDAC MC || | + || |/sys/bus/edac/devices/<dev>/repairX | | EDAC sysfs || | + || +---------------------------|--------------------------+| | + || EDAC|Bus | | + || | | | + || +----------+ Get feature | Get feature | | + || | | desc +---------|------+ desc +----------+ | | + || |EDAC scrub|<-----| EDAC device | | | | | + || +----------+ | driver- RAS |----->| EDAC mem | | | + || +----------+ | feature control| | repair | | | + || | |<-----| | +----------+ | | + || |EDAC ECS | +---------|------+ | | + || +----------+ Register RAS|features | | + || ______________________|_____________ | | + |+---------|---------------|------------------|--------------+ | + | +-------|----+ +-------|-------+ +----|----------+ | + | | | | CXL mem driver| | Client driver | | + | | ACPI RAS2 | | scrub, ECS, | | memory repair | | + | | driver | | sparing, PPR | | features | | + | +-----|------+ +-------|-------+ +------|--------+ | + | | | | | + +--------|-----------------|--------------------|--------------+ + | | | + +--------|-----------------|--------------------|--------------+ + | +---|-----------------|--------------------|-------+ | + | | | | + | | Platform HW and Firmware | | + | +--------------------------------------------------+ | + +--------------------------------------------------------------+ + + +1. EDAC Features components - Create feature-specific descriptors. For + example: scrub, ECS, memory repair in the above diagram. + +2. EDAC device driver for controlling RAS Features - Get feature's attribute + descriptors from EDAC RAS feature component and registers device's RAS + features with EDAC bus and expose the features control attributes via + sysfs. For example, /sys/bus/edac/devices/<dev-name>/<feature>X/ + +3. RAS dynamic feature controller - Userspace sample modules in rasdaemon for + dynamic scrub/repair control to issue scrubbing/repair when excess number + of corrected memory errors are reported in a short span of time. + +RAS features +------------ +1. Memory Scrub + +Memory scrub features are documented in `Documentation/edac/scrub.rst`. + +2. Memory Repair + +Memory repair features are documented in `Documentation/edac/memory_repair.rst`. diff --git a/Documentation/edac/index.rst b/Documentation/edac/index.rst new file mode 100644 index 000000000000..420c6601dbae --- /dev/null +++ b/Documentation/edac/index.rst @@ -0,0 +1,12 @@ +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-no-invariants-or-later + +============== +EDAC Subsystem +============== + +.. toctree:: + :maxdepth: 1 + + features + memory_repair + scrub diff --git a/Documentation/edac/memory_repair.rst b/Documentation/edac/memory_repair.rst new file mode 100644 index 000000000000..52162a422864 --- /dev/null +++ b/Documentation/edac/memory_repair.rst @@ -0,0 +1,121 @@ +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-no-invariants-or-later + +========================== +EDAC Memory Repair Control +========================== + +Copyright (c) 2024-2025 HiSilicon Limited. + +:Author: Shiju Jose <shiju.jose@huawei.com> +:License: The GNU Free Documentation License, Version 1.2 without + Invariant Sections, Front-Cover Texts nor Back-Cover Texts. + (dual licensed under the GPL v2) +:Original Reviewers: + +- Written for: 6.15 + +Introduction +------------ + +Some memory devices support repair operations to address issues in their +memory media. Post Package Repair (PPR) and memory sparing are examples of +such features. + +Post Package Repair (PPR) +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Post Package Repair is a maintenance operation which requests the memory +device to perform repair operation on its media. It is a memory self-healing +feature that fixes a failing memory location by replacing it with a spare row +in a DRAM device. + +For example, a CXL memory device with DRAM components that support PPR +features implements maintenance operations. DRAM components support those +types of PPR functions: + + - hard PPR, for a permanent row repair, and + - soft PPR, for a temporary row repair. + +Soft PPR is much faster than hard PPR, but the repair is lost after a power +cycle. + +The data may not be retained and memory requests may not be correctly +processed during a repair operation. In such case, the repair operation should +not be executed at runtime. + +For example, for CXL memory devices, see CXL spec rev 3.1 [1]_ sections +8.2.9.7.1.1 PPR Maintenance Operations, 8.2.9.7.1.2 sPPR Maintenance Operation +and 8.2.9.7.1.3 hPPR Maintenance Operation for more details. + +Memory Sparing +~~~~~~~~~~~~~~ + +Memory sparing is a repair function that replaces a portion of memory with +a portion of functional memory at a particular granularity. Memory +sparing has cacheline/row/bank/rank sparing granularities. For example, in +rank memory-sparing mode, one memory rank serves as a spare for other ranks on +the same channel in case they fail. + +The spare rank is held in reserve and not used as active memory until +a failure is indicated, with reserved capacity subtracted from the total +available memory in the system. + +After an error threshold is surpassed in a system protected by memory sparing, +the content of a failing rank of DIMMs is copied to the spare rank. The +failing rank is then taken offline and the spare rank placed online for use as +active memory in place of the failed rank. + +For example, CXL memory devices can support various subclasses for sparing +operation vary in terms of the scope of the sparing being performed. + +Cacheline sparing subclass refers to a sparing action that can replace a full +cacheline. Row sparing is provided as an alternative to PPR sparing functions +and its scope is that of a single DDR row. Bank sparing allows an entire bank +to be replaced. Rank sparing is defined as an operation in which an entire DDR +rank is replaced. + +See CXL spec 3.1 [1]_ section 8.2.9.7.1.4 Memory Sparing Maintenance +Operations for more details. + +.. [1] https://computeexpresslink.org/cxl-specification/ + +Use cases of generic memory repair features control +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +1. The soft PPR, hard PPR and memory-sparing features share similar control + attributes. Therefore, there is a need for a standardized, generic sysfs + repair control that is exposed to userspace and used by administrators, + scripts and tools. + +2. When a CXL device detects an error in a memory component, it informs the + host of the need for a repair maintenance operation by using an event + record where the "maintenance needed" flag is set. The event record + specifies the device physical address (DPA) and attributes of the memory + that requires repair. The kernel reports the corresponding CXL general + media or DRAM trace event to userspace, and userspace tools (e.g. + rasdaemon) initiate a repair maintenance operation in response to the + device request using the sysfs repair control. + +3. Userspace tools, such as rasdaemon, request a repair operation on a memory + region when maintenance need flag set or an uncorrected memory error or + excess of corrected memory errors above a threshold value is reported or an + exceed corrected errors threshold flag set for that memory. + +4. Multiple PPR/sparing instances may be present per memory device. + +5. Drivers should enforce that live repair is safe. In systems where memory + mapping functions can change between boots, one approach to this is to log + memory errors seen on this boot against which to check live memory repair + requests. + +The File System +--------------- + +The control attributes of a registered memory repair instance could be +accessed in the /sys/bus/edac/devices/<dev-name>/mem_repairX/ + +sysfs +----- + +Sysfs files are documented in +`Documentation/ABI/testing/sysfs-edac-memory-repair`. diff --git a/Documentation/edac/scrub.rst b/Documentation/edac/scrub.rst new file mode 100644 index 000000000000..daab929cdba1 --- /dev/null +++ b/Documentation/edac/scrub.rst @@ -0,0 +1,266 @@ +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-no-invariants-or-later + +============= +Scrub Control +============= + +Copyright (c) 2024-2025 HiSilicon Limited. + +:Author: Shiju Jose <shiju.jose@huawei.com> +:License: The GNU Free Documentation License, Version 1.2 without + Invariant Sections, Front-Cover Texts nor Back-Cover Texts. + (dual licensed under the GPL v2) + +- Written for: 6.15 + +Introduction +------------ + +Increasing DRAM size and cost have made memory subsystem reliability an +important concern. These modules are used where potentially corrupted data +could cause expensive or fatal issues. Memory errors are among the top +hardware failures that cause server and workload crashes. + +Memory scrubbing is a feature where an ECC (Error-Correcting Code) engine +reads data from each memory media location, corrects if necessary and writes +the corrected data back to the same memory media location. + +DIMMs can be scrubbed at a configurable rate to detect uncorrected memory +errors and attempt recovery from detected errors, providing the following +benefits: + +1. Proactively scrubbing DIMMs reduces the chance of a correctable error + becoming uncorrectable. + +2. When detected, uncorrected errors caught in unallocated memory pages are + isolated and prevented from being allocated to an application or the OS. + +3. This reduces the likelihood of software or hardware products encountering + memory errors. + +4. The additional data on failures in memory may be used to build up + statistics that are later used to decide whether to use memory repair + technologies such as Post Package Repair or Sparing. + +There are 2 types of memory scrubbing: + +1. Background (patrol) scrubbing while the DRAM is otherwise idle. + +2. On-demand scrubbing for a specific address range or region of memory. + +Several types of interfaces to hardware memory scrubbers have been +identified, such as CXL memory device patrol scrub, CXL DDR5 ECS, ACPI +RAS2 memory scrubbing, and ACPI NVDIMM ARS (Address Range Scrub). + +The control mechanisms vary across different memory scrubbers. To enable +standardized userspace tooling, there is a need to present these controls +through a standardized ABI. + +A generic memory EDAC scrub control allows users to manage underlying +scrubbers in the system through a standardized sysfs control interface. It +abstracts the management of various scrubbing functionalities into a unified +set of functions. + +Use cases of common scrub control feature +----------------------------------------- + +1. Several types of interfaces for hardware memory scrubbers have been + identified, including the CXL memory device patrol scrub, CXL DDR5 ECS, + ACPI RAS2 memory scrubbing features, ACPI NVDIMM ARS (Address Range Scrub), + and software-based memory scrubbers. + + Of the identified interfaces to hardware memory scrubbers some support + control over patrol (background) scrubbing (e.g., ACPI RAS2, CXL) and/or + on-demand scrubbing (e.g., ACPI RAS2, ACPI ARS). However, the scrub control + interfaces vary between memory scrubbers, highlighting the need for + a standardized, generic sysfs scrub control interface that is accessible to + userspace for administration and use by scripts/tools. + +2. User-space scrub controls allow users to disable scrubbing if necessary, + for example, to disable background patrol scrubbing or adjust the scrub + rate for performance-aware operations where background activities need to + be minimized or disabled. + +3. User-space tools enable on-demand scrubbing for specific address ranges, + provided that the scrubber supports this functionality. + +4. User-space tools can also control memory DIMM scrubbing at a configurable + scrub rate via sysfs scrub controls. This approach offers several benefits: + + 4.1. Detects uncorrectable memory errors early, before user access to affected + memory, helping facilitate recovery. + + 4.2. Reduces the likelihood of correctable errors developing into uncorrectable + errors. + +5. Policy control for hotplugged memory is necessary because there may not + be a system-wide BIOS or similar control to manage scrub settings for a CXL + device added after boot. Determining these settings is a policy decision, + balancing reliability against performance, so userspace should control it. + Therefore, a unified interface is recommended for handling this function in + a way that aligns with other similar interfaces, rather than creating a + separate one. + +Scrubbing features +------------------ + +CXL Memory Scrubbing features +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +CXL spec r3.1 [1]_ section 8.2.9.9.11.1 describes the memory device patrol +scrub control feature. The device patrol scrub proactively locates and makes +corrections to errors in regular cycle. The patrol scrub control allows the +userspace request to change CXL patrol scrubber's configurations. + +The patrol scrub control allows the requester to specify the number of +hours in which the patrol scrub cycles must be completed, provided that +the requested scrub rate must be within the supported range of the +scrub rate that the device is capable of. In the CXL driver, the +number of seconds per scrub cycles, which user requests via sysfs, is +rescaled to hours per scrub cycles. + +In addition, they allow the host to disable the feature in case it interferes +with performance-aware operations which require the background operations to +be turned off. + +Error Check Scrub (ECS) +~~~~~~~~~~~~~~~~~~~~~~~ + +CXL spec r3.1 [1]_ section 8.2.9.9.11.2 describes Error Check Scrub (ECS) +- a feature defined in the JEDEC DDR5 SDRAM Specification (JESD79-5) and +allowing DRAM to internally read, correct single-bit errors, and write back +corrected data bits to the DRAM array while providing transparency to error +counts. + +The DDR5 device contains number of memory media Field Replaceable Units (FRU) +per device. The DDR5 ECS feature and thus the ECS control driver supports +configuring the ECS parameters per FRU. + +ACPI RAS2 Hardware-based Memory Scrubbing +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +ACPI spec 6.5 [2]_ section 5.2.21 ACPI RAS2 describes an ACPI RAS2 table +which provides interfaces for platform RAS features and supports independent +RAS controls and capabilities for a given RAS feature for multiple instances +of the same component in a given system. + +Memory RAS features apply to RAS capabilities, controls and operations that +are specific to memory. RAS2 PCC sub-spaces for memory-specific RAS features +have a Feature Type of 0x00 (Memory). + +The platform can use the hardware-based memory scrubbing feature to expose +controls and capabilities associated with hardware-based memory scrub +engines. The RAS2 memory scrubbing feature supports as per spec, + +1. Independent memory scrubbing controls for each NUMA domain, identified + using its proximity domain. + +2. Provision for background (patrol) scrubbing of the entire memory system, + as well as on-demand scrubbing for a specific region of memory. + +ACPI Address Range Scrubbing (ARS) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +ACPI spec 6.5 [2]_ section 9.19.7.2 describes Address Range Scrubbing (ARS). +ARS allows the platform to communicate memory errors to system software. +This capability allows system software to prevent accesses to addresses with +uncorrectable errors in memory. ARS functions manage all NVDIMMs present in +the system. Only one scrub can be in progress system wide at any given time. + +The following functions are supported as per the specification: + +1. Query ARS Capabilities for a given address range, indicates platform + supports the ACPI NVDIMM Root Device Unconsumed Error Notification. + +2. Start ARS triggers an Address Range Scrub for the given memory range. + Address scrubbing can be done for volatile or persistent memory, or both. + +3. Query ARS Status command allows software to get the status of ARS, + including the progress of ARS and ARS error record. + +4. Clear Uncorrectable Error. + +5. Translate SPA + +6. ARS Error Inject etc. + +The kernel supports an existing control for ARS and ARS is currently not +supported in EDAC. + +.. [1] https://computeexpresslink.org/cxl-specification/ + +.. [2] https://uefi.org/specs/ACPI/6.5/ + +Comparison of various scrubbing features +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +--------------+-----------+-----------+-----------+-----------+ + | | ACPI | CXL patrol| CXL ECS | ARS | + | Name | RAS2 | scrub | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | On-demand | Supported | No | No | Supported | + | Scrubbing | | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Background | Supported | Supported | Supported | No | + | scrubbing | | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Mode of | Scrub ctrl| per device| per memory| Unknown | + | scrubbing | per NUMA | | media | | + | | domain. | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Query scrub | Supported | Supported | Supported | Supported | + | capabilities | | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Setting | Supported | No | No | Supported | + | address range| | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Setting | Supported | Supported | No | No | + | scrub rate | | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Unit for | Not | in hours | No | No | + | scrub rate | Defined | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + | | Supported | | | | + | Scrub | on-demand | No | No | Supported | + | status/ | scrubbing | | | | + | Completion | only | | | | + +--------------+-----------+-----------+-----------+-----------+ + | UC error | |CXL general|CXL general| ACPI UCE | + | reporting | Exception |media/DRAM |media/DRAM | notify and| + | | |event/media|event/media| query | + | | |scan? |scan? | ARS status| + +--------------+-----------+-----------+-----------+-----------+ + | | | | | | + | Support for | Supported | Supported | Supported | No | + | EDAC control | | | | | + | | | | | | + +--------------+-----------+-----------+-----------+-----------+ + +The File System +--------------- + +The control attributes of a registered scrubber instance could be +accessed in: + +/sys/bus/edac/devices/<dev-name>/scrubX/ + +sysfs +----- + +Sysfs files are documented in +`Documentation/ABI/testing/sysfs-edac-scrub` + +`Documentation/ABI/testing/sysfs-edac-ecs` 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/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt index 02febc883588..d937b7a03575 100644 --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt @@ -20,7 +20,7 @@ | openrisc: | TODO | | parisc: | ok | | powerpc: | ok | - | riscv: | ok | + | riscv: | TODO | | s390: | ok | | sh: | TODO | | sparc: | TODO | diff --git a/Documentation/features/list-arch.sh b/Documentation/features/list-arch.sh index e73aa35848f0..ac8ff7f6f859 100755 --- a/Documentation/features/list-arch.sh +++ b/Documentation/features/list-arch.sh @@ -6,6 +6,6 @@ # (If no arguments are given then it will print the host architecture's status.) # -ARCH=${1:-$(uname -m | sed 's/x86_64/x86/' | sed 's/i386/x86/')} +ARCH=${1:-$(uname -m | sed 's/x86_64/x86/' | sed 's/i386/x86/' | sed 's/s390x/s390/')} $(dirname $0)/../../scripts/get_feat.pl list --arch $ARCH diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/9p.rst index 2bbf68b56b0d..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 @@ -90,7 +90,7 @@ Just start the 9pfs capable network server like diod/nfs-ganesha e.g.:: $ diod -f -n -d 0 -S -l 0.0.0.0:9999 -e $PWD -Optionaly scan your bus if there are more then one usbg gadgets to find their path:: +Optionally scan your bus if there are more then one usbg gadgets to find their path:: $ python $kernel_dir/tools/usb/p9_fwd.py list @@ -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/bcachefs/SubmittingPatches.rst b/Documentation/filesystems/bcachefs/SubmittingPatches.rst new file mode 100644 index 000000000000..18c79d548391 --- /dev/null +++ b/Documentation/filesystems/bcachefs/SubmittingPatches.rst @@ -0,0 +1,105 @@ +Submitting patches to bcachefs +============================== + +Here are suggestions for submitting patches to bcachefs subsystem. + +Submission checklist +-------------------- + +Patches must be tested before being submitted, either with the xfstests suite +[0]_, or the full bcachefs test suite in ktest [1]_, depending on what's being +touched. Note that ktest wraps xfstests and will be an easier method to running +it for most users; it includes single-command wrappers for all the mainstream +in-kernel local filesystems. + +Patches will undergo more testing after being merged (including +lockdep/kasan/preempt/etc. variants), these are not generally required to be +run by the submitter - but do put some thought into what you're changing and +which tests might be relevant, e.g. are you dealing with tricky memory layout +work? kasan, are you doing locking work? then lockdep; and ktest includes +single-command variants for the debug build types you'll most likely need. + +The exception to this rule is incomplete WIP/RFC patches: if you're working on +something nontrivial, it's encouraged to send out a WIP patch to let people +know what you're doing and make sure you're on the right track. Just make sure +it includes a brief note as to what's done and what's incomplete, to avoid +confusion. + +Rigorous checkpatch.pl adherence is not required (many of its warnings are +considered out of date), but try not to deviate too much without reason. + +Focus on writing code that reads well and is organized well; code should be +aesthetically pleasing. + +CI +-- + +Instead of running your tests locally, when running the full test suite it's +preferable to let a server farm do it in parallel, and then have the results +in a nice test dashboard (which can tell you which failures are new, and +presents results in a git log view, avoiding the need for most bisecting). + +That exists [2]_, and community members may request an account. If you work for +a big tech company, you'll need to help out with server costs to get access - +but the CI is not restricted to running bcachefs tests: it runs any ktest test +(which generally makes it easy to wrap other tests that can run in qemu). + +Other things to think about +--------------------------- + +- How will we debug this code? Is there sufficient introspection to diagnose + when something starts acting wonky on a user machine? + + We don't necessarily need every single field of every data structure visible + with introspection, but having the important fields of all the core data + types wired up makes debugging drastically easier - a bit of thoughtful + foresight greatly reduces the need to have people build custom kernels with + debug patches. + + More broadly, think about all the debug tooling that might be needed. + +- Does it make the codebase more or less of a mess? Can we also try to do some + organizing, too? + +- Do new tests need to be written? New assertions? How do we know and verify + that the code is correct, and what happens if something goes wrong? + + We don't yet have automated code coverage analysis or easy fault injection - + but for now, pretend we did and ask what they might tell us. + + Assertions are hugely important, given that we don't yet have a systems + language that can do ergonomic embedded correctness proofs. Hitting an assert + in testing is much better than wandering off into undefined behaviour la-la + land - use them. Use them judiciously, and not as a replacement for proper + error handling, but use them. + +- Does it need to be performance tested? Should we add new performance counters? + + bcachefs has a set of persistent runtime counters which can be viewed with + the 'bcachefs fs top' command; this should give users a basic idea of what + their filesystem is currently doing. If you're doing a new feature or looking + at old code, think if anything should be added. + +- If it's a new on disk format feature - have upgrades and downgrades been + tested? (Automated tests exists but aren't in the CI, due to the hassle of + disk image management; coordinate to have them run.) + +Mailing list, IRC +----------------- + +Patches should hit the list [3]_, but much discussion and code review happens +on IRC as well [4]_; many people appreciate the more conversational approach +and quicker feedback. + +Additionally, we have a lively user community doing excellent QA work, which +exists primarily on IRC. Please make use of that resource; user feedback is +important for any nontrivial feature, and documenting it in commit messages +would be a good idea. + +.. rubric:: References + +.. [0] git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git +.. [1] https://evilpiepirate.org/git/ktest.git/ +.. [2] https://evilpiepirate.org/~testdashboard/ci/ +.. [3] linux-bcachefs@vger.kernel.org +.. [4] irc.oftc.net#bcache, #bcachefs-dev diff --git a/Documentation/filesystems/bcachefs/casefolding.rst b/Documentation/filesystems/bcachefs/casefolding.rst new file mode 100644 index 000000000000..ba5de97d155f --- /dev/null +++ b/Documentation/filesystems/bcachefs/casefolding.rst @@ -0,0 +1,90 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Casefolding +=========== + +bcachefs has support for case-insensitive file and directory +lookups using the regular `chattr +F` (`S_CASEFOLD`, `FS_CASEFOLD_FL`) +casefolding attributes. + +The main usecase for casefolding is compatibility with software written +against other filesystems that rely on casefolded lookups +(eg. NTFS and Wine/Proton). +Taking advantage of file-system level casefolding can lead to great +loading time gains in many applications and games. + +Casefolding support requires a kernel with the `CONFIG_UNICODE` enabled. +Once a directory has been flagged for casefolding, a feature bit +is enabled on the superblock which marks the filesystem as using +casefolding. +When the feature bit for casefolding is enabled, it is no longer possible +to mount that filesystem on kernels without `CONFIG_UNICODE` enabled. + +On the lookup/query side: casefolding is implemented by allocating a new +string of `BCH_NAME_MAX` length using the `utf8_casefold` function to +casefold the query string. + +On the dirent side: casefolding is implemented by ensuring the `bkey`'s +hash is made from the casefolded string and storing the cached casefolded +name with the regular name in the dirent. + +The structure looks like this: + +* Regular: [dirent data][regular name][nul][nul]... +* Casefolded: [dirent data][reg len][cf len][regular name][casefolded name][nul][nul]... + +(Do note, the number of NULs here is merely for illustration; their count can +vary per-key, and they may not even be present if the key is aligned to +`sizeof(u64)`.) + +This is efficient as it means that for all file lookups that require casefolding, +it has identical performance to a regular lookup: +a hash comparison and a `memcmp` of the name. + +Rationale +--------- + +Several designs were considered for this system: +One was to introduce a dirent_v2, however that would be painful especially as +the hash system only has support for a single key type. This would also need +`BCH_NAME_MAX` to change between versions, and a new feature bit. + +Another option was to store without the two lengths, and just take the length of +the regular name and casefolded name contiguously / 2 as the length. This would +assume that the regular length == casefolded length, but that could potentially +not be true, if the uppercase unicode glyph had a different UTF-8 encoding than +the lowercase unicode glyph. +It would be possible to disregard the casefold cache for those cases, but it was +decided to simply encode the two string lengths in the key to avoid random +performance issues if this edgecase was ever hit. + +The option settled on was to use a free-bit in d_type to mark a dirent as having +a casefold cache, and then treat the first 4 bytes the name block as lengths. +You can see this in the `d_cf_name_block` member of union in `bch_dirent`. + +The feature bit was used to allow casefolding support to be enabled for the majority +of users, but some allow users who have no need for the feature to still use bcachefs as +`CONFIG_UNICODE` can increase the kernel side a significant amount due to the tables used, +which may be decider between using bcachefs for eg. embedded platforms. + +Other filesystems like ext4 and f2fs have a super-block level option for casefolding +encoding, but bcachefs currently does not provide this. ext4 and f2fs do not expose +any encodings than a single UTF-8 version. When future encodings are desirable, +they will be added trivially using the opts mechanism. + +dentry/dcache considerations +---------------------------- + +Currently, in casefolded directories, bcachefs (like other filesystems) will not cache +negative dentry's. + +This is because currently doing so presents a problem in the following scenario: + + - Lookup file "blAH" in a casefolded directory + - Creation of file "BLAH" in a casefolded directory + - Lookup file "blAH" in a casefolded directory + +This would fail if negative dentry's were cached. + +This is slightly suboptimal, but could be fixed in future with some vfs work. + diff --git a/Documentation/filesystems/bcachefs/index.rst b/Documentation/filesystems/bcachefs/index.rst index 95fc4b90739e..3864d0ae89c1 100644 --- a/Documentation/filesystems/bcachefs/index.rst +++ b/Documentation/filesystems/bcachefs/index.rst @@ -4,9 +4,28 @@ bcachefs Documentation ====================== +Subsystem-specific development process notes +-------------------------------------------- + +Development notes specific to bcachefs. These are intended to supplement +:doc:`general kernel development handbook </process/index>`. + .. toctree:: - :maxdepth: 2 + :maxdepth: 1 :numbered: CodingStyle + SubmittingPatches + +Filesystem implementation +------------------------- + +Documentation for filesystem features and their implementation details. +At this moment, only a few of these are described here. + +.. toctree:: + :maxdepth: 1 + :numbered: + + casefolding errorcodes diff --git a/Documentation/filesystems/coda.rst b/Documentation/filesystems/coda.rst index bdde7e4e010b..0db3c83a50e5 100644 --- a/Documentation/filesystems/coda.rst +++ b/Documentation/filesystems/coda.rst @@ -141,7 +141,7 @@ kernel support. a process P which accessing a Coda file. It makes a system call which traps to the OS kernel. Examples of such calls trapping to the kernel are ``read``, ``write``, ``open``, ``close``, ``create``, ``mkdir``, - ``rmdir``, ``chmod`` in a Unix ontext. Similar calls exist in the Win32 + ``rmdir``, ``chmod`` in a Unix context. Similar calls exist in the Win32 environment, and are named ``CreateFile``. Generally the operating system handles the request in a virtual 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/debugfs.rst b/Documentation/filesystems/debugfs.rst index f7f977ffbf8d..610f718ef8b5 100644 --- a/Documentation/filesystems/debugfs.rst +++ b/Documentation/filesystems/debugfs.rst @@ -220,7 +220,7 @@ There are a couple of other directory-oriented helper functions:: A call to debugfs_change_name() will give a new name to an existing debugfs file, always in the same directory. The new_name must not exist prior -to the call; the return value is 0 on success and -E... on failuer. +to the call; the return value is 0 on success and -E... on failure. Symbolic links can be created with debugfs_create_symlink(). There is one important thing that all debugfs users must take into account: diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index fb7d2ee022bc..e15c4275862a 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -206,6 +206,7 @@ fault_type=%d Support configuring fault injection type, should be FAULT_BLKADDR_VALIDITY 0x000040000 FAULT_BLKADDR_CONSISTENCE 0x000080000 FAULT_NO_SEGMENT 0x000100000 + FAULT_INCONSISTENT_FOOTER 0x000200000 =========================== =========== mode=%s Control block allocation mode which supports "adaptive" and "lfs". In "lfs" mode, there should be no random @@ -365,6 +366,8 @@ errors=%s Specify f2fs behavior on critical errors. This supports modes: pending node write drop keep N/A pending meta write keep keep N/A ====================== =============== =============== ======== +nat_bits Enable nat_bits feature to enhance full/empty nat blocks access, + by default it's disabled. ======================== ============================================================ Debugfs Entries diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 04eaab01314b..e80329908549 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -137,9 +137,8 @@ However, these ioctls have some limitations: - In general, decrypted contents and filenames in the kernel VFS caches are freed but not wiped. Therefore, portions thereof may be recoverable from freed memory, even after the corresponding key(s) - were wiped. To partially solve this, you can set - CONFIG_PAGE_POISONING=y in your kernel config and add page_poison=1 - to your kernel command line. However, this has a performance cost. + were wiped. To partially solve this, you can add init_on_free=1 to + your kernel command line. However, this has a performance cost. - Secret keys might still exist in CPU registers, in crypto accelerator hardware (if used by the crypto API to implement any of @@ -428,11 +427,8 @@ API, but the filenames mode still does. - Mandatory: - CONFIG_CRYPTO_ADIANTUM - Recommended: - - arm32: CONFIG_CRYPTO_CHACHA20_NEON - arm32: CONFIG_CRYPTO_NHPOLY1305_NEON - - arm64: CONFIG_CRYPTO_CHACHA20_NEON - arm64: CONFIG_CRYPTO_NHPOLY1305_NEON - - x86: CONFIG_CRYPTO_CHACHA20_X86_64 - x86: CONFIG_CRYPTO_NHPOLY1305_SSE2 - x86: CONFIG_CRYPTO_NHPOLY1305_AVX2 diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst index 76e538217868..dacdbc1149e6 100644 --- a/Documentation/filesystems/fsverity.rst +++ b/Documentation/filesystems/fsverity.rst @@ -248,11 +248,17 @@ FS_IOC_READ_VERITY_METADATA The FS_IOC_READ_VERITY_METADATA ioctl reads verity metadata from a verity file. This ioctl is available since Linux v5.12. -This ioctl allows writing a server program that takes a verity file -and serves it to a client program, such that the client can do its own -fs-verity compatible verification of the file. This only makes sense -if the client doesn't trust the server and if the server needs to -provide the storage for the client. +This ioctl is useful for cases where the verity verification should be +performed somewhere other than the currently running kernel. + +One example is a server program that takes a verity file and serves it +to a client program, such that the client can do its own fs-verity +compatible verification of the file. This only makes sense if the +client doesn't trust the server and if the server needs to provide the +storage for the client. + +Another example is copying verity metadata when creating filesystem +images in userspace (such as with ``mkfs.ext4 -d``). This is a fairly specialized use case, and most fs-verity users won't need this ioctl. diff --git a/Documentation/filesystems/idmappings.rst b/Documentation/filesystems/idmappings.rst index 77930c77fcfe..2a206129f828 100644 --- a/Documentation/filesystems/idmappings.rst +++ b/Documentation/filesystems/idmappings.rst @@ -63,8 +63,8 @@ what id ``k11000`` corresponds to in the second or third idmapping. The straightforward algorithm to use is to apply the inverse of the first idmapping, mapping ``k11000`` up to ``u1000``. Afterwards, we can map ``u1000`` down using either the second idmapping mapping or third idmapping mapping. The second -idmapping would map ``u1000`` down to ``21000``. The third idmapping would map -``u1000`` down to ``u31000``. +idmapping would map ``u1000`` down to ``k21000``. The third idmapping would map +``u1000`` down to ``k31000``. If we were given the same task for the following three idmappings:: diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst index 2636f2a41bd3..a9cf8e950b15 100644 --- a/Documentation/filesystems/index.rst +++ b/Documentation/filesystems/index.rst @@ -118,7 +118,6 @@ Documentation for filesystem implementations. spufs/index squashfs sysfs - sysv-fs tmpfs ubifs ubifs-authentication diff --git a/Documentation/filesystems/iomap/design.rst b/Documentation/filesystems/iomap/design.rst index b0d0188a095e..e29651a42eec 100644 --- a/Documentation/filesystems/iomap/design.rst +++ b/Documentation/filesystems/iomap/design.rst @@ -246,6 +246,10 @@ The fields are as follows: * **IOMAP_F_PRIVATE**: Starting with this value, the upper bits can be set by the filesystem for its own purposes. + * **IOMAP_F_ANON_WRITE**: Indicates that (write) I/O does not have a target + block assigned to it yet and the file system will do that in the bio + submission handler, splitting the I/O as needed. + These flags can be set by iomap itself during file operations. The filesystem should supply an ``->iomap_end`` function if it needs to observe these flags: @@ -352,6 +356,11 @@ operations: ``IOMAP_NOWAIT`` is often set on behalf of ``IOCB_NOWAIT`` or ``RWF_NOWAIT``. + * ``IOMAP_DONTCACHE`` is set when the caller wishes to perform a + buffered file I/O and would like the kernel to drop the pagecache + after the I/O completes, if it isn't already being used by another + thread. + If it is necessary to read existing file contents from a `different <https://lore.kernel.org/all/20191008071527.29304-9-hch@lst.de/>`_ device or address range on a device, the filesystem should return that diff --git a/Documentation/filesystems/iomap/operations.rst b/Documentation/filesystems/iomap/operations.rst index 2c7f5df9d8b0..3b628e370d88 100644 --- a/Documentation/filesystems/iomap/operations.rst +++ b/Documentation/filesystems/iomap/operations.rst @@ -131,6 +131,8 @@ These ``struct kiocb`` flags are significant for buffered I/O with iomap: * ``IOCB_NOWAIT``: Turns on ``IOMAP_NOWAIT``. + * ``IOCB_DONTCACHE``: Turns on ``IOMAP_DONTCACHE``. + Internal per-Folio State ------------------------ @@ -283,7 +285,7 @@ The ``ops`` structure must be specified and is as follows: struct iomap_writeback_ops { int (*map_blocks)(struct iomap_writepage_ctx *wpc, struct inode *inode, loff_t offset, unsigned len); - int (*prepare_ioend)(struct iomap_ioend *ioend, int status); + int (*submit_ioend)(struct iomap_writepage_ctx *wpc, int status); void (*discard_folio)(struct folio *folio, loff_t pos); }; @@ -306,13 +308,12 @@ The fields are as follows: purpose. This function must be supplied by the filesystem. - - ``prepare_ioend``: Enables filesystems to transform the writeback - ioend or perform any other preparatory work before the writeback I/O - is submitted. + - ``submit_ioend``: Allows the file systems to hook into writeback bio + submission. This might include pre-write space accounting updates, or installing a custom ``->bi_end_io`` function for internal purposes, such as deferring the ioend completion to a workqueue to run metadata update - transactions from process context. + transactions from process context before submitting the bio. This function is optional. - ``discard_folio``: iomap calls this function after ``->map_blocks`` @@ -341,7 +342,7 @@ This can happen in interrupt or process context, depending on the storage device. Filesystems that need to update internal bookkeeping (e.g. unwritten -extent conversions) should provide a ``->prepare_ioend`` function to +extent conversions) should provide a ``->submit_ioend`` function to set ``struct iomap_end::bio::bi_end_io`` to its own function. This function should call ``iomap_finish_ioends`` after finishing its own work (e.g. unwritten extent conversion). @@ -515,18 +516,33 @@ IOMAP_WRITE`` with any combination of the following enhancements: * ``IOMAP_ATOMIC``: This write is being issued with torn-write protection. - Only a single bio can be created for the write, and the write must - not be split into multiple I/O requests, i.e. flag REQ_ATOMIC must be - set. + Torn-write protection may be provided based on HW-offload or by a + software mechanism provided by the filesystem. + + For HW-offload based support, only a single bio can be created for the + write, and the write must not be split into multiple I/O requests, i.e. + flag REQ_ATOMIC must be set. The file range to write must be aligned to satisfy the requirements of both the filesystem and the underlying block device's atomic commit capabilities. If filesystem metadata updates are required (e.g. unwritten extent - conversion or copy on write), all updates for the entire file range + conversion or copy-on-write), all updates for the entire file range must be committed atomically as well. - Only one space mapping is allowed per untorn write. - Untorn writes must be aligned to, and must not be longer than, a - single file block. + Untorn-writes may be longer than a single file block. In all cases, + the mapping start disk block must have at least the same alignment as + the write offset. + The filesystems must set IOMAP_F_ATOMIC_BIO to inform iomap core of an + untorn-write based on HW-offload. + + For untorn-writes based on a software mechanism provided by the + filesystem, all the disk block alignment and single bio restrictions + which apply for HW-offload based untorn-writes do not apply. + The mechanism would typically be used as a fallback for when + HW-offload based untorn-writes may not be issued, e.g. the range of the + write covers multiple extents, meaning that it is not possible to issue + a single bio. + All filesystem metadata updates for the entire file range must be + committed atomically as well. Callers commonly hold ``i_rwsem`` in shared or exclusive mode before calling this function. diff --git a/Documentation/filesystems/journalling.rst b/Documentation/filesystems/journalling.rst index 0254f7d57429..863e93e623f7 100644 --- a/Documentation/filesystems/journalling.rst +++ b/Documentation/filesystems/journalling.rst @@ -111,9 +111,7 @@ a callback function when the transaction is finally committed to disk, so that you can do some of your own management. You ask the journalling layer for calling the callback by simply setting ``journal->j_commit_callback`` function pointer and that function is -called after each transaction commit. You can also use -``transaction->t_private_list`` for attaching entries to a transaction -that need processing when the transaction commits. +called after each transaction commit. JBD2 also provides a way to block all transaction updates via jbd2_journal_lock_updates() / diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index d20a32b77b60..0ec0bb6eb0fb 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -66,7 +66,7 @@ prototypes:: int (*link) (struct dentry *,struct inode *,struct dentry *); int (*unlink) (struct inode *,struct dentry *); int (*symlink) (struct mnt_idmap *, struct inode *,struct dentry *,const char *); - int (*mkdir) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t); + struct dentry *(*mkdir) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t); int (*rmdir) (struct inode *,struct dentry *); int (*mknod) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t,dev_t); int (*rename) (struct mnt_idmap *, struct inode *, struct dentry *, diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 73f0bfd7e903..3886c14f89f4 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -515,7 +515,7 @@ The methods defined in the table are: the cache to expand a request in either direction. This allows the cache to size the request appropriately for the cache granularity. - The function is passed poiners to the start and length in its parameters, + The function is passed pointers to the start and length in its parameters, plus the size of the file for reference, and adjusts the start and length appropriately. It should return one of: 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/overlayfs.rst b/Documentation/filesystems/overlayfs.rst index 6245b67ae9e0..2db379b4b31e 100644 --- a/Documentation/filesystems/overlayfs.rst +++ b/Documentation/filesystems/overlayfs.rst @@ -292,13 +292,27 @@ rename or unlink will of course be noticed and handled). Permission model ---------------- +An overlay filesystem stashes credentials that will be used when +accessing lower or upper filesystems. + +In the old mount api the credentials of the task calling mount(2) are +stashed. In the new mount api the credentials of the task creating the +superblock through FSCONFIG_CMD_CREATE command of fsconfig(2) are +stashed. + +Starting with kernel v6.15 it is possible to use the "override_creds" +mount option which will cause the credentials of the calling task to be +recorded. Note that "override_creds" is only meaningful when used with +the new mount api as the old mount api combines setting options and +superblock creation in a single mount(2) syscall. + Permission checking in the overlay filesystem follows these principles: 1) permission check SHOULD return the same result before and after copy up 2) task creating the overlay mount MUST NOT gain additional privileges - 3) non-mounting task MAY gain additional privileges through the overlay, + 3) task[*] MAY gain additional privileges through the overlay, compared to direct access on underlying lower or upper filesystems This is achieved by performing two permission checks on each access: @@ -306,7 +320,7 @@ This is achieved by performing two permission checks on each access: a) check if current task is allowed access based on local DAC (owner, group, mode and posix acl), as well as MAC checks - b) check if mounting task would be allowed real operation on lower or + b) check if stashed credentials would be allowed real operation on lower or upper layer based on underlying filesystem permissions, again including MAC checks @@ -315,10 +329,10 @@ are copied up. On the other hand it can result in server enforced permissions (used by NFS, for example) being ignored (3). Check (b) ensures that no task gains permissions to underlying layers that -the mounting task does not have (2). This also means that it is possible +the stashed credentials do not have (2). This also means that it is possible to create setups where the consistency rule (1) does not hold; normally, -however, the mounting task will have sufficient privileges to perform all -operations. +however, the stashed credentials will have sufficient privileges to +perform all operations. Another way to demonstrate this model is drawing parallels between:: diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index 1639e78e3146..767b2927c762 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -1144,7 +1144,7 @@ and it *must* be opened exclusive. --- -** mandatory** +**mandatory** ->d_revalidate() gets two extra arguments - inode of parent directory and name our dentry is expected to have. Both are stable (dir is pinned in @@ -1157,3 +1157,49 @@ in normal case it points into the pathname being looked up. NOTE: if you need something like full path from the root of filesystem, you are still on your own - this assists with simple cases, but it's not magic. + +--- + +**recommended** + +kern_path_locked() and user_path_locked() no longer return a negative +dentry so this doesn't need to be checked. If the name cannot be found, +ERR_PTR(-ENOENT) is returned. + +--- + +**recommended** + +lookup_one_qstr_excl() is changed to return errors in more cases, so +these conditions don't require explicit checks: + + - if LOOKUP_CREATE is NOT given, then the dentry won't be negative, + ERR_PTR(-ENOENT) is returned instead + - if LOOKUP_EXCL IS given, then the dentry won't be positive, + ERR_PTR(-EEXIST) is rreturned instread + +LOOKUP_EXCL now means "target must not exist". It can be combined with +LOOK_CREATE or LOOKUP_RENAME_TARGET. + +--- + +**mandatory** +invalidate_inodes() is gone use evict_inodes() instead. + +--- + +**mandatory** + +->mkdir() now returns a dentry. If the created inode is found to +already be in cache and have a dentry (often IS_ROOT()), it will need to +be spliced into the given name in place of the given dentry. That dentry +now needs to be returned. If the original dentry is used, NULL should +be returned. Any error should be returned with ERR_PTR(). + +In general, filesystems which use d_instantiate_new() to install the new +inode can safely return NULL. Filesystems which may not have an I_NEW inode +should use d_drop();d_splice_alias() and return the result of the latter. + +If a positive dentry cannot be returned for some reason, in-kernel +clients such as cachefiles, nfsd, smb/server may not perform ideally but +will fail-safe. 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/filesystems/sysv-fs.rst b/Documentation/filesystems/sysv-fs.rst deleted file mode 100644 index 89e40911ad7c..000000000000 --- a/Documentation/filesystems/sysv-fs.rst +++ /dev/null @@ -1,264 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -================== -SystemV Filesystem -================== - -It implements all of - - Xenix FS, - - SystemV/386 FS, - - Coherent FS. - -To install: - -* Answer the 'System V and Coherent filesystem support' question with 'y' - when configuring the kernel. -* To mount a disk or a partition, use:: - - mount [-r] -t sysv device mountpoint - - The file system type names:: - - -t sysv - -t xenix - -t coherent - - may be used interchangeably, but the last two will eventually disappear. - -Bugs in the present implementation: - -- Coherent FS: - - - The "free list interleave" n:m is currently ignored. - - Only file systems with no filesystem name and no pack name are recognized. - (See Coherent "man mkfs" for a description of these features.) - -- SystemV Release 2 FS: - - The superblock is only searched in the blocks 9, 15, 18, which - corresponds to the beginning of track 1 on floppy disks. No support - for this FS on hard disk yet. - - -These filesystems are rather similar. Here is a comparison with Minix FS: - -* Linux fdisk reports on partitions - - - Minix FS 0x81 Linux/Minix - - Xenix FS ?? - - SystemV FS ?? - - Coherent FS 0x08 AIX bootable - -* Size of a block or zone (data allocation unit on disk) - - - Minix FS 1024 - - Xenix FS 1024 (also 512 ??) - - SystemV FS 1024 (also 512 and 2048) - - Coherent FS 512 - -* General layout: all have one boot block, one super block and - separate areas for inodes and for directories/data. - On SystemV Release 2 FS (e.g. Microport) the first track is reserved and - all the block numbers (including the super block) are offset by one track. - -* Byte ordering of "short" (16 bit entities) on disk: - - - Minix FS little endian 0 1 - - Xenix FS little endian 0 1 - - SystemV FS little endian 0 1 - - Coherent FS little endian 0 1 - - Of course, this affects only the file system, not the data of files on it! - -* Byte ordering of "long" (32 bit entities) on disk: - - - Minix FS little endian 0 1 2 3 - - Xenix FS little endian 0 1 2 3 - - SystemV FS little endian 0 1 2 3 - - Coherent FS PDP-11 2 3 0 1 - - Of course, this affects only the file system, not the data of files on it! - -* Inode on disk: "short", 0 means non-existent, the root dir ino is: - - ================================= == - Minix FS 1 - Xenix FS, SystemV FS, Coherent FS 2 - ================================= == - -* Maximum number of hard links to a file: - - =========== ========= - Minix FS 250 - Xenix FS ?? - SystemV FS ?? - Coherent FS >=10000 - =========== ========= - -* Free inode management: - - - Minix FS - a bitmap - - Xenix FS, SystemV FS, Coherent FS - There is a cache of a certain number of free inodes in the super-block. - When it is exhausted, new free inodes are found using a linear search. - -* Free block management: - - - Minix FS - a bitmap - - Xenix FS, SystemV FS, Coherent FS - Free blocks are organized in a "free list". Maybe a misleading term, - since it is not true that every free block contains a pointer to - the next free block. Rather, the free blocks are organized in chunks - of limited size, and every now and then a free block contains pointers - to the free blocks pertaining to the next chunk; the first of these - contains pointers and so on. The list terminates with a "block number" - 0 on Xenix FS and SystemV FS, with a block zeroed out on Coherent FS. - -* Super-block location: - - =========== ========================== - Minix FS block 1 = bytes 1024..2047 - Xenix FS block 1 = bytes 1024..2047 - SystemV FS bytes 512..1023 - Coherent FS block 1 = bytes 512..1023 - =========== ========================== - -* Super-block layout: - - - Minix FS:: - - unsigned short s_ninodes; - unsigned short s_nzones; - unsigned short s_imap_blocks; - unsigned short s_zmap_blocks; - unsigned short s_firstdatazone; - unsigned short s_log_zone_size; - unsigned long s_max_size; - unsigned short s_magic; - - - Xenix FS, SystemV FS, Coherent FS:: - - unsigned short s_firstdatazone; - unsigned long s_nzones; - unsigned short s_fzone_count; - unsigned long s_fzones[NICFREE]; - unsigned short s_finode_count; - unsigned short s_finodes[NICINOD]; - char s_flock; - char s_ilock; - char s_modified; - char s_rdonly; - unsigned long s_time; - short s_dinfo[4]; -- SystemV FS only - unsigned long s_free_zones; - unsigned short s_free_inodes; - short s_dinfo[4]; -- Xenix FS only - unsigned short s_interleave_m,s_interleave_n; -- Coherent FS only - char s_fname[6]; - char s_fpack[6]; - - then they differ considerably: - - Xenix FS:: - - char s_clean; - char s_fill[371]; - long s_magic; - long s_type; - - SystemV FS:: - - long s_fill[12 or 14]; - long s_state; - long s_magic; - long s_type; - - Coherent FS:: - - unsigned long s_unique; - - Note that Coherent FS has no magic. - -* Inode layout: - - - Minix FS:: - - unsigned short i_mode; - unsigned short i_uid; - unsigned long i_size; - unsigned long i_time; - unsigned char i_gid; - unsigned char i_nlinks; - unsigned short i_zone[7+1+1]; - - - Xenix FS, SystemV FS, Coherent FS:: - - unsigned short i_mode; - unsigned short i_nlink; - unsigned short i_uid; - unsigned short i_gid; - unsigned long i_size; - unsigned char i_zone[3*(10+1+1+1)]; - unsigned long i_atime; - unsigned long i_mtime; - unsigned long i_ctime; - - -* Regular file data blocks are organized as - - - Minix FS: - - - 7 direct blocks - - 1 indirect block (pointers to blocks) - - 1 double-indirect block (pointer to pointers to blocks) - - - Xenix FS, SystemV FS, Coherent FS: - - - 10 direct blocks - - 1 indirect block (pointers to blocks) - - 1 double-indirect block (pointer to pointers to blocks) - - 1 triple-indirect block (pointer to pointers to pointers to blocks) - - - =========== ========== ================ - Inode size inodes per block - =========== ========== ================ - Minix FS 32 32 - Xenix FS 64 16 - SystemV FS 64 16 - Coherent FS 64 8 - =========== ========== ================ - -* Directory entry on disk - - - Minix FS:: - - unsigned short inode; - char name[14/30]; - - - Xenix FS, SystemV FS, Coherent FS:: - - unsigned short inode; - char name[14]; - - =========== ============== ===================== - Dir entry size dir entries per block - =========== ============== ===================== - Minix FS 16/32 64/32 - Xenix FS 16 64 - SystemV FS 16 64 - Coherent FS 16 32 - =========== ============== ===================== - -* How to implement symbolic links such that the host fsck doesn't scream: - - - Minix FS normal - - Xenix FS kludge: as regular files with chmod 1000 - - SystemV FS ?? - - Coherent FS kludge: as regular files with chmod 1000 - - -Notation: We often speak of a "block" but mean a zone (the allocation unit) -and not the disk driver's notion of "block". diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index 31eea688609a..ae79c30b6c0c 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -495,7 +495,7 @@ As of kernel 2.6.22, the following members are defined: int (*link) (struct dentry *,struct inode *,struct dentry *); int (*unlink) (struct inode *,struct dentry *); int (*symlink) (struct mnt_idmap *, struct inode *,struct dentry *,const char *); - int (*mkdir) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t); + struct dentry *(*mkdir) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t); int (*rmdir) (struct inode *,struct dentry *); int (*mknod) (struct mnt_idmap *, struct inode *,struct dentry *,umode_t,dev_t); int (*rename) (struct mnt_idmap *, struct inode *, struct dentry *, @@ -562,7 +562,26 @@ otherwise noted. ``mkdir`` called by the mkdir(2) system call. Only required if you want to support creating subdirectories. You will probably need to - call d_instantiate() just as you would in the create() method + call d_instantiate_new() just as you would in the create() method. + + If d_instantiate_new() is not used and if the fh_to_dentry() + export operation is provided, or if the storage might be + accessible by another path (e.g. with a network filesystem) + then more care may be needed. Importantly d_instantate() + should not be used with an inode that is no longer I_NEW if there + any chance that the inode could already be attached to a dentry. + This is because of a hard rule in the VFS that a directory must + only ever have one dentry. + + For example, if an NFS filesystem is mounted twice the new directory + could be visible on the other mount before it is on the original + mount, and a pair of name_to_handle_at(), open_by_handle_at() + calls could instantiate the directory inode with an IS_ROOT() + dentry before the first mkdir returns. + + If there is any chance this could happen, then the new inode + should be d_drop()ed and attached with d_splice_alias(). The + returned dentry (if any) should be returned by ->mkdir(). ``rmdir`` called by the rmdir(2) system call. Only required if you want diff --git a/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst b/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst index 6402ab8e370c..2a2705e975e8 100644 --- a/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst +++ b/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst @@ -219,7 +219,7 @@ The log is circular, so the positions in the log are defined by the combination of a cycle number - the number of times the log has been overwritten - and the offset into the log. A LSN carries the cycle in the upper 32 bits and the offset in the lower 32 bits. The offset is in units of "basic blocks" (512 -bytes). Hence we can do realtively simple LSN based math to keep track of +bytes). Hence we can do relatively simple LSN based math to keep track of available space in the log. Log space accounting is done via a pair of constructs called "grant heads". The diff --git a/Documentation/filesystems/xfs/xfs-maintainer-entry-profile.rst b/Documentation/filesystems/xfs/xfs-maintainer-entry-profile.rst index 32b6ac4ca9d6..ce4584fb3103 100644 --- a/Documentation/filesystems/xfs/xfs-maintainer-entry-profile.rst +++ b/Documentation/filesystems/xfs/xfs-maintainer-entry-profile.rst @@ -93,7 +93,7 @@ others on a regular basis about burnout. sponsoring work on any part of XFS. - **LTS Maintainer**: Someone who backports and tests bug fixes from - uptream to the LTS kernels. + upstream to the LTS kernels. There tend to be six separate LTS trees at any given time. The maintainer for a given LTS release should identify themselves with an diff --git a/Documentation/filesystems/xfs/xfs-online-fsck-design.rst b/Documentation/filesystems/xfs/xfs-online-fsck-design.rst index 12aa63840830..e231d127cd40 100644 --- a/Documentation/filesystems/xfs/xfs-online-fsck-design.rst +++ b/Documentation/filesystems/xfs/xfs-online-fsck-design.rst @@ -4521,8 +4521,8 @@ Both online and offline repair can use this strategy. | For this second effort, the ondisk parent pointer format as originally | | proposed was ``(parent_inum, parent_gen, dirent_pos) → (dirent_name)``. | | The format was changed during development to eliminate the requirement | -| of repair tools needing to to ensure that the ``dirent_pos`` field | -| always matched when reconstructing a directory. | +| of repair tools needing to ensure that the ``dirent_pos`` field always | +| matched when reconstructing a directory. | | | | There were a few other ways to have solved that problem: | | | 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/hwmon/abituguru-datasheet.rst b/Documentation/hwmon/abituguru-datasheet.rst index 0cd61471d2a2..19ba4b4cd034 100644 --- a/Documentation/hwmon/abituguru-datasheet.rst +++ b/Documentation/hwmon/abituguru-datasheet.rst @@ -6,9 +6,9 @@ First of all, what I know about uGuru is no fact based on any help, hints or datasheet from Abit. The data I have got on uGuru have I assembled through my weak knowledge in "backwards engineering". And just for the record, you may have noticed uGuru isn't a chip developed by -Abit, as they claim it to be. It's really just an microprocessor (uC) created by +Abit, as they claim it to be. It's really just a microprocessor (uC) created by Winbond (W83L950D). And no, reading the manual for this specific uC or -mailing Windbond for help won't give any useful data about uGuru, as it is +mailing Winbond for help won't give any useful data about uGuru, as it is the program inside the uC that is responding to calls. Olle Sandberg <ollebull@gmail.com>, 2005-05-25 @@ -35,7 +35,7 @@ As far as known the uGuru is always placed at and using the (ISA) I/O-ports ports are holding for detection. We will refer to 0xE0 as CMD (command-port) and 0xE4 as DATA because Abit refers to them with these names. -If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC an uGuru could be +If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC a uGuru could be present. We have to check for two different values at data-port, because after a reboot uGuru will hold 0x00 here, but if the driver is removed and later on attached again data-port will hold 0x08, more about this later. @@ -46,7 +46,7 @@ have to test CMD for two different values. On these uGuru's DATA will initially hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read first! -To be really sure an uGuru is present a test read of one or more register +To be really sure a uGuru is present a test read of one or more register sets should be done. diff --git a/Documentation/hwmon/abituguru.rst b/Documentation/hwmon/abituguru.rst index cfda60b757ce..4a5ee16b1048 100644 --- a/Documentation/hwmon/abituguru.rst +++ b/Documentation/hwmon/abituguru.rst @@ -40,7 +40,7 @@ Supported chips: .. [2] There is a separate abituguru3 driver for these motherboards, the abituguru (without the 3 !) driver will not work on these - motherboards (and visa versa)! + motherboards (and vice versa)! Authors: - Hans de Goede <j.w.r.degoede@hhs.nl>, diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst index 739636cf7994..d2be9db29614 100644 --- a/Documentation/hwmon/asus_ec_sensors.rst +++ b/Documentation/hwmon/asus_ec_sensors.rst @@ -6,6 +6,7 @@ Kernel driver asus_ec_sensors Supported boards: * PRIME X470-PRO * PRIME X570-PRO + * PRIME X670E-PRO WIFI * Pro WS X570-ACE * ProArt X570-CREATOR WIFI * ProArt X670E-CREATOR WIFI diff --git a/Documentation/hwmon/cgbc-hwmon.rst b/Documentation/hwmon/cgbc-hwmon.rst new file mode 100644 index 000000000000..3a5e6e6e8639 --- /dev/null +++ b/Documentation/hwmon/cgbc-hwmon.rst @@ -0,0 +1,63 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver cgbc-hwmon +======================== + +Supported chips: + + * Congatec Board Controller. + + Prefix: 'cgbc-hwmon' + +Author: Thomas Richard <thomas.richard@bootlin.com> + +Description +----------- + +This driver enables monitoring support for the Congatec Board Controller. +This controller is embedded on the x86 SoMs of Congatec. + +Sysfs entries +------------- + +The following sysfs entries list contains all sensors defined in the Board +Controller. The available sensors in sysfs depend on the SoM and the +system. + +============= ====================== +Name Description +============= ====================== +temp1_input CPU temperature +temp2_input Box temperature +temp3_input Ambient temperature +temp4_input Board temperature +temp5_input Carrier temperature +temp6_input Chipset temperature +temp7_input Video temperature +temp8_input Other temperature +temp9_input TOPDIM temperature +temp10_input BOTTOMDIM temperature +in0_input CPU voltage +in1_input DC Runtime voltage +in2_input DC Standby voltage +in3_input CMOS Battery voltage +in4_input Battery voltage +in5_input AC voltage +in6_input Other voltage +in7_input 5V voltage +in8_input 5V Standby voltage +in9_input 3V3 voltage +in10_input 3V3 Standby voltage +in11_input VCore A voltage +in12_input VCore B voltage +in13_input 12V voltage +curr1_input DC current +curr2_input 5V current +curr3_input 12V current +fan1_input CPU fan +fan2_input Box fan +fan3_input Ambient fan +fan4_input Chiptset fan +fan5_input Video fan +fan6_input Other fan +============= ====================== diff --git a/Documentation/hwmon/dell-smm-hwmon.rst b/Documentation/hwmon/dell-smm-hwmon.rst index 74905675d71f..5a4edb6565cf 100644 --- a/Documentation/hwmon/dell-smm-hwmon.rst +++ b/Documentation/hwmon/dell-smm-hwmon.rst @@ -32,12 +32,12 @@ Temperature sensors and fans can be queried and set via the standard =============================== ======= ======================================= Name Perm Description =============================== ======= ======================================= -fan[1-3]_input RO Fan speed in RPM. -fan[1-3]_label RO Fan label. -fan[1-3]_min RO Minimal Fan speed in RPM -fan[1-3]_max RO Maximal Fan speed in RPM -fan[1-3]_target RO Expected Fan speed in RPM -pwm[1-3] RW Control the fan PWM duty-cycle. +fan[1-4]_input RO Fan speed in RPM. +fan[1-4]_label RO Fan label. +fan[1-4]_min RO Minimal Fan speed in RPM +fan[1-4]_max RO Maximal Fan speed in RPM +fan[1-4]_target RO Expected Fan speed in RPM +pwm[1-4] RW Control the fan PWM duty-cycle. pwm1_enable WO Enable or disable automatic BIOS fan control (not supported on all laptops, see below for details). @@ -93,7 +93,7 @@ Again, when you find new codes, we'd be happy to have your patches! --------------------------- The driver also exports the fans as thermal cooling devices with -``type`` set to ``dell-smm-fan[1-3]``. This allows for easy fan control +``type`` set to ``dell-smm-fan[1-4]``. This allows for easy fan control using one of the thermal governors. Module parameters diff --git a/Documentation/hwmon/htu31.rst b/Documentation/hwmon/htu31.rst new file mode 100644 index 000000000000..ccde84264643 --- /dev/null +++ b/Documentation/hwmon/htu31.rst @@ -0,0 +1,37 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver HTU31 +==================== + +Supported chips: + + * Measurement Specialties HTU31 + + Prefix: 'htu31' + + Addresses scanned: - + + Datasheet: Publicly available from https://www.te.com/en/product-CAT-HSC0007.html + +Author: + + - Andrei Lalaev <andrey.lalaev@gmail.com> + +Description +----------- + +HTU31 is a humidity and temperature sensor. + +Supported temperature range is from -40 to 125 degrees Celsius. + +Communication with the device is performed via I2C protocol. Sensor's default address +is 0x40. + +sysfs-Interface +--------------- + +=================== ================= +temp1_input: temperature input +humidity1_input: humidity input +heater_enable: heater control +=================== ================= diff --git a/Documentation/hwmon/ina233.rst b/Documentation/hwmon/ina233.rst new file mode 100644 index 000000000000..42323162e6db --- /dev/null +++ b/Documentation/hwmon/ina233.rst @@ -0,0 +1,75 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver ina233 +==================== + +Supported chips: + + * TI INA233 + + Prefix: 'ina233' + + * Datasheet + + Publicly available at the TI website : https://www.ti.com/lit/ds/symlink/ina233.pdf + +Author: Leo Yang <leo.yang.sy0@gmail.com> + +Usage Notes +----------- + +The shunt resistor value can be configured by a device tree property; +see Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml for details. + + +Description +----------- + +This driver supports hardware monitoring for TI INA233. + +The driver is a client driver to the core PMBus driver. Please see +Documentation/hwmon/pmbus.rst for details on PMBus client drivers. + +The driver provides the following attributes for input voltage: + +**in1_input** + +**in1_label** + +**in1_max** + +**in1_max_alarm** + +**in1_min** + +**in1_min_alarm** + +The driver provides the following attributes for shunt voltage: + +**in2_input** + +**in2_label** + +The driver provides the following attributes for output voltage: + +**in3_input** + +**in3_label** + +**in3_alarm** + +The driver provides the following attributes for output current: + +**curr1_input** + +**curr1_label** + +**curr1_max** + +**curr1_max_alarm** + +The driver provides the following attributes for input power: + +**power1_input** + +**power1_label** diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 874f8fd26325..f0ddf6222c44 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -53,6 +53,7 @@ Hardware Monitoring Kernel Drivers bel-pfe bpa-rs600 bt1-pvt + cgbc-hwmon chipcap2 coretemp corsair-cpro @@ -85,11 +86,13 @@ Hardware Monitoring Kernel Drivers hih6130 hp-wmi-sensors hs3001 + htu31 ibmaem ibm-cffps ibmpowernv ina209 ina2xx + ina233 ina238 ina3221 inspur-ipsps1 diff --git a/Documentation/hwmon/lm90.rst b/Documentation/hwmon/lm90.rst index 23af17a0ab44..98452eed16d5 100644 --- a/Documentation/hwmon/lm90.rst +++ b/Documentation/hwmon/lm90.rst @@ -365,6 +365,34 @@ Supported chips: Datasheet: Not publicly available, can be requested from Nuvoton + * Nuvoton NCT7716 + + Prefix: 'nct7716' + + Addresses scanned: I2C 0x48, 0x49 + + Datasheet: Not publicly available, can be requested from Nuvoton + + * Nuvoton NCT7717 + + Prefix: 'nct7717' + + Addresses scanned: I2C 0x48 + + Datasheet: Publicly available at Nuvoton website + + https://www.nuvoton.com/resource-files/Nuvoton_NCT7717U_Datasheet_V111.pdf + + * Nuvoton NCT7718 + + Prefix: 'nct7718' + + Addresses scanned: I2C 0x4c + + Datasheet: Publicly available at Nuvoton website + + https://www.nuvoton.com/resource-files/Nuvoton_NCT7718W_Datasheet_V11.pdf + * Philips/NXP SA56004X Prefix: 'sa56004' @@ -573,6 +601,21 @@ W83L771AWG/ASG * The AWG and ASG variants only differ in package format. * Diode ideality factor configuration (remote sensor) at 0xE3 +NCT7716: + * 8 bit sensor resolution + * Selectable address + * Configurable conversion rate + +NCT7717: + * 8 bit sensor resolution + * Configurable conversion rate + +NCT7718: + * Temperature offset register for remote temperature sensor + * 11 bit resolution for remote temperature sensor + * Low temperature limits + * Configurable conversion rate + SA56004X: * Better local resolution diff --git a/Documentation/hwmon/ltc2978.rst b/Documentation/hwmon/ltc2978.rst index 651ca4904c66..0b72d566cac7 100644 --- a/Documentation/hwmon/ltc2978.rst +++ b/Documentation/hwmon/ltc2978.rst @@ -5,6 +5,22 @@ Kernel driver ltc2978 Supported chips: + * Analog Devices LT7170 + + Prefix: 'lt7170' + + Addresses scanned: - + + Datasheet: https://www.analog.com/en/products/lt7170.html + + * Analog Devices LT7171 + + Prefix: 'lt7171' + + Addresses scanned: - + + Datasheet: https://www.analog.com/en/products/lt7171.html + * Linear Technology LTC2972 Prefix: 'ltc2972' @@ -151,6 +167,14 @@ Supported chips: Datasheet: https://www.analog.com/en/products/ltm4644 + * Linear Technology LTM4673 + + Prefix: 'ltm4673' + + Addresses scanned: - + + Datasheet: https://www.analog.com/en/products/ltm4673 + * Linear Technology LTM4675 Prefix: 'ltm4675' @@ -215,6 +239,8 @@ Author: Guenter Roeck <linux@roeck-us.net> Description ----------- +- LT7170 and LT7171 are 20 A, 16 V, single- or dual-phase Silent Switcher +- step-down regulators with Digital Power System Management. - LTC2974 and LTC2975 are quad digital power supply managers. - LTC2978 is an octal power supply monitor. - LTC2977 is a pin compatible replacement for LTC2978. @@ -292,6 +318,7 @@ in1_reset_history Reset input voltage history. in[N]_label "vout[1-8]". + - LT7170, LT7171: N=2 - LTC2972: N=2-3 - LTC2974, LTC2975: N=2-5 - LTC2977, LTC2979, LTC2980, LTM2987: N=2-9 @@ -330,6 +357,8 @@ in[N]_reset_history Reset output voltage history. temp[N]_input Measured temperature. + - On LT7170 and LT7171, temp1 reports the chip + temperature. - On LTC2972, temp[1-2] report external temperatures, and temp 3 reports the chip temperature. - On LTC2974 and LTC2975, temp[1-4] report external @@ -403,9 +432,9 @@ power[N]_input Measured output power. curr1_label "iin". - LTC3880, LTC3883, LTC3884, LTC3886, LTC3887, LTC3889, - LTM4644, LTM4675, LTM4676, LTM4677, LTM4678, LTM4680, - and LTM4700 only. + LT7170, LT7171, LTC3880, LTC3883, LTC3884, LTC3886, + LTC3887, LTC3889, LTM4644, LTM4675, LTM4676, LTM4677, + LTM4678, LTM4680, and LTM4700 only. curr1_input Measured input current. @@ -423,6 +452,7 @@ curr1_reset_history Reset input current history. curr[N]_label "iout[1-4]". + - LT7170, LT7171: N=1 - LTC2972: N-1-2 - LTC2974, LTC2975: N=1-4 - LTC2977, LTC2979, LTC2980, LTM2987: not supported diff --git a/Documentation/hwmon/nct6683.rst b/Documentation/hwmon/nct6683.rst index 8d4a20d99e59..3e549ba95a15 100644 --- a/Documentation/hwmon/nct6683.rst +++ b/Documentation/hwmon/nct6683.rst @@ -3,7 +3,7 @@ Kernel driver nct6683 Supported chips: - * Nuvoton NCT6683D/NCT6687D + * Nuvoton NCT6683D/NCT6686D/NCT6687D Prefix: 'nct6683' @@ -61,6 +61,7 @@ Board Firmware version Intel DH87RL NCT6683D EC firmware version 1.0 build 04/03/13 Intel DH87MC NCT6683D EC firmware version 1.0 build 04/03/13 Intel DB85FL NCT6683D EC firmware version 1.0 build 04/03/13 +AMD BC-250 NCT6686D EC firmware version 1.0 build 07/28/21 ASRock X570 NCT6683D EC firmware version 1.0 build 06/28/19 ASRock X670E NCT6686D EC firmware version 1.0 build 05/19/22 ASRock B650 Steel Legend WiFi NCT6686D EC firmware version 1.0 build 11/09/23 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/iio_devbuf.rst b/Documentation/iio/iio_devbuf.rst index 9919e4792d0e..dca1f0200b0d 100644 --- a/Documentation/iio/iio_devbuf.rst +++ b/Documentation/iio/iio_devbuf.rst @@ -148,5 +148,5 @@ applied), however there are corner cases in which the buffered data may be found in a processed form. Please note that these corner cases are not addressed by this documentation. -Please see ``Documentation/ABI/testing/sysfs-bus-iio`` for a complete +Please see Documentation/ABI/testing/sysfs-bus-iio for a complete description of the attributes. 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/input/devices/elantech.rst b/Documentation/input/devices/elantech.rst index c3374a7ce7af..98163a258b83 100644 --- a/Documentation/input/devices/elantech.rst +++ b/Documentation/input/devices/elantech.rst @@ -556,7 +556,7 @@ Note on debounce: In case the box has unstable power supply or other electricity issues, or when number of finger changes, F/W would send "debounce packet" to inform driver that the hardware is in debounce status. -The debouce packet has the following signature:: +The debounce packet has the following signature:: byte 0: 0xc4 byte 1: 0xff diff --git a/Documentation/input/input-programming.rst b/Documentation/input/input-programming.rst index c9264814c7aa..2b3e6a34e34b 100644 --- a/Documentation/input/input-programming.rst +++ b/Documentation/input/input-programming.rst @@ -346,3 +346,22 @@ driver can handle these events, it has to set the respective bits in evbit, This callback routine can be called from an interrupt or a BH (although that isn't a rule), and thus must not sleep, and must not take too long to finish. + +Polled input devices +~~~~~~~~~~~~~~~~~~~~ + +Input polling is set up by passing an input device struct and a callback to +the function:: + + int input_setup_polling(struct input_dev *dev, + void (*poll_fn)(struct input_dev *dev)) + +Within the callback, devices should use the regular input_report_* functions +and input_sync as is used by other devices. + +There is also the function:: + + void input_set_poll_interval(struct input_dev *dev, unsigned int interval) + +which is used to configure the interval, in milliseconds, that the device will +be polled at. 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/livepatch/module-elf-format.rst b/Documentation/livepatch/module-elf-format.rst index a03ed02ec57e..5d48778d4dfc 100644 --- a/Documentation/livepatch/module-elf-format.rst +++ b/Documentation/livepatch/module-elf-format.rst @@ -217,16 +217,19 @@ livepatch relocation section refer to their respective symbols with their symbol indices, and the original symbol indices (and thus the symtab ordering) must be preserved in order for apply_relocate_add() to find the right symbol. -For example, take this particular rela from a livepatch module::: +For example, take this particular rela from a livepatch module:: Relocation section '.klp.rela.btrfs.text.btrfs_feature_attr_show' at offset 0x2ba0 contains 4 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 000000000000001f 0000005e00000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.printk,0 - 4 - This rela refers to the symbol '.klp.sym.vmlinux.printk,0', and the symbol index is encoded - in 'Info'. Here its symbol index is 0x5e, which is 94 in decimal, which refers to the - symbol index 94. - And in this patch module's corresponding symbol table, symbol index 94 refers to that very symbol: +This rela refers to the symbol '.klp.sym.vmlinux.printk,0', and the symbol +index is encoded in 'Info'. Here its symbol index is 0x5e, which is 94 in +decimal, which refers to the symbol index 94. + +And in this patch module's corresponding symbol table, symbol index 94 refers +to that very symbol:: + [ snip ] 94: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.printk,0 [ snip ] 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/split_page_table_lock.rst b/Documentation/mm/split_page_table_lock.rst index 8e1ceb0a6619..cc3cd46abd1b 100644 --- a/Documentation/mm/split_page_table_lock.rst +++ b/Documentation/mm/split_page_table_lock.rst @@ -4,7 +4,7 @@ Split page table lock Originally, mm->page_table_lock spinlock protected all page tables of the mm_struct. But this approach leads to poor page fault scalability of -multi-threaded applications due high contention on the lock. To improve +multi-threaded applications due to high contention on the lock. To improve scalability, split page table lock was introduced. With split page table lock we have separate per-table lock to serialize 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/genetlink-c.yaml b/Documentation/netlink/genetlink-c.yaml index 9660ffb1ed6a..96fa1f1522ed 100644 --- a/Documentation/netlink/genetlink-c.yaml +++ b/Documentation/netlink/genetlink-c.yaml @@ -14,9 +14,10 @@ $defs: pattern: ^[0-9A-Za-z_-]+( - 1)?$ minimum: 0 len-or-limit: - # literal int or limit based on fixed-width type e.g. u8-min, u16-max, etc. + # literal int, const name, or limit based on fixed-width type + # e.g. u8-min, u16-max, etc. type: [ string, integer ] - pattern: ^[su](8|16|32|64)-(min|max)$ + pattern: ^[0-9A-Za-z_-]+$ minimum: 0 # Schema for specs @@ -160,7 +161,7 @@ properties: type: string type: &attr-type enum: [ unused, pad, flag, binary, - uint, sint, u8, u16, u32, u64, s32, s64, + uint, sint, u8, u16, u32, u64, s8, s16, s32, s64, string, nest, indexed-array, nest-type-value ] doc: description: Documentation of the attribute. diff --git a/Documentation/netlink/genetlink-legacy.yaml b/Documentation/netlink/genetlink-legacy.yaml index 16380e12cabe..a8c5b521937d 100644 --- a/Documentation/netlink/genetlink-legacy.yaml +++ b/Documentation/netlink/genetlink-legacy.yaml @@ -14,9 +14,10 @@ $defs: pattern: ^[0-9A-Za-z_-]+( - 1)?$ minimum: 0 len-or-limit: - # literal int or limit based on fixed-width type e.g. u8-min, u16-max, etc. + # literal int, const name, or limit based on fixed-width type + # e.g. u8-min, u16-max, etc. type: [ string, integer ] - pattern: ^[su](8|16|32|64)-(min|max)$ + pattern: ^[0-9A-Za-z_-]+$ minimum: 0 # Schema for specs @@ -151,6 +152,9 @@ properties: the right formatting mechanism when displaying values of this type. enum: [ hex, mac, fddi, ipv4, ipv6, uuid ] + struct: + description: Name of the nested struct type. + type: string # End genetlink-legacy attribute-sets: @@ -203,7 +207,7 @@ properties: type: &attr-type description: The netlink attribute type enum: [ unused, pad, flag, binary, bitfield32, - uint, sint, u8, u16, u32, u64, s32, s64, + uint, sint, u8, u16, u32, u64, s8, s16, s32, s64, string, nest, indexed-array, nest-type-value ] doc: description: Documentation of the attribute. diff --git a/Documentation/netlink/genetlink.yaml b/Documentation/netlink/genetlink.yaml index b036227b46f1..40efbbad76ab 100644 --- a/Documentation/netlink/genetlink.yaml +++ b/Documentation/netlink/genetlink.yaml @@ -14,9 +14,10 @@ $defs: pattern: ^[0-9A-Za-z_-]+( - 1)?$ minimum: 0 len-or-limit: - # literal int or limit based on fixed-width type e.g. u8-min, u16-max, etc. + # literal int, const name, or limit based on fixed-width type + # e.g. u8-min, u16-max, etc. type: [ string, integer ] - pattern: ^[su](8|16|32|64)-(min|max)$ + pattern: ^[0-9A-Za-z_-]+$ minimum: 0 # Schema for specs @@ -123,7 +124,7 @@ properties: type: string type: &attr-type enum: [ unused, pad, flag, binary, - uint, sint, u8, u16, u32, u64, s32, s64, + uint, sint, u8, u16, u32, u64, s8, s16, s32, s64, string, nest, indexed-array, nest-type-value ] doc: description: Documentation of the attribute. diff --git a/Documentation/netlink/specs/conntrack.yaml b/Documentation/netlink/specs/conntrack.yaml new file mode 100644 index 000000000000..840dc4504216 --- /dev/null +++ b/Documentation/netlink/specs/conntrack.yaml @@ -0,0 +1,643 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + +name: conntrack +protocol: netlink-raw +protonum: 12 + +doc: + Netfilter connection tracking subsystem over nfnetlink + +definitions: + - + name: nfgenmsg + type: struct + members: + - + name: nfgen-family + type: u8 + - + name: version + type: u8 + - + name: res-id + byte-order: big-endian + type: u16 + - + name: nf-ct-tcp-flags-mask + type: struct + members: + - + name: flags + type: u8 + enum: nf-ct-tcp-flags + enum-as-flags: true + - + name: mask + type: u8 + enum: nf-ct-tcp-flags + enum-as-flags: true + - + name: nf-ct-tcp-flags + type: flags + entries: + - window-scale + - sack-perm + - close-init + - be-liberal + - unacked + - maxack + - challenge-ack + - simultaneous-open + - + name: nf-ct-tcp-state + type: enum + entries: + - none + - syn-sent + - syn-recv + - established + - fin-wait + - close-wait + - last-ack + - time-wait + - close + - syn-sent2 + - max + - ignore + - retrans + - unack + - timeout-max + - + name: nf-ct-sctp-state + type: enum + entries: + - none + - cloned + - cookie-wait + - cookie-echoed + - established + - shutdown-sent + - shutdown-received + - shutdown-ack-sent + - shutdown-heartbeat-sent + - + name: nf-ct-status + type: flags + entries: + - expected + - seen-reply + - assured + - confirmed + - src-nat + - dst-nat + - seq-adj + - src-nat-done + - dst-nat-done + - dying + - fixed-timeout + - template + - nat-clash + - helper + - offload + - hw-offload + +attribute-sets: + - + name: counter-attrs + attributes: + - + name: packets + type: u64 + byte-order: big-endian + - + name: bytes + type: u64 + byte-order: big-endian + - + name: packets-old + type: u32 + - + name: bytes-old + type: u32 + - + name: pad + type: pad + - + name: tuple-proto-attrs + attributes: + - + name: proto-num + type: u8 + doc: l4 protocol number + - + name: proto-src-port + type: u16 + byte-order: big-endian + doc: l4 source port + - + name: proto-dst-port + type: u16 + byte-order: big-endian + doc: l4 source port + - + name: proto-icmp-id + type: u16 + byte-order: big-endian + doc: l4 icmp id + - + name: proto-icmp-type + type: u8 + - + name: proto-icmp-code + type: u8 + - + name: proto-icmpv6-id + type: u16 + byte-order: big-endian + doc: l4 icmp id + - + name: proto-icmpv6-type + type: u8 + - + name: proto-icmpv6-code + type: u8 + - + name: tuple-ip-attrs + attributes: + - + name: ip-v4-src + type: u32 + byte-order: big-endian + display-hint: ipv4 + doc: ipv4 source address + - + name: ip-v4-dst + type: u32 + byte-order: big-endian + display-hint: ipv4 + doc: ipv4 destination address + - + name: ip-v6-src + type: binary + checks: + min-len: 16 + byte-order: big-endian + display-hint: ipv6 + doc: ipv6 source address + - + name: ip-v6-dst + type: binary + checks: + min-len: 16 + byte-order: big-endian + display-hint: ipv6 + doc: ipv6 destination address + - + name: tuple-attrs + attributes: + - + name: tuple-ip + type: nest + nested-attributes: tuple-ip-attrs + doc: conntrack l3 information + - + name: tuple-proto + type: nest + nested-attributes: tuple-proto-attrs + doc: conntrack l4 information + - + name: tuple-zone + type: u16 + byte-order: big-endian + doc: conntrack zone id + - + name: protoinfo-tcp-attrs + attributes: + - + name: tcp-state + type: u8 + enum: nf-ct-tcp-state + doc: tcp connection state + - + name: tcp-wscale-original + type: u8 + doc: window scaling factor in original direction + - + name: tcp-wscale-reply + type: u8 + doc: window scaling factor in reply direction + - + name: tcp-flags-original + type: binary + struct: nf-ct-tcp-flags-mask + - + name: tcp-flags-reply + type: binary + struct: nf-ct-tcp-flags-mask + - + name: protoinfo-dccp-attrs + attributes: + - + name: dccp-state + type: u8 + doc: dccp connection state + - + name: dccp-role + type: u8 + - + name: dccp-handshake-seq + type: u64 + byte-order: big-endian + - + name: dccp-pad + type: pad + - + name: protoinfo-sctp-attrs + attributes: + - + name: sctp-state + type: u8 + doc: sctp connection state + enum: nf-ct-sctp-state + - + name: vtag-original + type: u32 + byte-order: big-endian + - + name: vtag-reply + type: u32 + byte-order: big-endian + - + name: protoinfo-attrs + attributes: + - + name: protoinfo-tcp + type: nest + nested-attributes: protoinfo-tcp-attrs + doc: conntrack tcp state information + - + name: protoinfo-dccp + type: nest + nested-attributes: protoinfo-dccp-attrs + doc: conntrack dccp state information + - + name: protoinfo-sctp + type: nest + nested-attributes: protoinfo-sctp-attrs + doc: conntrack sctp state information + - + name: help-attrs + attributes: + - + name: help-name + type: string + doc: helper name + - + name: nat-proto-attrs + attributes: + - + name: nat-port-min + type: u16 + byte-order: big-endian + - + name: nat-port-max + type: u16 + byte-order: big-endian + - + name: nat-attrs + attributes: + - + name: nat-v4-minip + type: u32 + byte-order: big-endian + - + name: nat-v4-maxip + type: u32 + byte-order: big-endian + - + name: nat-v6-minip + type: binary + - + name: nat-v6-maxip + type: binary + - + name: nat-proto + type: nest + nested-attributes: nat-proto-attrs + - + name: seqadj-attrs + attributes: + - + name: correction-pos + type: u32 + byte-order: big-endian + - + name: offset-before + type: u32 + byte-order: big-endian + - + name: offset-after + type: u32 + byte-order: big-endian + - + name: secctx-attrs + attributes: + - + name: secctx-name + type: string + - + name: synproxy-attrs + attributes: + - + name: isn + type: u32 + byte-order: big-endian + - + name: its + type: u32 + byte-order: big-endian + - + name: tsoff + type: u32 + byte-order: big-endian + - + name: conntrack-attrs + attributes: + - + name: tuple-orig + type: nest + nested-attributes: tuple-attrs + doc: conntrack l3+l4 protocol information, original direction + - + name: tuple-reply + type: nest + nested-attributes: tuple-attrs + doc: conntrack l3+l4 protocol information, reply direction + - + name: status + type: u32 + byte-order: big-endian + enum: nf-ct-status + enum-as-flags: true + doc: conntrack flag bits + - + name: protoinfo + type: nest + nested-attributes: protoinfo-attrs + - + name: help + type: nest + nested-attributes: help-attrs + - + name: nat-src + type: nest + nested-attributes: nat-attrs + - + name: timeout + type: u32 + byte-order: big-endian + - + name: mark + type: u32 + byte-order: big-endian + - + name: counters-orig + type: nest + nested-attributes: counter-attrs + - + name: counters-reply + type: nest + nested-attributes: counter-attrs + - + name: use + type: u32 + byte-order: big-endian + - + name: id + type: u32 + byte-order: big-endian + - + name: nat-dst + type: nest + nested-attributes: nat-attrs + - + name: tuple-master + type: nest + nested-attributes: tuple-attrs + - + name: seq-adj-orig + type: nest + nested-attributes: seqadj-attrs + - + name: seq-adj-reply + type: nest + nested-attributes: seqadj-attrs + - + name: secmark + type: binary + doc: obsolete + - + name: zone + type: u16 + byte-order: big-endian + doc: conntrack zone id + - + name: secctx + type: nest + nested-attributes: secctx-attrs + - + name: timestamp + type: u64 + byte-order: big-endian + - + name: mark-mask + type: u32 + byte-order: big-endian + - + name: labels + type: binary + - + name: labels mask + type: binary + - + name: synproxy + type: nest + nested-attributes: synproxy-attrs + - + name: filter + type: nest + nested-attributes: tuple-attrs + - + name: status-mask + type: u32 + byte-order: big-endian + enum: nf-ct-status + enum-as-flags: true + doc: conntrack flag bits to change + - + name: timestamp-event + type: u64 + byte-order: big-endian + - + name: conntrack-stats-attrs + attributes: + - + name: searched + type: u32 + byte-order: big-endian + doc: obsolete + - + name: found + type: u32 + byte-order: big-endian + - + name: new + type: u32 + byte-order: big-endian + doc: obsolete + - + name: invalid + type: u32 + byte-order: big-endian + doc: obsolete + - + name: ignore + type: u32 + byte-order: big-endian + doc: obsolete + - + name: delete + type: u32 + byte-order: big-endian + doc: obsolete + - + name: delete-list + type: u32 + byte-order: big-endian + doc: obsolete + - + name: insert + type: u32 + byte-order: big-endian + - + name: insert-failed + type: u32 + byte-order: big-endian + - + name: drop + type: u32 + byte-order: big-endian + - + name: early-drop + type: u32 + byte-order: big-endian + - + name: error + type: u32 + byte-order: big-endian + - + name: search-restart + type: u32 + byte-order: big-endian + - + name: clash-resolve + type: u32 + byte-order: big-endian + - + name: chain-toolong + type: u32 + byte-order: big-endian + +operations: + enum-model: directional + list: + - + name: get + doc: get / dump entries + attribute-set: conntrack-attrs + fixed-header: nfgenmsg + do: + request: + value: 0x101 + attributes: + - tuple-orig + - tuple-reply + - zone + reply: + value: 0x100 + attributes: + - tuple-orig + - tuple-reply + - status + - protoinfo + - help + - nat-src + - nat-dst + - timeout + - mark + - counter-orig + - counter-reply + - use + - id + - nat-dst + - tuple-master + - seq-adj-orig + - seq-adj-reply + - zone + - secctx + - labels + - synproxy + dump: + request: + value: 0x101 + attributes: + - nfgen-family + - mark + - filter + - status + - zone + reply: + value: 0x100 + attributes: + - tuple-orig + - tuple-reply + - status + - protoinfo + - help + - nat-src + - nat-dst + - timeout + - mark + - counter-orig + - counter-reply + - use + - id + - nat-dst + - tuple-master + - seq-adj-orig + - seq-adj-reply + - zone + - secctx + - labels + - synproxy + - + name: get-stats + doc: dump pcpu conntrack stats + attribute-set: conntrack-stats-attrs + fixed-header: nfgenmsg + dump: + request: + value: 0x104 + reply: + value: 0x104 + attributes: + - searched + - found + - insert + - insert-failed + - drop + - early-drop + - error + - search-restart + - clash-resolve + - chain-toolong diff --git a/Documentation/netlink/specs/devlink.yaml b/Documentation/netlink/specs/devlink.yaml index 09fbb4c03fc8..bd9726269b4f 100644 --- a/Documentation/netlink/specs/devlink.yaml +++ b/Documentation/netlink/specs/devlink.yaml @@ -1868,6 +1868,7 @@ operations: - info-version-fixed - info-version-running - info-version-stored + - info-board-serial-number dump: reply: *info-get-reply diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml index 259cb211a338..655d8d10fe24 100644 --- a/Documentation/netlink/specs/ethtool.yaml +++ b/Documentation/netlink/specs/ethtool.yaml @@ -1524,7 +1524,8 @@ attribute-sets: nested-attributes: bitset - name: hwtstamp-flags - type: u32 + type: nest + nested-attributes: bitset operations: enum-model: directional 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/netdev.yaml b/Documentation/netlink/specs/netdev.yaml index cbb544bd6c84..f5e0750ab71d 100644 --- a/Documentation/netlink/specs/netdev.yaml +++ b/Documentation/netlink/specs/netdev.yaml @@ -70,6 +70,10 @@ definitions: name: tx-checksum doc: L3 checksum HW offload is supported by the driver. + - + name: tx-launch-time-fifo + doc: + Launch time HW offload is supported by the driver. - name: queue-type type: enum @@ -115,6 +119,9 @@ attribute-sets: type: u64 enum: xsk-flags - + name: io-uring-provider-info + attributes: [] + - name: page-pool attributes: - @@ -171,6 +178,11 @@ attribute-sets: name: dmabuf doc: ID of the dmabuf this page-pool is attached to. type: u32 + - + name: io-uring + doc: io-uring memory provider information. + type: nest + nested-attributes: io-uring-provider-info - name: page-pool-info subset-of: page-pool @@ -269,6 +281,9 @@ attribute-sets: processing, if event polling finds events type: uint - + name: xsk-info + attributes: [] + - name: queue attributes: - @@ -286,6 +301,9 @@ attribute-sets: - name: type doc: Queue type as rx, tx. Each queue type defines a separate ID space. + XDP TX queues allocated in the kernel are not linked to NAPIs and + thus not listed. AF_XDP queues will have more information set in + the xsk attribute. type: u32 enum: queue-type - @@ -296,7 +314,16 @@ attribute-sets: name: dmabuf doc: ID of the dmabuf attached to this queue, if any. type: u32 - + - + name: io-uring + doc: io_uring memory provider information. + type: nest + nested-attributes: io-uring-provider-info + - + name: xsk + doc: XSK information for this queue, if any. + type: nest + nested-attributes: xsk-info - name: qstats doc: | @@ -444,6 +471,8 @@ attribute-sets: name: tx-needs-csum doc: | Number of packets that required the device to calculate the checksum. + This counter includes the number of GSO wire packets for which device + calculated the L4 checksum. type: uint - name: tx-hw-gso-packets @@ -572,6 +601,7 @@ operations: - inflight-mem - detach-time - dmabuf + - io-uring dump: reply: *pp-reply config-cond: page-pool @@ -637,6 +667,8 @@ operations: - napi-id - ifindex - dmabuf + - io-uring + - xsk dump: request: attributes: @@ -713,8 +745,8 @@ operations: - irq-suspend-timeout kernel-family: - headers: [ "linux/list.h"] - sock-priv: struct list_head + headers: [ "net/netdev_netlink.h"] + sock-priv: struct netdev_nl_sock mcast-groups: list: diff --git a/Documentation/netlink/specs/nl80211.yaml b/Documentation/netlink/specs/nl80211.yaml new file mode 100644 index 000000000000..1ec49c3562cd --- /dev/null +++ b/Documentation/netlink/specs/nl80211.yaml @@ -0,0 +1,2000 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + +name: nl80211 +protocol: genetlink-legacy + +doc: + Netlink API for 802.11 wireless devices + +definitions: + - + name: commands + type: enum + entries: + - unspec + - get-wiphy + - set-wiphy + - new-wiphy + - del-wiphy + - get-interface + - set-interface + - new-interface + - del-interface + - get-key + - set-key + - new-key + - del-key + - get-beacon + - set-beacon + - new-beacon + - del-beacon + - get-station + - set-station + - new-station + - del-station + - get-mpath + - set-mpath + - new-mpath + - del-mpath + - set-bss + - set-reg + - req-set-reg + - get-mesh-config + - set-mesh-config + - set-mgmt-extra-ie + - get-reg + - get-scan + - trigger-scan + - new-scan-results + - scan-aborted + - reg-change + - authenticate + - associate + - deauthenticate + - disassociate + - michael-mic-failure + - reg-beacon-hint + - join-ibss + - leave-ibss + - testmode + - connect + - roam + - disconnect + - set-wiphy-netns + - get-survey + - new-survey-results + - set-pmksa + - del-pmksa + - flush-pmksa + - remain-on-channel + - cancel-remain-on-channel + - set-tx-bitrate-mask + - register-action + - action + - action-tx-status + - set-power-save + - get-power-save + - set-cqm + - notify-cqm + - set-channel + - set-wds-peer + - frame-wait-cancel + - join-mesh + - leave-mesh + - unprot-deauthenticate + - unprot-disassociate + - new-peer-candidate + - get-wowlan + - set-wowlan + - start-sched-scan + - stop-sched-scan + - sched-scan-results + - sched-scan-stopped + - set-rekey-offload + - pmksa-candidate + - tdls-oper + - tdls-mgmt + - unexpected-frame + - probe-client + - register-beacons + - unexpected-4-addr-frame + - set-noack-map + - ch-switch-notify + - start-p2p-device + - stop-p2p-device + - conn-failed + - set-mcast-rate + - set-mac-acl + - radar-detect + - get-protocol-features + - update-ft-ies + - ft-event + - crit-protocol-start + - crit-protocol-stop + - get-coalesce + - set-coalesce + - channel-switch + - vendor + - set-qos-map + - add-tx-ts + - del-tx-ts + - get-mpp + - join-ocb + - leave-ocb + - ch-switch-started-notify + - tdls-channel-switch + - tdls-cancel-channel-switch + - wiphy-reg-change + - abort-scan + - start-nan + - stop-nan + - add-nan-function + - del-nan-function + - change-nan-config + - nan-match + - set-multicast-to-unicast + - update-connect-params + - set-pmk + - del-pmk + - port-authorized + - reload-regdb + - external-auth + - sta-opmode-changed + - control-port-frame + - get-ftm-responder-stats + - peer-measurement-start + - peer-measurement-result + - peer-measurement-complete + - notify-radar + - update-owe-info + - probe-mesh-link + - set-tid-config + - unprot-beacon + - control-port-frame-tx-status + - set-sar-specs + - obss-color-collision + - color-change-request + - color-change-started + - color-change-aborted + - color-change-completed + - set-fils-aad + - assoc-comeback + - add-link + - remove-link + - add-link-sta + - modify-link-sta + - remove-link-sta + - set-hw-timestamp + - links-removed + - set-tid-to-link-mapping + - + name: feature-flags + type: flags + entries: + - sk-tx-status + - ht-ibss + - inactivity-timer + - cell-base-reg-hints + - p2p-device-needs-channel + - sae + - low-priority-scan + - scan-flush + - ap-scan + - vif-txpower + - need-obss-scan + - p2p-go-ctwin + - p2p-go-oppps + - reserved + - advertise-chan-limits + - full-ap-client-state + - userspace-mpm + - active-monitor + - ap-mode-chan-width-change + - ds-param-set-ie-in-probes + - wfa-tpc-ie-in-probes + - quiet + - tx-power-insertion + - ackto-estimation + - static-smps + - dynamic-smps + - supports-wmm-admission + - mac-on-create + - tdls-channel-switch + - scan-random-mac-addr + - sched-scan-random-mac-addr + - no-random-mac-addr + - + name: ieee80211-mcs-info + type: struct + members: + - + name: rx-mask + type: binary + len: 10 + - + name: rx-highest + type: u16 + byte-order: little-endian + - + name: tx-params + type: u8 + - + name: reserved + type: binary + len: 3 + - + name: ieee80211-vht-mcs-info + type: struct + members: + - + name: rx-mcs-map + type: u16 + byte-order: little-endian + - + name: rx-highest + type: u16 + byte-order: little-endian + - + name: tx-mcs-map + type: u16 + byte-order: little-endian + - + name: tx-highest + type: u16 + byte-order: little-endian + - + name: ieee80211-ht-cap + type: struct + members: + - + name: cap-info + type: u16 + byte-order: little-endian + - + name: ampdu-params-info + type: u8 + - + name: mcs + type: binary + struct: ieee80211-mcs-info + - + name: extended-ht-cap-info + type: u16 + byte-order: little-endian + - + name: tx-bf-cap-info + type: u32 + byte-order: little-endian + - + name: antenna-selection-info + type: u8 + - + name: channel-type + type: enum + entries: + - no-ht + - ht20 + - ht40minus + - ht40plus + - + name: sta-flag-update + type: struct + members: + - + name: mask + type: u32 + - + name: set + type: u32 + - + name: protocol-features + type: flags + entries: + - split-wiphy-dump + +attribute-sets: + - + name: nl80211-attrs + name-prefix: nl80211-attr- + enum-name: nl80211-attrs + attr-max-name: num-nl80211-attr + attributes: + - + name: wiphy + type: u32 + - + name: wiphy-name + type: string + - + name: ifindex + type: u32 + - + name: ifname + type: string + - + name: iftype + type: u32 + - + name: mac + type: binary + display-hint: mac + - + name: key-data + type: binary + - + name: key-idx + type: u8 + - + name: key-cipher + type: u32 + - + name: key-seq + type: binary + - + name: key-default + type: flag + - + name: beacon-interval + type: u32 + - + name: dtim-period + type: u32 + - + name: beacon-head + type: binary + - + name: beacon-tail + type: binary + - + name: sta-aid + type: u16 + - + name: sta-flags + type: binary # TODO: nest + - + name: sta-listen-interval + type: u16 + - + name: sta-supported-rates + type: binary + - + name: sta-vlan + type: u32 + - + name: sta-info + type: binary # TODO: nest + - + name: wiphy-bands + type: nest + nested-attributes: wiphy-bands + - + name: mntr-flags + type: binary # TODO: nest + - + name: mesh-id + type: binary + - + name: sta-plink-action + type: u8 + - + name: mpath-next-hop + type: binary + display-hint: mac + - + name: mpath-info + type: binary # TODO: nest + - + name: bss-cts-prot + type: u8 + - + name: bss-short-preamble + type: u8 + - + name: bss-short-slot-time + type: u8 + - + name: ht-capability + type: binary + - + name: supported-iftypes + type: nest + nested-attributes: supported-iftypes + - + name: reg-alpha2 + type: binary + - + name: reg-rules + type: binary # TODO: nest + - + name: mesh-config + type: binary # TODO: nest + - + name: bss-basic-rates + type: binary + - + name: wiphy-txq-params + type: binary # TODO: nest + - + name: wiphy-freq + type: u32 + - + name: wiphy-channel-type + type: u32 + enum: channel-type + - + name: key-default-mgmt + type: flag + - + name: mgmt-subtype + type: u8 + - + name: ie + type: binary + - + name: max-num-scan-ssids + type: u8 + - + name: scan-frequencies + type: binary # TODO: nest + - + name: scan-ssids + type: binary # TODO: nest + - + name: generation + type: u32 + - + name: bss + type: binary # TODO: nest + - + name: reg-initiator + type: u8 + - + name: reg-type + type: u8 + - + name: supported-commands + type: indexed-array + sub-type: u32 + enum: commands + - + name: frame + type: binary + - + name: ssid + type: binary + - + name: auth-type + type: u32 + - + name: reason-code + type: u16 + - + name: key-type + type: u32 + - + name: max-scan-ie-len + type: u16 + - + name: cipher-suites + type: binary + sub-type: u32 + display-hint: hex + - + name: freq-before + type: binary # TODO: nest + - + name: freq-after + type: binary # TODO: nest + - + name: freq-fixed + type: flag + - + name: wiphy-retry-short + type: u8 + - + name: wiphy-retry-long + type: u8 + - + name: wiphy-frag-threshold + type: u32 + - + name: wiphy-rts-threshold + type: u32 + - + name: timed-out + type: flag + - + name: use-mfp + type: u32 + - + name: sta-flags2 + type: binary + struct: sta-flag-update + - + name: control-port + type: flag + - + name: testdata + type: binary + - + name: privacy + type: flag + - + name: disconnected-by-ap + type: flag + - + name: status-code + type: u16 + - + name: cipher-suites-pairwise + type: binary + - + name: cipher-suite-group + type: u32 + - + name: wpa-versions + type: u32 + - + name: akm-suites + type: binary + - + name: req-ie + type: binary + - + name: resp-ie + type: binary + - + name: prev-bssid + type: binary + - + name: key + type: binary # TODO: nest + - + name: keys + type: binary # TODO: nest + - + name: pid + type: u32 + - + name: 4addr + type: u8 + - + name: survey-info + type: binary # TODO: nest + - + name: pmkid + type: binary + - + name: max-num-pmkids + type: u8 + - + name: duration + type: u32 + - + name: cookie + type: u64 + - + name: wiphy-coverage-class + type: u8 + - + name: tx-rates + type: binary # TODO: nest + - + name: frame-match + type: binary + - + name: ack + type: flag + - + name: ps-state + type: u32 + - + name: cqm + type: binary # TODO: nest + - + name: local-state-change + type: flag + - + name: ap-isolate + type: u8 + - + name: wiphy-tx-power-setting + type: u32 + - + name: wiphy-tx-power-level + type: u32 + - + name: tx-frame-types + type: nest + nested-attributes: iftype-attrs + - + name: rx-frame-types + type: nest + nested-attributes: iftype-attrs + - + name: frame-type + type: u16 + - + name: control-port-ethertype + type: flag + - + name: control-port-no-encrypt + type: flag + - + name: support-ibss-rsn + type: flag + - + name: wiphy-antenna-tx + type: u32 + - + name: wiphy-antenna-rx + type: u32 + - + name: mcast-rate + type: u32 + - + name: offchannel-tx-ok + type: flag + - + name: bss-ht-opmode + type: u16 + - + name: key-default-types + type: binary # TODO: nest + - + name: max-remain-on-channel-duration + type: u32 + - + name: mesh-setup + type: binary # TODO: nest + - + name: wiphy-antenna-avail-tx + type: u32 + - + name: wiphy-antenna-avail-rx + type: u32 + - + name: support-mesh-auth + type: flag + - + name: sta-plink-state + type: u8 + - + name: wowlan-triggers + type: binary # TODO: nest + - + name: wowlan-triggers-supported + type: nest + nested-attributes: wowlan-triggers-attrs + - + name: sched-scan-interval + type: u32 + - + name: interface-combinations + type: indexed-array + sub-type: nest + nested-attributes: if-combination-attributes + - + name: software-iftypes + type: nest + nested-attributes: supported-iftypes + - + name: rekey-data + type: binary # TODO: nest + - + name: max-num-sched-scan-ssids + type: u8 + - + name: max-sched-scan-ie-len + type: u16 + - + name: scan-supp-rates + type: binary # TODO: nest + - + name: hidden-ssid + type: u32 + - + name: ie-probe-resp + type: binary + - + name: ie-assoc-resp + type: binary + - + name: sta-wme + type: binary # TODO: nest + - + name: support-ap-uapsd + type: flag + - + name: roam-support + type: flag + - + name: sched-scan-match + type: binary # TODO: nest + - + name: max-match-sets + type: u8 + - + name: pmksa-candidate + type: binary # TODO: nest + - + name: tx-no-cck-rate + type: flag + - + name: tdls-action + type: u8 + - + name: tdls-dialog-token + type: u8 + - + name: tdls-operation + type: u8 + - + name: tdls-support + type: flag + - + name: tdls-external-setup + type: flag + - + name: device-ap-sme + type: u32 + - + name: dont-wait-for-ack + type: flag + - + name: feature-flags + type: u32 + enum: feature-flags + enum-as-flags: True + - + name: probe-resp-offload + type: u32 + - + name: probe-resp + type: binary + - + name: dfs-region + type: u8 + - + name: disable-ht + type: flag + - + name: ht-capability-mask + type: binary + struct: ieee80211-ht-cap + - + name: noack-map + type: u16 + - + name: inactivity-timeout + type: u16 + - + name: rx-signal-dbm + type: u32 + - + name: bg-scan-period + type: u16 + - + name: wdev + type: u64 + - + name: user-reg-hint-type + type: u32 + - + name: conn-failed-reason + type: u32 + - + name: auth-data + type: binary + - + name: vht-capability + type: binary + - + name: scan-flags + type: u32 + - + name: channel-width + type: u32 + - + name: center-freq1 + type: u32 + - + name: center-freq2 + type: u32 + - + name: p2p-ctwindow + type: u8 + - + name: p2p-oppps + type: u8 + - + name: local-mesh-power-mode + type: u32 + - + name: acl-policy + type: u32 + - + name: mac-addrs + type: binary # TODO: nest + - + name: mac-acl-max + type: u32 + - + name: radar-event + type: u32 + - + name: ext-capa + type: binary + - + name: ext-capa-mask + type: binary + - + name: sta-capability + type: u16 + - + name: sta-ext-capability + type: binary + - + name: protocol-features + type: u32 + enum: protocol-features + - + name: split-wiphy-dump + type: flag + - + name: disable-vht + type: flag + - + name: vht-capability-mask + type: binary + - + name: mdid + type: u16 + - + name: ie-ric + type: binary + - + name: crit-prot-id + type: u16 + - + name: max-crit-prot-duration + type: u16 + - + name: peer-aid + type: u16 + - + name: coalesce-rule + type: binary # TODO: nest + - + name: ch-switch-count + type: u32 + - + name: ch-switch-block-tx + type: flag + - + name: csa-ies + type: binary # TODO: nest + - + name: cntdwn-offs-beacon + type: binary + - + name: cntdwn-offs-presp + type: binary + - + name: rxmgmt-flags + type: binary + - + name: sta-supported-channels + type: binary + - + name: sta-supported-oper-classes + type: binary + - + name: handle-dfs + type: flag + - + name: support-5-mhz + type: flag + - + name: support-10-mhz + type: flag + - + name: opmode-notif + type: u8 + - + name: vendor-id + type: u32 + - + name: vendor-subcmd + type: u32 + - + name: vendor-data + type: binary + - + name: vendor-events + type: binary + - + name: qos-map + type: binary + - + name: mac-hint + type: binary + display-hint: mac + - + name: wiphy-freq-hint + type: u32 + - + name: max-ap-assoc-sta + type: u32 + - + name: tdls-peer-capability + type: u32 + - + name: socket-owner + type: flag + - + name: csa-c-offsets-tx + type: binary + - + name: max-csa-counters + type: u8 + - + name: tdls-initiator + type: flag + - + name: use-rrm + type: flag + - + name: wiphy-dyn-ack + type: flag + - + name: tsid + type: u8 + - + name: user-prio + type: u8 + - + name: admitted-time + type: u16 + - + name: smps-mode + type: u8 + - + name: oper-class + type: u8 + - + name: mac-mask + type: binary + display-hint: mac + - + name: wiphy-self-managed-reg + type: flag + - + name: ext-features + type: binary + - + name: survey-radio-stats + type: binary + - + name: netns-fd + type: u32 + - + name: sched-scan-delay + type: u32 + - + name: reg-indoor + type: flag + - + name: max-num-sched-scan-plans + type: u32 + - + name: max-scan-plan-interval + type: u32 + - + name: max-scan-plan-iterations + type: u32 + - + name: sched-scan-plans + type: binary # TODO: nest + - + name: pbss + type: flag + - + name: bss-select + type: binary # TODO: nest + - + name: sta-support-p2p-ps + type: u8 + - + name: pad + type: binary + - + name: iftype-ext-capa + type: binary # TODO: nest + - + name: mu-mimo-group-data + type: binary + - + name: mu-mimo-follow-mac-addr + type: binary + display-hint: mac + - + name: scan-start-time-tsf + type: u64 + - + name: scan-start-time-tsf-bssid + type: binary + - + name: measurement-duration + type: u16 + - + name: measurement-duration-mandatory + type: flag + - + name: mesh-peer-aid + type: u16 + - + name: nan-master-pref + type: u8 + - + name: bands + type: u32 + - + name: nan-func + type: binary # TODO: nest + - + name: nan-match + type: binary # TODO: nest + - + name: fils-kek + type: binary + - + name: fils-nonces + type: binary + - + name: multicast-to-unicast-enabled + type: flag + - + name: bssid + type: binary + display-hint: mac + - + name: sched-scan-relative-rssi + type: s8 + - + name: sched-scan-rssi-adjust + type: binary + - + name: timeout-reason + type: u32 + - + name: fils-erp-username + type: binary + - + name: fils-erp-realm + type: binary + - + name: fils-erp-next-seq-num + type: u16 + - + name: fils-erp-rrk + type: binary + - + name: fils-cache-id + type: binary + - + name: pmk + type: binary + - + name: sched-scan-multi + type: flag + - + name: sched-scan-max-reqs + type: u32 + - + name: want-1x-4way-hs + type: flag + - + name: pmkr0-name + type: binary + - + name: port-authorized + type: binary + - + name: external-auth-action + type: u32 + - + name: external-auth-support + type: flag + - + name: nss + type: u8 + - + name: ack-signal + type: s32 + - + name: control-port-over-nl80211 + type: flag + - + name: txq-stats + type: nest + nested-attributes: txq-stats-attrs + - + name: txq-limit + type: u32 + - + name: txq-memory-limit + type: u32 + - + name: txq-quantum + type: u32 + - + name: he-capability + type: binary + - + name: ftm-responder + type: binary # TODO: nest + - + name: ftm-responder-stats + type: binary # TODO: nest + - + name: timeout + type: u32 + - + name: peer-measurements + type: binary # TODO: nest + - + name: airtime-weight + type: u16 + - + name: sta-tx-power-setting + type: u8 + - + name: sta-tx-power + type: s16 + - + name: sae-password + type: binary + - + name: twt-responder + type: flag + - + name: he-obss-pd + type: binary # TODO: nest + - + name: wiphy-edmg-channels + type: u8 + - + name: wiphy-edmg-bw-config + type: u8 + - + name: vlan-id + type: u16 + - + name: he-bss-color + type: binary # TODO: nest + - + name: iftype-akm-suites + type: binary # TODO: nest + - + name: tid-config + type: binary # TODO: nest + - + name: control-port-no-preauth + type: flag + - + name: pmk-lifetime + type: u32 + - + name: pmk-reauth-threshold + type: u8 + - + name: receive-multicast + type: flag + - + name: wiphy-freq-offset + type: u32 + - + name: center-freq1-offset + type: u32 + - + name: scan-freq-khz + type: binary # TODO: nest + - + name: he-6ghz-capability + type: binary + - + name: fils-discovery + type: binary # TOOD: nest + - + name: unsol-bcast-probe-resp + type: binary # TOOD: nest + - + name: s1g-capability + type: binary + - + name: s1g-capability-mask + type: binary + - + name: sae-pwe + type: u8 + - + name: reconnect-requested + type: binary + - + name: sar-spec + type: nest + nested-attributes: sar-attributes + - + name: disable-he + type: flag + - + name: obss-color-bitmap + type: u64 + - + name: color-change-count + type: u8 + - + name: color-change-color + type: u8 + - + name: color-change-elems + type: binary # TODO: nest + - + name: mbssid-config + type: binary # TODO: nest + - + name: mbssid-elems + type: binary # TODO: nest + - + name: radar-background + type: flag + - + name: ap-settings-flags + type: u32 + - + name: eht-capability + type: binary + - + name: disable-eht + type: flag + - + name: mlo-links + type: binary # TODO: nest + - + name: mlo-link-id + type: u8 + - + name: mld-addr + type: binary + display-hint: mac + - + name: mlo-support + type: flag + - + name: max-num-akm-suites + type: binary + - + name: eml-capability + type: u16 + - + name: mld-capa-and-ops + type: u16 + - + name: tx-hw-timestamp + type: u64 + - + name: rx-hw-timestamp + type: u64 + - + name: td-bitmap + type: binary + - + name: punct-bitmap + type: u32 + - + name: max-hw-timestamp-peers + type: u16 + - + name: hw-timestamp-enabled + type: flag + - + name: ema-rnr-elems + type: binary # TODO: nest + - + name: mlo-link-disabled + type: flag + - + name: bss-dump-include-use-data + type: flag + - + name: mlo-ttlm-dlink + type: u16 + - + name: mlo-ttlm-ulink + type: u16 + - + name: assoc-spp-amsdu + type: flag + - + name: wiphy-radios + type: binary # TODO: nest + - + name: wiphy-interface-combinations + type: binary # TODO: nest + - + name: vif-radio-mask + type: u32 + - + name: frame-type-attrs + subset-of: nl80211-attrs + attributes: + - + name: frame-type + - + name: wiphy-bands + name-prefix: nl80211-band- + attr-max-name: num-nl80211-bands + attributes: + - + name: 2ghz + doc: 2.4 GHz ISM band + value: 0 + type: nest + nested-attributes: band-attrs + - + name: 5ghz + doc: around 5 GHz band (4.9 - 5.7 GHz) + type: nest + nested-attributes: band-attrs + - + name: 60ghz + doc: around 60 GHz band (58.32 - 69.12 GHz) + type: nest + nested-attributes: band-attrs + - + name: 6ghz + type: nest + nested-attributes: band-attrs + - + name: s1ghz + type: nest + nested-attributes: band-attrs + - + name: lc + type: nest + nested-attributes: band-attrs + - + name: band-attrs + enum-name: nl80211-band-attr + name-prefix: nl80211-band-attr- + attributes: + - + name: freqs + type: indexed-array + sub-type: nest + nested-attributes: frequency-attrs + - + name: rates + type: indexed-array + sub-type: nest + nested-attributes: bitrate-attrs + - + name: ht-mcs-set + type: binary + struct: ieee80211-mcs-info + - + name: ht-capa + type: u16 + - + name: ht-ampdu-factor + type: u8 + - + name: ht-ampdu-density + type: u8 + - + name: vht-mcs-set + type: binary + struct: ieee80211-vht-mcs-info + - + name: vht-capa + type: u32 + - + name: iftype-data + type: indexed-array + sub-type: nest + nested-attributes: iftype-data-attrs + - + name: edmg-channels + type: binary + - + name: edmg-bw-config + type: binary + - + name: s1g-mcs-nss-set + type: binary + - + name: s1g-capa + type: binary + - + name: bitrate-attrs + name-prefix: nl80211-bitrate-attr- + attributes: + - + name: rate + type: u32 + - + name: 2ghz-shortpreamble + type: flag + - + name: frequency-attrs + name-prefix: nl80211-frequency-attr- + attributes: + - + name: freq + type: u32 + - + name: disabled + type: flag + - + name: no-ir + type: flag + - + name: no-ibss + name-prefix: __nl80211-frequency-attr- + type: flag + - + name: radar + type: flag + - + name: max-tx-power + type: u32 + - + name: dfs-state + type: u32 + - + name: dfs-time + type: binary + - + name: no-ht40-minus + type: binary + - + name: no-ht40-plus + type: binary + - + name: no-80mhz + type: binary + - + name: no-160mhz + type: binary + - + name: dfs-cac-time + type: binary + - + name: indoor-only + type: binary + - + name: ir-concurrent + type: binary + - + name: no-20mhz + type: binary + - + name: no-10mhz + type: binary + - + name: wmm + type: indexed-array + sub-type: nest + nested-attributes: wmm-attrs + - + name: no-he + type: binary + - + name: offset + type: u32 + - + name: 1mhz + type: binary + - + name: 2mhz + type: binary + - + name: 4mhz + type: binary + - + name: 8mhz + type: binary + - + name: 16mhz + type: binary + - + name: no-320mhz + type: binary + - + name: no-eht + type: binary + - + name: psd + type: binary + - + name: dfs-concurrent + type: binary + - + name: no-6ghz-vlp-client + type: binary + - + name: no-6ghz-afc-client + type: binary + - + name: can-monitor + type: binary + - + name: allow-6ghz-vlp-ap + type: binary + - + name: if-combination-attributes + enum-name: nl80211-if-combination-attrs + name-prefix: nl80211-iface-comb- + attr-max-name: max-nl80211-iface-comb + attributes: + - + name: limits + type: indexed-array + sub-type: nest + nested-attributes: iface-limit-attributes + - + name: maxnum + type: u32 + - + name: sta-ap-bi-match + type: flag + - + name: num-channels + type: u32 + - + name: radar-detect-widths + type: u32 + - + name: radar-detect-regions + type: u32 + - + name: bi-min-gcd + type: u32 + - + name: iface-limit-attributes + enum-name: nl80211-iface-limit-attrs + name-prefix: nl80211-iface-limit- + attr-max-name: max-nl80211-iface-limit + attributes: + - + name: max + type: u32 + - + name: types + type: nest + nested-attributes: supported-iftypes + - + name: iftype-data-attrs + name-prefix: nl80211-band-iftype-attr- + attributes: + - + name: iftypes + type: binary + - + name: he-cap-mac + type: binary + - + name: he-cap-phy + type: binary + - + name: he-cap-mcs-set + type: binary + - + name: he-cap-ppe + type: binary + - + name: he-6ghz-capa + type: binary + - + name: vendor-elems + type: binary + - + name: eht-cap-mac + type: binary + - + name: eht-cap-phy + type: binary + - + name: eht-cap-mcs-set + type: binary + - + name: eht-cap-ppe + type: binary + - + name: iftype-attrs + enum-name: nl80211-iftype + name-prefix: nl80211-iftype- + attributes: + - + name: unspecified + type: nest + value: 0 + nested-attributes: frame-type-attrs + - + name: adhoc + type: nest + nested-attributes: frame-type-attrs + - + name: station + type: nest + nested-attributes: frame-type-attrs + - + name: ap + type: nest + nested-attributes: frame-type-attrs + - + name: ap-vlan + type: nest + nested-attributes: frame-type-attrs + - + name: wds + type: nest + nested-attributes: frame-type-attrs + - + name: monitor + type: nest + nested-attributes: frame-type-attrs + - + name: mesh-point + type: nest + nested-attributes: frame-type-attrs + - + name: p2p-client + type: nest + nested-attributes: frame-type-attrs + - + name: p2p-go + type: nest + nested-attributes: frame-type-attrs + - + name: p2p-device + type: nest + nested-attributes: frame-type-attrs + - + name: ocb + type: nest + nested-attributes: frame-type-attrs + - + name: nan + type: nest + nested-attributes: frame-type-attrs + - + name: sar-attributes + enum-name: nl80211-sar-attrs + name-prefix: nl80211-sar-attr- + attributes: + - + name: type + type: u32 + - + name: specs + type: indexed-array + sub-type: nest + nested-attributes: sar-specs + - + name: sar-specs + enum-name: nl80211-sar-specs-attrs + name-prefix: nl80211-sar-attr-specs- + attributes: + - + name: power + type: s32 + - + name: range-index + type: u32 + - + name: start-freq + type: u32 + - + name: end-freq + type: u32 + - + name: supported-iftypes + enum-name: nl80211-iftype + name-prefix: nl80211-iftype- + attributes: + - + name: adhoc + type: flag + - + name: station + type: flag + - + name: ap + type: flag + - + name: ap-vlan + type: flag + - + name: wds + type: flag + - + name: monitor + type: flag + - + name: mesh-point + type: flag + - + name: p2p-client + type: flag + - + name: p2p-go + type: flag + - + name: p2p-device + type: flag + - + name: ocb + type: flag + - + name: nan + type: flag + - + name: txq-stats-attrs + name-prefix: nl80211-txq-stats- + attributes: + - + name: backlog-bytes + type: u32 + - + name: backlog-packets + type: u32 + - + name: flows + type: u32 + - + name: drops + type: u32 + - + name: ecn-marks + type: u32 + - + name: overlimit + type: u32 + - + name: overmemory + type: u32 + - + name: collisions + type: u32 + - + name: tx-bytes + type: u32 + - + name: tx-packets + type: u32 + - + name: max-flows + type: u32 + - + name: wmm-attrs + enum-name: nl80211-wmm-rule + name-prefix: nl80211-wmmr- + attributes: + - + name: cw-min + type: u16 + - + name: cw-max + type: u16 + - + name: aifsn + type: u8 + - + name: txop + type: u16 + - + name: wowlan-triggers-attrs + enum-name: nl80211-wowlan-triggers + name-prefix: nl80211-wowlan-trig- + attr-max-name: max-nl80211-wowlan-trig + attributes: + - + name: any + type: flag + - + name: disconnect + type: flag + - + name: magic-pkt + type: flag + - + name: pkt-pattern + type: flag + - + name: gtk-rekey-supported + type: flag + - + name: gtk-rekey-failure + type: flag + - + name: eap-ident-request + type: flag + - + name: 4way-handshake + type: flag + - + name: rfkill-release + type: flag + - + name: wakeup-pkt-80211 + type: flag + - + name: wakeup-pkt-80211-len + type: flag + - + name: wakeup-pkt-8023 + type: flag + - + name: wakeup-pkt-8023-len + type: flag + - + name: tcp-connection + type: flag + - + name: wakeup-tcp-match + type: flag + - + name: wakeup-tcp-connlost + type: flag + - + name: wakeup-tcp-nomoretokens + type: flag + - + name: net-detect + type: flag + - + name: net-detect-results + type: flag + - + name: unprotected-deauth-disassoc + type: flag + +operations: + enum-model: directional + list: + - + name: get-wiphy + doc: | + Get information about a wiphy or dump a list of all wiphys. Requests to dump get-wiphy + should unconditionally include the split-wiphy-dump flag in the request. + attribute-set: nl80211-attrs + do: + request: + value: 1 + attributes: + - wiphy + - wdev + - ifindex + reply: + value: 3 + attributes: &wiphy-reply-attrs + - bands + - cipher-suites + - control-port-ethertype + - ext-capa + - ext-capa-mask + - ext-features + - feature-flags + - generation + - ht-capability-mask + - interface-combinations + - mac + - max-csa-counters + - max-match-sets + - max-num-akm-suites + - max-num-pmkids + - max-num-scan-ssids + - max-num-sched-scan-plans + - max-num-sched-scan-ssids + - max-remain-on-channel-duration + - max-scan-ie-len + - max-scan-plan-interval + - max-scan-plan-iterations + - max-sched-scan-ie-len + - offchannel-tx-ok + - rx-frame-types + - sar-spec + - sched-scan-max-reqs + - software-iftypes + - support-ap-uapsd + - supported-commands + - supported-iftypes + - tdls-external-setup + - tdls-support + - tx-frame-types + - txq-limit + - txq-memory-limit + - txq-quantum + - txq-stats + - vht-capability-mask + - wiphy + - wiphy-antenna-avail-rx + - wiphy-antenna-avail-tx + - wiphy-antenna-rx + - wiphy-antenna-tx + - wiphy-bands + - wiphy-coverage-class + - wiphy-frag-threshold + - wiphy-name + - wiphy-retry-long + - wiphy-retry-short + - wiphy-rts-threshold + - wowlan-triggers-supported + dump: + request: + attributes: + - wiphy + - wdev + - ifindex + - split-wiphy-dump + reply: + attributes: *wiphy-reply-attrs + - + name: get-interface + doc: Get information about an interface or dump a list of all interfaces + attribute-set: nl80211-attrs + do: + request: + value: 5 + attributes: + - ifname + reply: + value: 7 + attributes: &interface-reply-attrs + - ifname + - iftype + - ifindex + - wiphy + - wdev + - mac + - generation + - txq-stats + - 4addr + dump: + request: + attributes: + - ifname + reply: + attributes: *interface-reply-attrs + - + name: get-protocol-features + doc: Get information about supported protocol features + attribute-set: nl80211-attrs + do: + request: + value: 95 + attributes: + - protocol-features + reply: + value: 95 + attributes: + - protocol-features + +mcast-groups: + list: + - + name: config + - + name: scan + - + name: regulatory + - + name: mlme + - + name: vendor + - + name: nan + - + name: testmode diff --git a/Documentation/netlink/specs/rt_addr.yaml b/Documentation/netlink/specs/rt_addr.yaml index cbee1cedb177..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. @@ -168,6 +169,30 @@ operations: reply: value: 20 attributes: *ifaddr-all + - + name: getmulticast + doc: Get / dump IPv4/IPv6 multicast addresses. + attribute-set: addr-attrs + fixed-header: ifaddrmsg + do: + request: + value: 58 + attributes: + - ifa-family + - ifa-index + reply: + value: 58 + attributes: &mcaddr-attrs + - multicast + - cacheinfo + dump: + request: + value: 58 + attributes: + - ifa-family + reply: + value: 58 + attributes: *mcaddr-attrs mcast-groups: list: diff --git a/Documentation/netlink/specs/rt_link.yaml b/Documentation/netlink/specs/rt_link.yaml index 0d492500c7e5..31238455f8e9 100644 --- a/Documentation/netlink/specs/rt_link.yaml +++ b/Documentation/netlink/specs/rt_link.yaml @@ -771,6 +771,18 @@ definitions: name: to type: u32 - + name: ifla-geneve-port-range + type: struct + members: + - + name: low + type: u16 + byte-order: big-endian + - + name: high + type: u16 + byte-order: big-endian + - name: ifla-vf-mac type: struct members: @@ -1148,6 +1160,9 @@ attribute-sets: name: max-pacing-offload-horizon type: uint doc: EDT offload horizon supported by the device (in nsec). + - + name: netns-immutable + type: u8 - name: af-spec-attrs attributes: @@ -1915,6 +1930,10 @@ attribute-sets: - name: inner-proto-inherit type: flag + - + name: port-range + type: binary + struct: ifla-geneve-port-range - name: linkinfo-iptun-attrs name-prefix: ifla-iptun- 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/netlink/specs/rt_rule.yaml b/Documentation/netlink/specs/rt_rule.yaml index a9debac3058a..de0938d36541 100644 --- a/Documentation/netlink/specs/rt_rule.yaml +++ b/Documentation/netlink/specs/rt_rule.yaml @@ -182,6 +182,18 @@ attribute-sets: type: u32 byte-order: big-endian display-hint: hex + - + name: sport-mask + type: u16 + display-hint: hex + - + name: dport-mask + type: u16 + display-hint: hex + - + name: dscp-mask + type: u8 + display-hint: hex operations: enum-model: directional @@ -215,6 +227,9 @@ operations: - dscp - flowlabel - flowlabel-mask + - sport-mask + - dport-mask + - dscp-mask - name: newrule-ntf doc: Notify a rule creation diff --git a/Documentation/networking/batman-adv.rst b/Documentation/networking/batman-adv.rst index 44b9b5cc0e24..ec53a42499c1 100644 --- a/Documentation/networking/batman-adv.rst +++ b/Documentation/networking/batman-adv.rst @@ -27,7 +27,7 @@ Load the batman-adv module into your kernel:: $ insmod batman-adv.ko The module is now waiting for activation. You must add some interfaces on which -batman-adv can operate. The batman-adv soft-interface can be created using the +batman-adv can operate. The batman-adv mesh-interface can be created using the iproute2 tool ``ip``:: $ ip link add name bat0 type batadv diff --git a/Documentation/networking/device_drivers/cable/index.rst b/Documentation/networking/device_drivers/cable/index.rst deleted file mode 100644 index cce3c4392972..000000000000 --- a/Documentation/networking/device_drivers/cable/index.rst +++ /dev/null @@ -1,18 +0,0 @@ -.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) - -Cable Modem Device Drivers -========================== - -Contents: - -.. toctree:: - :maxdepth: 2 - - sb1000 - -.. only:: subproject and html - - Indices - ======= - - * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/cable/sb1000.rst b/Documentation/networking/device_drivers/cable/sb1000.rst deleted file mode 100644 index c8582ca4034d..000000000000 --- a/Documentation/networking/device_drivers/cable/sb1000.rst +++ /dev/null @@ -1,222 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -=================== -SB100 device driver -=================== - -sb1000 is a module network device driver for the General Instrument (also known -as NextLevel) SURFboard1000 internal cable modem board. This is an ISA card -which is used by a number of cable TV companies to provide cable modem access. -It's a one-way downstream-only cable modem, meaning that your upstream net link -is provided by your regular phone modem. - -This driver was written by Franco Venturi <fventuri@mediaone.net>. He deserves -a great deal of thanks for this wonderful piece of code! - -Needed tools -============ - -Support for this device is now a part of the standard Linux kernel. The -driver source code file is drivers/net/sb1000.c. In addition to this -you will need: - -1. The "cmconfig" program. This is a utility which supplements "ifconfig" - to configure the cable modem and network interface (usually called "cm0"); - -2. Several PPP scripts which live in /etc/ppp to make connecting via your - cable modem easy. - - These utilities can be obtained from: - - http://www.jacksonville.net/~fventuri/ - - in Franco's original source code distribution .tar.gz file. Support for - the sb1000 driver can be found at: - - - http://web.archive.org/web/%2E/http://home.adelphia.net/~siglercm/sb1000.html - - http://web.archive.org/web/%2E/http://linuxpower.cx/~cable/ - - along with these utilities. - -3. The standard isapnp tools. These are necessary to configure your SB1000 - card at boot time (or afterwards by hand) since it's a PnP card. - - If you don't have these installed as a standard part of your Linux - distribution, you can find them at: - - http://www.roestock.demon.co.uk/isapnptools/ - - or check your Linux distribution binary CD or their web site. For help with - isapnp, pnpdump, or /etc/isapnp.conf, go to: - - http://www.roestock.demon.co.uk/isapnptools/isapnpfaq.html - -Using the driver -================ - -To make the SB1000 card work, follow these steps: - -1. Run ``make config``, or ``make menuconfig``, or ``make xconfig``, whichever - you prefer, in the top kernel tree directory to set up your kernel - configuration. Make sure to say "Y" to "Prompt for development drivers" - and to say "M" to the sb1000 driver. Also say "Y" or "M" to all the standard - networking questions to get TCP/IP and PPP networking support. - -2. **BEFORE** you build the kernel, edit drivers/net/sb1000.c. Make sure - to redefine the value of READ_DATA_PORT to match the I/O address used - by isapnp to access your PnP cards. This is the value of READPORT in - /etc/isapnp.conf or given by the output of pnpdump. - -3. Build and install the kernel and modules as usual. - -4. Boot your new kernel following the usual procedures. - -5. Set up to configure the new SB1000 PnP card by capturing the output - of "pnpdump" to a file and editing this file to set the correct I/O ports, - IRQ, and DMA settings for all your PnP cards. Make sure none of the settings - conflict with one another. Then test this configuration by running the - "isapnp" command with your new config file as the input. Check for - errors and fix as necessary. (As an aside, I use I/O ports 0x110 and - 0x310 and IRQ 11 for my SB1000 card and these work well for me. YMMV.) - Then save the finished config file as /etc/isapnp.conf for proper - configuration on subsequent reboots. - -6. Download the original file sb1000-1.1.2.tar.gz from Franco's site or one of - the others referenced above. As root, unpack it into a temporary directory - and do a ``make cmconfig`` and then ``install -c cmconfig /usr/local/sbin``. - Don't do ``make install`` because it expects to find all the utilities built - and ready for installation, not just cmconfig. - -7. As root, copy all the files under the ppp/ subdirectory in Franco's - tar file into /etc/ppp, being careful not to overwrite any files that are - already in there. Then modify ppp@gi-on to set the correct login name, - phone number, and frequency for the cable modem. Also edit pap-secrets - to specify your login name and password and any site-specific information - you need. - -8. Be sure to modify /etc/ppp/firewall to use ipchains instead of - the older ipfwadm commands from the 2.0.x kernels. There's a neat utility to - convert ipfwadm commands to ipchains commands: - - http://users.dhp.com/~whisper/ipfwadm2ipchains/ - - You may also wish to modify the firewall script to implement a different - firewalling scheme. - -9. Start the PPP connection via the script /etc/ppp/ppp@gi-on. You must be - root to do this. It's better to use a utility like sudo to execute - frequently used commands like this with root permissions if possible. If you - connect successfully the cable modem interface will come up and you'll see a - driver message like this at the console:: - - cm0: sb1000 at (0x110,0x310), csn 1, S/N 0x2a0d16d8, IRQ 11. - sb1000.c:v1.1.2 6/01/98 (fventuri@mediaone.net) - - The "ifconfig" command should show two new interfaces, ppp0 and cm0. - - The command "cmconfig cm0" will give you information about the cable modem - interface. - -10. Try pinging a site via ``ping -c 5 www.yahoo.com``, for example. You should - see packets received. - -11. If you can't get site names (like www.yahoo.com) to resolve into - IP addresses (like 204.71.200.67), be sure your /etc/resolv.conf file - has no syntax errors and has the right nameserver IP addresses in it. - If this doesn't help, try something like ``ping -c 5 204.71.200.67`` to - see if the networking is running but the DNS resolution is where the - problem lies. - -12. If you still have problems, go to the support web sites mentioned above - and read the information and documentation there. - -Common problems -=============== - -1. Packets go out on the ppp0 interface but don't come back on the cm0 - interface. It looks like I'm connected but I can't even ping any - numerical IP addresses. (This happens predominantly on Debian systems due - to a default boot-time configuration script.) - -Solution - As root ``echo 0 > /proc/sys/net/ipv4/conf/cm0/rp_filter`` so it - can share the same IP address as the ppp0 interface. Note that this - command should probably be added to the /etc/ppp/cablemodem script - *right*between* the "/sbin/ifconfig" and "/sbin/cmconfig" commands. - You may need to do this to /proc/sys/net/ipv4/conf/ppp0/rp_filter as well. - If you do this to /proc/sys/net/ipv4/conf/default/rp_filter on each reboot - (in rc.local or some such) then any interfaces can share the same IP - addresses. - -2. I get "unresolved symbol" error messages on executing ``insmod sb1000.o``. - -Solution - You probably have a non-matching kernel source tree and - /usr/include/linux and /usr/include/asm header files. Make sure you - install the correct versions of the header files in these two directories. - Then rebuild and reinstall the kernel. - -3. When isapnp runs it reports an error, and my SB1000 card isn't working. - -Solution - There's a problem with later versions of isapnp using the "(CHECK)" - option in the lines that allocate the two I/O addresses for the SB1000 card. - This first popped up on RH 6.0. Delete "(CHECK)" for the SB1000 I/O addresses. - Make sure they don't conflict with any other pieces of hardware first! Then - rerun isapnp and go from there. - -4. I can't execute the /etc/ppp/ppp@gi-on file. - -Solution - As root do ``chmod ug+x /etc/ppp/ppp@gi-on``. - -5. The firewall script isn't working (with 2.2.x and higher kernels). - -Solution - Use the ipfwadm2ipchains script referenced above to convert the - /etc/ppp/firewall script from the deprecated ipfwadm commands to ipchains. - -6. I'm getting *tons* of firewall deny messages in the /var/kern.log, - /var/messages, and/or /var/syslog files, and they're filling up my /var - partition!!! - -Solution - First, tell your ISP that you're receiving DoS (Denial of Service) - and/or portscanning (UDP connection attempts) attacks! Look over the deny - messages to figure out what the attack is and where it's coming from. Next, - edit /etc/ppp/cablemodem and make sure the ",nobroadcast" option is turned on - to the "cmconfig" command (uncomment that line). If you're not receiving these - denied packets on your broadcast interface (IP address xxx.yyy.zzz.255 - typically), then someone is attacking your machine in particular. Be careful - out there.... - -7. Everything seems to work fine but my computer locks up after a while - (and typically during a lengthy download through the cable modem)! - -Solution - You may need to add a short delay in the driver to 'slow down' the - SURFboard because your PC might not be able to keep up with the transfer rate - of the SB1000. To do this, it's probably best to download Franco's - sb1000-1.1.2.tar.gz archive and build and install sb1000.o manually. You'll - want to edit the 'Makefile' and look for the 'SB1000_DELAY' - define. Uncomment those 'CFLAGS' lines (and comment out the default ones) - and try setting the delay to something like 60 microseconds with: - '-DSB1000_DELAY=60'. Then do ``make`` and as root ``make install`` and try - it out. If it still doesn't work or you like playing with the driver, you may - try other numbers. Remember though that the higher the delay, the slower the - driver (which slows down the rest of the PC too when it is actively - used). Thanks to Ed Daiga for this tip! - -Credits -======= - -This README came from Franco Venturi's original README file which is -still supplied with his driver .tar.gz archive. I and all other sb1000 users -owe Franco a tremendous "Thank you!" Additional thanks goes to Carl Patten -and Ralph Bonnell who are now managing the Linux SB1000 web site, and to -the SB1000 users who reported and helped debug the common problems listed -above. - - - Clemmitt Sigler - csigler@vt.edu diff --git a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst index 8bf411b857d4..5f3885e56f58 100644 --- a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst @@ -70,7 +70,7 @@ the DPSW object that it will probe: Besides the configuration of the actual DPSW object, the dpaa2-switch driver will need the following DPAA2 objects: - * 1 DPMCP - A Management Command Portal object is needed for any interraction + * 1 DPMCP - A Management Command Portal object is needed for any interaction with the MC firmware. * 1 DPBP - A Buffer Pool is used for seeding buffers intended for the Rx path diff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst index 6fc1961492b7..05d822b904b4 100644 --- a/Documentation/networking/device_drivers/ethernet/index.rst +++ b/Documentation/networking/device_drivers/ethernet/index.rst @@ -55,7 +55,6 @@ Contents: ti/cpsw_switchdev ti/am65_nuss_cpsw_switchdev ti/tlan - toshiba/spider_net wangxun/txgbe wangxun/ngbe diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst index 99d95be4d159..43d72c8b713b 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst @@ -1082,6 +1082,11 @@ like flow control, FEC and more. need to replace the cable/transceiver. - Error + * - `total_success_recovery_phy` + - The number of total successful recovery events of any type during + ports reset cycle. + - Error + * - `rx_out_of_buffer` - Number of times receive queue had no software buffers allocated for the adapter's incoming traffic. diff --git a/Documentation/networking/device_drivers/ethernet/toshiba/spider_net.rst b/Documentation/networking/device_drivers/ethernet/toshiba/spider_net.rst deleted file mode 100644 index fe5b32be15cd..000000000000 --- a/Documentation/networking/device_drivers/ethernet/toshiba/spider_net.rst +++ /dev/null @@ -1,202 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -=========================== -The Spidernet Device Driver -=========================== - -Written by Linas Vepstas <linas@austin.ibm.com> - -Version of 7 June 2007 - -Abstract -======== -This document sketches the structure of portions of the spidernet -device driver in the Linux kernel tree. The spidernet is a gigabit -ethernet device built into the Toshiba southbridge commonly used -in the SONY Playstation 3 and the IBM QS20 Cell blade. - -The Structure of the RX Ring. -============================= -The receive (RX) ring is a circular linked list of RX descriptors, -together with three pointers into the ring that are used to manage its -contents. - -The elements of the ring are called "descriptors" or "descrs"; they -describe the received data. This includes a pointer to a buffer -containing the received data, the buffer size, and various status bits. - -There are three primary states that a descriptor can be in: "empty", -"full" and "not-in-use". An "empty" or "ready" descriptor is ready -to receive data from the hardware. A "full" descriptor has data in it, -and is waiting to be emptied and processed by the OS. A "not-in-use" -descriptor is neither empty or full; it is simply not ready. It may -not even have a data buffer in it, or is otherwise unusable. - -During normal operation, on device startup, the OS (specifically, the -spidernet device driver) allocates a set of RX descriptors and RX -buffers. These are all marked "empty", ready to receive data. This -ring is handed off to the hardware, which sequentially fills in the -buffers, and marks them "full". The OS follows up, taking the full -buffers, processing them, and re-marking them empty. - -This filling and emptying is managed by three pointers, the "head" -and "tail" pointers, managed by the OS, and a hardware current -descriptor pointer (GDACTDPA). The GDACTDPA points at the descr -currently being filled. When this descr is filled, the hardware -marks it full, and advances the GDACTDPA by one. Thus, when there is -flowing RX traffic, every descr behind it should be marked "full", -and everything in front of it should be "empty". If the hardware -discovers that the current descr is not empty, it will signal an -interrupt, and halt processing. - -The tail pointer tails or trails the hardware pointer. When the -hardware is ahead, the tail pointer will be pointing at a "full" -descr. The OS will process this descr, and then mark it "not-in-use", -and advance the tail pointer. Thus, when there is flowing RX traffic, -all of the descrs in front of the tail pointer should be "full", and -all of those behind it should be "not-in-use". When RX traffic is not -flowing, then the tail pointer can catch up to the hardware pointer. -The OS will then note that the current tail is "empty", and halt -processing. - -The head pointer (somewhat mis-named) follows after the tail pointer. -When traffic is flowing, then the head pointer will be pointing at -a "not-in-use" descr. The OS will perform various housekeeping duties -on this descr. This includes allocating a new data buffer and -dma-mapping it so as to make it visible to the hardware. The OS will -then mark the descr as "empty", ready to receive data. Thus, when there -is flowing RX traffic, everything in front of the head pointer should -be "not-in-use", and everything behind it should be "empty". If no -RX traffic is flowing, then the head pointer can catch up to the tail -pointer, at which point the OS will notice that the head descr is -"empty", and it will halt processing. - -Thus, in an idle system, the GDACTDPA, tail and head pointers will -all be pointing at the same descr, which should be "empty". All of the -other descrs in the ring should be "empty" as well. - -The show_rx_chain() routine will print out the locations of the -GDACTDPA, tail and head pointers. It will also summarize the contents -of the ring, starting at the tail pointer, and listing the status -of the descrs that follow. - -A typical example of the output, for a nearly idle system, might be:: - - net eth1: Total number of descrs=256 - net eth1: Chain tail located at descr=20 - net eth1: Chain head is at 20 - net eth1: HW curr desc (GDACTDPA) is at 21 - net eth1: Have 1 descrs with stat=x40800101 - net eth1: HW next desc (GDACNEXTDA) is at 22 - net eth1: Last 255 descrs with stat=xa0800000 - -In the above, the hardware has filled in one descr, number 20. Both -head and tail are pointing at 20, because it has not yet been emptied. -Meanwhile, hw is pointing at 21, which is free. - -The "Have nnn decrs" refers to the descr starting at the tail: in this -case, nnn=1 descr, starting at descr 20. The "Last nnn descrs" refers -to all of the rest of the descrs, from the last status change. The "nnn" -is a count of how many descrs have exactly the same status. - -The status x4... corresponds to "full" and status xa... corresponds -to "empty". The actual value printed is RXCOMST_A. - -In the device driver source code, a different set of names are -used for these same concepts, so that:: - - "empty" == SPIDER_NET_DESCR_CARDOWNED == 0xa - "full" == SPIDER_NET_DESCR_FRAME_END == 0x4 - "not in use" == SPIDER_NET_DESCR_NOT_IN_USE == 0xf - - -The RX RAM full bug/feature -=========================== - -As long as the OS can empty out the RX buffers at a rate faster than -the hardware can fill them, there is no problem. If, for some reason, -the OS fails to empty the RX ring fast enough, the hardware GDACTDPA -pointer will catch up to the head, notice the not-empty condition, -ad stop. However, RX packets may still continue arriving on the wire. -The spidernet chip can save some limited number of these in local RAM. -When this local ram fills up, the spider chip will issue an interrupt -indicating this (GHIINT0STS will show ERRINT, and the GRMFLLINT bit -will be set in GHIINT1STS). When the RX ram full condition occurs, -a certain bug/feature is triggered that has to be specially handled. -This section describes the special handling for this condition. - -When the OS finally has a chance to run, it will empty out the RX ring. -In particular, it will clear the descriptor on which the hardware had -stopped. However, once the hardware has decided that a certain -descriptor is invalid, it will not restart at that descriptor; instead -it will restart at the next descr. This potentially will lead to a -deadlock condition, as the tail pointer will be pointing at this descr, -which, from the OS point of view, is empty; the OS will be waiting for -this descr to be filled. However, the hardware has skipped this descr, -and is filling the next descrs. Since the OS doesn't see this, there -is a potential deadlock, with the OS waiting for one descr to fill, -while the hardware is waiting for a different set of descrs to become -empty. - -A call to show_rx_chain() at this point indicates the nature of the -problem. A typical print when the network is hung shows the following:: - - net eth1: Spider RX RAM full, incoming packets might be discarded! - net eth1: Total number of descrs=256 - net eth1: Chain tail located at descr=255 - net eth1: Chain head is at 255 - net eth1: HW curr desc (GDACTDPA) is at 0 - net eth1: Have 1 descrs with stat=xa0800000 - net eth1: HW next desc (GDACNEXTDA) is at 1 - net eth1: Have 127 descrs with stat=x40800101 - net eth1: Have 1 descrs with stat=x40800001 - net eth1: Have 126 descrs with stat=x40800101 - net eth1: Last 1 descrs with stat=xa0800000 - -Both the tail and head pointers are pointing at descr 255, which is -marked xa... which is "empty". Thus, from the OS point of view, there -is nothing to be done. In particular, there is the implicit assumption -that everything in front of the "empty" descr must surely also be empty, -as explained in the last section. The OS is waiting for descr 255 to -become non-empty, which, in this case, will never happen. - -The HW pointer is at descr 0. This descr is marked 0x4.. or "full". -Since its already full, the hardware can do nothing more, and thus has -halted processing. Notice that descrs 0 through 254 are all marked -"full", while descr 254 and 255 are empty. (The "Last 1 descrs" is -descr 254, since tail was at 255.) Thus, the system is deadlocked, -and there can be no forward progress; the OS thinks there's nothing -to do, and the hardware has nowhere to put incoming data. - -This bug/feature is worked around with the spider_net_resync_head_ptr() -routine. When the driver receives RX interrupts, but an examination -of the RX chain seems to show it is empty, then it is probable that -the hardware has skipped a descr or two (sometimes dozens under heavy -network conditions). The spider_net_resync_head_ptr() subroutine will -search the ring for the next full descr, and the driver will resume -operations there. Since this will leave "holes" in the ring, there -is also a spider_net_resync_tail_ptr() that will skip over such holes. - -As of this writing, the spider_net_resync() strategy seems to work very -well, even under heavy network loads. - - -The TX ring -=========== -The TX ring uses a low-watermark interrupt scheme to make sure that -the TX queue is appropriately serviced for large packet sizes. - -For packet sizes greater than about 1KBytes, the kernel can fill -the TX ring quicker than the device can drain it. Once the ring -is full, the netdev is stopped. When there is room in the ring, -the netdev needs to be reawakened, so that more TX packets are placed -in the ring. The hardware can empty the ring about four times per jiffy, -so its not appropriate to wait for the poll routine to refill, since -the poll routine runs only once per jiffy. The low-watermark mechanism -marks a descr about 1/4th of the way from the bottom of the queue, so -that an interrupt is generated when the descr is processed. This -interrupt wakes up the netdev, which can then refill the queue. -For large packets, this mechanism generates a relatively small number -of interrupts, about 1K/sec. For smaller packets, this will drop to zero -interrupts, as the hardware can empty the queue faster than the kernel -can fill it. diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst index 0dd30a84ce25..a254af25b7ef 100644 --- a/Documentation/networking/device_drivers/index.rst +++ b/Documentation/networking/device_drivers/index.rst @@ -9,7 +9,6 @@ Contents: :maxdepth: 2 atm/index - cable/index can/index cellular/index ethernet/index diff --git a/Documentation/networking/devlink/bnxt.rst b/Documentation/networking/devlink/bnxt.rst index a4fb27663cd6..9a8b3d76d11f 100644 --- a/Documentation/networking/devlink/bnxt.rst +++ b/Documentation/networking/devlink/bnxt.rst @@ -24,6 +24,8 @@ Parameters - Permanent * - ``enable_remote_dev_reset`` - Runtime + * - ``enable_roce`` + - Permanent The ``bnxt`` driver also implements the following driver-specific parameters. diff --git a/Documentation/networking/devlink/ice.rst b/Documentation/networking/devlink/ice.rst index e3972d03cea0..792e9f8c846a 100644 --- a/Documentation/networking/devlink/ice.rst +++ b/Documentation/networking/devlink/ice.rst @@ -69,6 +69,17 @@ Parameters To verify that value has been set: $ devlink dev param show pci/0000:16:00.0 name tx_scheduling_layers + * - ``msix_vec_per_pf_max`` + - driverinit + - Set the max MSI-X that can be used by the PF, rest can be utilized for + SRIOV. The range is from min value set in msix_vec_per_pf_min to + 2k/number of ports. + * - ``msix_vec_per_pf_min`` + - driverinit + - Set the min MSI-X that will be used by the PF. This value inform how many + MSI-X will be allocated statically. The range is from 2 to value set + in msix_vec_per_pf_max. + .. list-table:: Driver specific parameters implemented :widths: 5 5 90 diff --git a/Documentation/networking/devlink/mlx5.rst b/Documentation/networking/devlink/mlx5.rst index 41618538fc70..7febe0aecd53 100644 --- a/Documentation/networking/devlink/mlx5.rst +++ b/Documentation/networking/devlink/mlx5.rst @@ -280,6 +280,10 @@ Description of the vnic counters: number of packets handled by the VNIC experiencing unexpected steering failure (at any point in steering flow owned by the VNIC, including the FDB for the eswitch owner). +- icm_consumption + amount of Interconnect Host Memory (ICM) consumed by the vnic in + granularity of 4KB. ICM is host memory allocated by SW upon HCA request + and is used for storing data structures that control HCA operation. User commands examples: diff --git a/Documentation/networking/devlink/sfc.rst b/Documentation/networking/devlink/sfc.rst index db64a1bd9733..0398d59ea184 100644 --- a/Documentation/networking/devlink/sfc.rst +++ b/Documentation/networking/devlink/sfc.rst @@ -5,7 +5,7 @@ sfc devlink support =================== This document describes the devlink features implemented by the ``sfc`` -device driver for the ef100 device. +device driver for the ef10 and ef100 devices. Info versions ============= @@ -18,6 +18,10 @@ The ``sfc`` driver reports the following versions * - Name - Type - Description + * - ``fw.bundle_id`` + - stored + - Version of the firmware "bundle" image that was last used to update + multiple components. * - ``fw.mgmt.suc`` - running - For boards where the management function is split between multiple @@ -55,3 +59,13 @@ The ``sfc`` driver reports the following versions * - ``fw.uefi`` - running - UEFI driver version (No UNDI support). + +Flash Update +============ + +The ``sfc`` driver implements support for flash update using the +``devlink-flash`` interface. It supports updating the device flash using a +combined flash image ("bundle") that contains multiple components (on ef10, +typically ``fw.mgmt``, ``fw.app``, ``fw.exprom`` and ``fw.uefi``). + +The driver does not support any overwrite mask flags. diff --git a/Documentation/networking/devmem.rst b/Documentation/networking/devmem.rst index d95363645331..eb678ca45496 100644 --- a/Documentation/networking/devmem.rst +++ b/Documentation/networking/devmem.rst @@ -256,7 +256,7 @@ Testing ======= More realistic example code can be found in the kernel source under -``tools/testing/selftests/net/ncdevmem.c`` +``tools/testing/selftests/drivers/net/hw/ncdevmem.c`` ncdevmem is a devmem TCP netcat. It works very similarly to netcat, but receives data directly into a udmabuf. @@ -268,8 +268,7 @@ ncdevmem has a validation mode as well that expects a repeating pattern of incoming data and validates it as such. For example, you can launch ncdevmem on the server by:: - ncdevmem -s <server IP> -c <client IP> -f eth1 -d 3 -n 0000:06:00.0 -l \ - -p 5201 -v 7 + ncdevmem -s <server IP> -c <client IP> -f <ifname> -l -p 5201 -v 7 On client side, use regular netcat to send TX data to ncdevmem process on the server:: diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 3770a2294509..b6e9af4d0f1b 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -1934,7 +1934,7 @@ ETHTOOL_A_RSS_INDIR attribute returns RSS indirection table where each byte indicates queue number. ETHTOOL_A_RSS_INPUT_XFRM attribute is a bitmap indicating the type of transformation applied to the input protocol fields before given to the RSS -hfunc. Current supported option is symmetric-xor. +hfunc. Current supported options are symmetric-xor and symmetric-or-xor. PLCA_GET_CFG ============ 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/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 363b4950d542..5c63ab928b97 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -705,6 +705,8 @@ tcp_retries2 - INTEGER seconds and is a lower bound for the effective timeout. TCP will effectively time out at the first RTO which exceeds the hypothetical timeout. + If tcp_rto_max_ms is decreased, it is recommended to also + change tcp_retries2. RFC 1122 recommends at least 100 seconds for the timeout, which corresponds to a value of at least 8. @@ -1227,8 +1229,8 @@ tcp_pingpong_thresh - INTEGER tcp_rto_min_us - INTEGER Minimal TCP retransmission timeout (in microseconds). Note that the rto_min route option has the highest precedence for configuring this - setting, followed by the TCP_BPF_RTO_MIN socket option, followed by - this tcp_rto_min_us sysctl. + setting, followed by the TCP_BPF_RTO_MIN and TCP_RTO_MIN_US socket + options, followed by this tcp_rto_min_us sysctl. The recommended practice is to use a value less or equal to 200000 microseconds. @@ -1237,6 +1239,17 @@ tcp_rto_min_us - INTEGER Default: 200000 +tcp_rto_max_ms - INTEGER + Maximal TCP retransmission timeout (in ms). + Note that TCP_RTO_MAX_MS socket option has higher precedence. + + When changing tcp_rto_max_ms, it is important to understand + that tcp_retries2 might need a change. + + Possible Values: 1000 - 120,000 + + Default: 120,000 + UDP variables ============= diff --git a/Documentation/networking/iso15765-2.rst b/Documentation/networking/iso15765-2.rst index 0e9d96074178..37ebb2c417cb 100644 --- a/Documentation/networking/iso15765-2.rst +++ b/Documentation/networking/iso15765-2.rst @@ -369,8 +369,8 @@ to their default. addr.can_family = AF_CAN; addr.can_ifindex = if_nametoindex("can0"); - addr.tp.tx_id = 0x18DA42F1 | CAN_EFF_FLAG; - addr.tp.rx_id = 0x18DAF142 | CAN_EFF_FLAG; + addr.can_addr.tp.tx_id = 0x18DA42F1 | CAN_EFF_FLAG; + addr.can_addr.tp.rx_id = 0x18DAF142 | CAN_EFF_FLAG; ret = bind(s, (struct sockaddr *)&addr, sizeof(addr)); if (ret < 0) diff --git a/Documentation/networking/j1939.rst b/Documentation/networking/j1939.rst index 544bad175aae..45f02efe3df5 100644 --- a/Documentation/networking/j1939.rst +++ b/Documentation/networking/j1939.rst @@ -66,6 +66,90 @@ the library exclusively, or by the in-kernel system exclusively. J1939 concepts ============== +Data Sent to the J1939 Stack +---------------------------- + +The data buffers sent to the J1939 stack from user space are not CAN frames +themselves. Instead, they are payloads that the J1939 stack converts into +proper CAN frames based on the size of the buffer and the type of transfer. The +size of the buffer influences how the stack processes the data and determines +the internal code path used for the transfer. + +**Handling of Different Buffer Sizes:** + +- **Buffers with a size of 8 bytes or less:** + + - These are handled as simple sessions internally within the stack. + + - The stack converts the buffer directly into a single CAN frame without + fragmentation. + + - This type of transfer does not require an actual client (receiver) on the + receiving side. + +- **Buffers up to 1785 bytes:** + + - These are automatically handled as J1939 Transport Protocol (TP) transfers. + + - Internally, the stack splits the buffer into multiple 8-byte CAN frames. + + - TP transfers can be unicast or broadcast. + + - **Broadcast TP:** Does not require a receiver on the other side and can be + used in broadcast scenarios. + + - **Unicast TP:** Requires an active receiver (client) on the other side to + acknowledge the transfer. + +- **Buffers from 1786 bytes up to 111 MiB:** + + - These are handled as ISO 11783 Extended Transport Protocol (ETP) transfers. + + - ETP transfers are used for larger payloads and are split into multiple CAN + frames internally. + + - **ETP transfers (unicast):** Require a receiver on the other side to + process the incoming data and acknowledge each step of the transfer. + + - ETP transfers cannot be broadcast like TP transfers, and always require a + receiver for operation. + +**Non-Blocking Operation with `MSG_DONTWAIT`:** + +The J1939 stack supports non-blocking operation when used in combination with +the `MSG_DONTWAIT` flag. In this mode, the stack attempts to take as much data +as the available memory for the socket allows. It returns the amount of data +that was successfully taken, and it is the responsibility of user space to +monitor this value and handle partial transfers. + +- If the stack cannot take the entire buffer, it returns the number of bytes + successfully taken, and user space should handle the remainder. + +- **Error handling:** When using `MSG_DONTWAIT`, the user must rely on the + error queue to detect transfer errors. See the **SO_J1939_ERRQUEUE** section + for details on how to subscribe to error notifications. Without the error + queue, there is no other way for user space to be notified of transfer errors + during non-blocking operations. + +**Behavior and Requirements:** + +- **Simple transfers (<= 8 bytes):** Do not require a receiver on the other + side, making them easy to send without needing address claiming or + coordination with a destination. + +- **Unicast TP/ETP:** Requires a receiver on the other side to complete the + transfer. The receiver must acknowledge the transfer for the session to + proceed successfully. + +- **Broadcast TP:** Allows sending data without a receiver, but only works for + TP transfers. ETP cannot be broadcast and always needs a receiving client. + +These different behaviors depend heavily on the size of the buffer provided to +the stack, and the appropriate transport mechanism (TP or ETP) is selected +based on the payload size. The stack automatically manages the fragmentation +and reassembly of large payloads and ensures that the correct CAN frames are +generated and transmitted for each session. + PGN --- @@ -338,6 +422,459 @@ with ``cmsg_level == SOL_J1939 && cmsg_type == SCM_J1939_DEST_ADDR``, } } +setsockopt(2) +^^^^^^^^^^^^^ + +The ``setsockopt(2)`` function is used to configure various socket-level +options for J1939 communication. The following options are supported: + +``SO_J1939_FILTER`` +~~~~~~~~~~~~~~~~~~~ + +The ``SO_J1939_FILTER`` option is essential when the default behavior of +``bind(2)`` and ``connect(2)`` is insufficient for specific use cases. By +default, ``bind(2)`` and ``connect(2)`` allow a socket to be associated with a +single unicast or broadcast address. However, there are scenarios where finer +control over the incoming messages is required, such as filtering by Parameter +Group Number (PGN) rather than by addresses. + +For example, in a system where multiple types of J1939 messages are being +transmitted, a process might only be interested in a subset of those messages, +such as specific PGNs, and not want to receive all messages destined for its +address or broadcast to the bus. + +By applying the ``SO_J1939_FILTER`` option, you can filter messages based on: + +- **Source Address (SA)**: Filter messages coming from specific source + addresses. + +- **Source Name**: Filter messages coming from ECUs with specific NAME + identifiers. + +- **Parameter Group Number (PGN)**: Focus on receiving messages with specific + PGNs, filtering out irrelevant ones. + +This filtering mechanism is particularly useful when: + +- You want to receive a subset of messages based on their PGNs, even if the + address is the same. + +- You need to handle both broadcast and unicast messages but only care about + certain message types or parameters. + +- The ``bind(2)`` and ``connect(2)`` functions only allow binding to a single + address, which might not be sufficient if the process needs to handle multiple + PGNs but does not want to open multiple sockets. + +To remove existing filters, you can pass ``optval == NULL`` or ``optlen == 0`` +to ``setsockopt(2)``. This will clear all currently set filters. If you want to +**update** the set of filters, you must pass the updated filter set to +``setsockopt(2)``, as the new filter set will **replace** the old one entirely. +This behavior ensures that any previous filter configuration is discarded and +only the new set is applied. + +Example of removing all filters: + +.. code-block:: c + + setsockopt(sock, SOL_CAN_J1939, SO_J1939_FILTER, NULL, 0); + +**Maximum number of filters:** The maximum amount of filters that can be +applied using ``SO_J1939_FILTER`` is defined by ``J1939_FILTER_MAX``, which is +set to 512. This means you can configure up to 512 individual filters to match +your specific filtering needs. + +Practical use case: **Monitoring Address Claiming** + +One practical use case is monitoring the J1939 address claiming process by +filtering for specific PGNs related to address claiming. This allows a process +to monitor and handle address claims without processing unrelated messages. + +Example: + +.. code-block:: c + + struct j1939_filter filt[] = { + { + .pgn = J1939_PGN_ADDRESS_CLAIMED, + .pgn_mask = J1939_PGN_PDU1_MAX, + }, { + .pgn = J1939_PGN_REQUEST, + .pgn_mask = J1939_PGN_PDU1_MAX, + }, { + .pgn = J1939_PGN_ADDRESS_COMMANDED, + .pgn_mask = J1939_PGN_MAX, + }, + }; + setsockopt(sock, SOL_CAN_J1939, SO_J1939_FILTER, &filt, sizeof(filt)); + +In this example, the socket will only receive messages with the PGNs related to +address claiming: ``J1939_PGN_ADDRESS_CLAIMED``, ``J1939_PGN_REQUEST``, and +``J1939_PGN_ADDRESS_COMMANDED``. This is particularly useful in scenarios where +you want to monitor and process address claims without being overwhelmed by +other traffic on the J1939 network. + +``SO_J1939_PROMISC`` +~~~~~~~~~~~~~~~~~~~~ + +The ``SO_J1939_PROMISC`` option enables socket-level promiscuous mode. When +this option is enabled, the socket will receive all J1939 traffic, regardless +of any filters set by ``bind()`` or ``connect()``. This is analogous to +enabling promiscuous mode for an Ethernet interface, where all traffic on the +network segment is captured. + +However, **`SO_J1939_FILTER` has a higher priority** compared to +``SO_J1939_PROMISC``. This means that even in promiscuous mode, you can reduce +the number of packets received by applying specific filters with +`SO_J1939_FILTER`. The filters will limit which packets are passed to the +socket, allowing for more refined traffic selection while promiscuous mode is +active. + +The acceptable value size for this option is ``sizeof(int)``, and the value is +only differentiated between `0` and non-zero. A value of `0` disables +promiscuous mode, while any non-zero value enables it. + +This combination can be useful for debugging or monitoring specific types of +traffic while still capturing a broad set of messages. + +Example: + +.. code-block:: c + + int value = 1; + setsockopt(sock, SOL_CAN_J1939, SO_J1939_PROMISC, &value, sizeof(value)); + +In this example, setting ``value`` to any non-zero value (e.g., `1`) enables +promiscuous mode, allowing the socket to receive all J1939 traffic on the +network. + +``SO_BROADCAST`` +~~~~~~~~~~~~~~~~ + +The ``SO_BROADCAST`` option enables the sending and receiving of broadcast +messages. By default, broadcast messages are disabled for J1939 sockets. When +this option is enabled, the socket will be allowed to send and receive +broadcast packets on the J1939 network. + +Due to the nature of the CAN bus as a shared medium, all messages transmitted +on the bus are visible to all participants. In the context of J1939, +broadcasting refers to using a specific destination address field, where the +destination address is set to a value that indicates the message is intended +for all participants (usually a global address such as 0xFF). Enabling the +broadcast option allows the socket to send and receive such broadcast messages. + +The acceptable value size for this option is ``sizeof(int)``, and the value is +only differentiated between `0` and non-zero. A value of `0` disables the +ability to send and receive broadcast messages, while any non-zero value +enables it. + +Example: + +.. code-block:: c + + int value = 1; + setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &value, sizeof(value)); + +In this example, setting ``value`` to any non-zero value (e.g., `1`) enables +the socket to send and receive broadcast messages. + +``SO_J1939_SEND_PRIO`` +~~~~~~~~~~~~~~~~~~~~~~ + +The ``SO_J1939_SEND_PRIO`` option sets the priority of outgoing J1939 messages +for the socket. In J1939, messages can have different priorities, and lower +numerical values indicate higher priority. This option allows the user to +control the priority of messages sent from the socket by adjusting the priority +bits in the CAN identifier. + +The acceptable value **size** for this option is ``sizeof(int)``, and the value +is expected to be in the range of 0 to 7, where `0` is the highest priority, +and `7` is the lowest. By default, the priority is set to `6` if this option is +not explicitly configured. + +Note that the priority values `0` and `1` can only be set if the process has +the `CAP_NET_ADMIN` capability. These are reserved for high-priority traffic +and require administrative privileges. + +Example: + +.. code-block:: c + + int prio = 3; // Priority value between 0 (highest) and 7 (lowest) + setsockopt(sock, SOL_CAN_J1939, SO_J1939_SEND_PRIO, &prio, sizeof(prio)); + +In this example, the priority is set to `3`, meaning the outgoing messages will +be sent with a moderate priority level. + +``SO_J1939_ERRQUEUE`` +~~~~~~~~~~~~~~~~~~~~~ + +The ``SO_J1939_ERRQUEUE`` option enables the socket to receive error messages +from the error queue, providing diagnostic information about transmission +failures, protocol violations, or other issues that occur during J1939 +communication. Once this option is set, user space is required to handle +``MSG_ERRQUEUE`` messages. + +Setting ``SO_J1939_ERRQUEUE`` to ``0`` will purge any currently present error +messages in the error queue. When enabled, error messages can be retrieved +using the ``recvmsg(2)`` system call. + +When subscribing to the error queue, the following error events can be +accessed: + +- **``J1939_EE_INFO_TX_ABORT``**: Transmission abort errors. +- **``J1939_EE_INFO_RX_RTS``**: Reception of RTS (Request to Send) control + frames. +- **``J1939_EE_INFO_RX_DPO``**: Reception of data packets with Data Page Offset + (DPO). +- **``J1939_EE_INFO_RX_ABORT``**: Reception abort errors. + +The error queue can be used to correlate errors with specific message transfer +sessions using the session ID (``tskey``). The session ID is assigned via the +``SOF_TIMESTAMPING_OPT_ID`` flag, which is set by enabling the +``SO_TIMESTAMPING`` option. + +If ``SO_J1939_ERRQUEUE`` is activated, the user is required to pull messages +from the error queue, meaning that using plain ``recv(2)`` is not sufficient +anymore. The user must use ``recvmsg(2)`` with appropriate flags to handle +error messages. Failure to do so can result in the socket becoming blocked with +unprocessed error messages in the queue. + +It is **recommended** that ``SO_J1939_ERRQUEUE`` be used in combination with +``SO_TIMESTAMPING`` in most cases. This enables proper error handling along +with session tracking and timestamping, providing a more detailed analysis of +message transfers and errors. + +The acceptable value **size** for this option is ``sizeof(int)``, and the value +is only differentiated between ``0`` and non-zero. A value of ``0`` disables +error queue reception and purges any existing error messages, while any +non-zero value enables it. + +Example: + +.. code-block:: c + + int enable = 1; // Enable error queue reception + setsockopt(sock, SOL_CAN_J1939, SO_J1939_ERRQUEUE, &enable, sizeof(enable)); + + // Enable timestamping with session tracking via tskey + int timestamping = SOF_TIMESTAMPING_OPT_ID | SOF_TIMESTAMPING_TX_ACK | + SOF_TIMESTAMPING_TX_SCHED | + SOF_TIMESTAMPING_RX_SOFTWARE | SOF_TIMESTAMPING_OPT_CMSG; + setsockopt(sock, SOL_SOCKET, SO_TIMESTAMPING, ×tamping, + sizeof(timestamping)); + +When enabled, error messages can be retrieved using ``recvmsg(2)``. By +combining ``SO_J1939_ERRQUEUE`` with ``SO_TIMESTAMPING`` (with +``SOF_TIMESTAMPING_OPT_ID`` and ``SOF_TIMESTAMPING_OPT_CMSG`` enabled), the +user can track message transfers, retrieve precise timestamps, and correlate +errors with specific sessions. + +For more information on enabling timestamps and session tracking, refer to the +`SO_TIMESTAMPING` section. + +``SO_TIMESTAMPING`` +~~~~~~~~~~~~~~~~~~~ + +The ``SO_TIMESTAMPING`` option allows the socket to receive timestamps for +various events related to message transmissions and receptions in J1939. This +option is often used in combination with ``SO_J1939_ERRQUEUE`` to provide +detailed diagnostic information, session tracking, and precise timing data for +message transfers. + +In J1939, all payloads provided by user space, regardless of size, are +processed by the kernel as **sessions**. This includes both single-frame +messages (up to 8 bytes) and multi-frame protocols such as the Transport +Protocol (TP) and Extended Transport Protocol (ETP). Even for small, +single-frame messages, the kernel creates a session to manage the transmission +and reception. The concept of sessions allows the kernel to manage various +aspects of the protocol, such as reassembling multi-frame messages and tracking +the status of transmissions. + +When receiving extended error messages from the error queue, the error +information is delivered through a `struct sock_extended_err`, accessible via +the control message (``cmsg``) retrieved using the ``recvmsg(2)`` system call. + +There are two typical origins for the extended error messages in J1939: + +1. ``serr->ee_origin == SO_EE_ORIGIN_TIMESTAMPING``: + + In this case, the `serr->ee_info` field will contain one of the following + timestamp types: + + - ``SCM_TSTAMP_SCHED``: This timestamp is valid for Extended Transport + Protocol (ETP) transfers and simple transfers (8 bytes or less). It + indicates when a message or set of frames has been scheduled for + transmission. + + - For simple transfers (8 bytes or less), it marks the point when the + message is queued and ready to be sent onto the CAN bus. + + - For ETP transfers, it is sent after receiving a CTS (Clear to Send) + frame on the sender side, indicating that a new set of frames has been + scheduled for transmission. + + - The Transport Protocol (TP) case is currently not implemented for this + timestamp. + + - On the receiver side, the counterpart to this event for ETP is + represented by the ``J1939_EE_INFO_RX_DPO`` message, which indicates the + reception of a Data Page Offset (DPO) control frame. + + - ``SCM_TSTAMP_ACK``: This timestamp indicates the acknowledgment of the + message or session. + + - For simple transfers (8 bytes or less), it marks when the message has + been sent and an echo confirmation has been received from the CAN + controller, indicating that the frame was transmitted onto the bus. + + - For multi-frame transfers (TP or ETP), it signifies that the entire + session has been acknowledged, typically after receiving the End of + Message Acknowledgment (EOMA) packet. + +2. ``serr->ee_origin == SO_EE_ORIGIN_LOCAL``: + + In this case, the `serr->ee_info` field will contain one of the following + J1939 stack-specific message types: + + - ``J1939_EE_INFO_TX_ABORT``: This message indicates that the transmission + of a message or session was aborted. The cause of the abort can come from + various sources: + + - **CAN stack failure**: The J1939 stack was unable to pass the frame to + the CAN framework for transmission. + + - **Echo failure**: The J1939 stack did not receive an echo confirmation + from the CAN controller, meaning the frame may not have been successfully + transmitted to the CAN bus. + + - **Protocol-level issues**: For multi-frame transfers (TP/ETP), this + could include protocol-related errors, such as an abort signaled by the + receiver or a timeout at the protocol level, which causes the session to + terminate prematurely. + + - The corresponding error code is stored in ``serr->ee_data`` + (``session->err`` on kernel side), providing additional details about + the specific reason for the abort. + + - ``J1939_EE_INFO_RX_RTS``: This message indicates that the J1939 stack has + received a Request to Send (RTS) control frame, signaling the start of a + multi-frame transfer using the Transport Protocol (TP) or Extended + Transport Protocol (ETP). + + - It informs the receiver that the sender is ready to transmit a + multi-frame message and includes details about the total message size + and the number of frames to be sent. + + - Statistics such as ``J1939_NLA_TOTAL_SIZE``, ``J1939_NLA_PGN``, + ``J1939_NLA_SRC_NAME``, and ``J1939_NLA_DEST_NAME`` are provided along + with the ``J1939_EE_INFO_RX_RTS`` message, giving detailed information + about the incoming transfer. + + - ``J1939_EE_INFO_RX_DPO``: This message indicates that the J1939 stack has + received a Data Page Offset (DPO) control frame, which is part of the + Extended Transport Protocol (ETP). + + - The DPO frame signals the continuation of an ETP multi-frame message by + indicating the offset position in the data being transferred. It helps + the receiver manage large data sets by identifying which portion of the + message is being received. + + - It is typically paired with a corresponding ``SCM_TSTAMP_SCHED`` event + on the sender side, which indicates when the next set of frames is + scheduled for transmission. + + - This event includes statistics such as ``J1939_NLA_BYTES_ACKED``, which + tracks the number of bytes acknowledged up to that point in the session. + + - ``J1939_EE_INFO_RX_ABORT``: This message indicates that the reception of a + multi-frame message (Transport Protocol or Extended Transport Protocol) has + been aborted. + + - The abort can be triggered by protocol-level errors such as timeouts, an + unexpected frame, or a specific abort request from the sender. + + - This message signals that the receiver cannot continue processing the + transfer, and the session is terminated. + + - The corresponding error code is stored in ``serr->ee_data`` + (``session->err`` on kernel side ), providing further details about the + reason for the abort, such as protocol violations or timeouts. + + - After receiving this message, the receiver discards the partially received + frames, and the multi-frame session is considered incomplete. + +In both cases, if ``SOF_TIMESTAMPING_OPT_ID`` is enabled, ``serr->ee_data`` +will be set to the session’s unique identifier (``session->tskey``). This +allows user space to track message transfers by their session identifier across +multiple frames or stages. + +In all other cases, ``serr->ee_errno`` will be set to ``ENOMSG``, except for +the ``J1939_EE_INFO_TX_ABORT`` and ``J1939_EE_INFO_RX_ABORT`` cases, where the +kernel sets ``serr->ee_data`` to the error stored in ``session->err``. All +protocol-specific errors are converted to standard kernel error values and +stored in ``session->err``. These error values are unified across system calls +and ``serr->ee_errno``. Some of the known error values are described in the +`Error Codes in the J1939 Stack` section. + +When the `J1939_EE_INFO_RX_RTS` message is provided, it will include the +following statistics for multi-frame messages (TP and ETP): + + - ``J1939_NLA_TOTAL_SIZE``: Total size of the message in the session. + - ``J1939_NLA_PGN``: Parameter Group Number (PGN) identifying the message type. + - ``J1939_NLA_SRC_NAME``: 64-bit name of the source ECU. + - ``J1939_NLA_DEST_NAME``: 64-bit name of the destination ECU. + - ``J1939_NLA_SRC_ADDR``: 8-bit source address of the sending ECU. + - ``J1939_NLA_DEST_ADDR``: 8-bit destination address of the receiving ECU. + +- For other messages (including single-frame messages), only the following + statistic is included: + + - ``J1939_NLA_BYTES_ACKED``: Number of bytes successfully acknowledged in the + session. + +The key flags for ``SO_TIMESTAMPING`` include: + +- ``SOF_TIMESTAMPING_OPT_ID``: Enables the use of a unique session identifier + (``tskey``) for each transfer. This identifier helps track message transfers + and errors as distinct sessions in user space. When this option is enabled, + ``serr->ee_data`` will be set to ``session->tskey``. + +- ``SOF_TIMESTAMPING_OPT_CMSG``: Sends timestamp information through control + messages (``struct scm_timestamping``), allowing the application to retrieve + timestamps alongside the data. + +- ``SOF_TIMESTAMPING_TX_SCHED``: Provides the timestamp for when a message is + scheduled for transmission (``SCM_TSTAMP_SCHED``). + +- ``SOF_TIMESTAMPING_TX_ACK``: Provides the timestamp for when a message + transmission is fully acknowledged (``SCM_TSTAMP_ACK``). + +- ``SOF_TIMESTAMPING_RX_SOFTWARE``: Provides timestamps for reception-related + events (e.g., ``J1939_EE_INFO_RX_RTS``, ``J1939_EE_INFO_RX_DPO``, + ``J1939_EE_INFO_RX_ABORT``). + +These flags enable detailed monitoring of message lifecycles, including +transmission scheduling, acknowledgments, reception timestamps, and gathering +detailed statistics about the communication session, especially for multi-frame +payloads like TP and ETP. + +Example: + +.. code-block:: c + + // Enable timestamping with various options, including session tracking and + // statistics + int sock_opt = SOF_TIMESTAMPING_OPT_CMSG | + SOF_TIMESTAMPING_TX_ACK | + SOF_TIMESTAMPING_TX_SCHED | + SOF_TIMESTAMPING_OPT_ID | + SOF_TIMESTAMPING_RX_SOFTWARE; + + setsockopt(sock, SOL_SOCKET, SO_TIMESTAMPING, &sock_opt, sizeof(sock_opt)); + + + Dynamic Addressing ------------------ @@ -458,3 +995,141 @@ Send: }; sendto(sock, dat, sizeof(dat), 0, (const struct sockaddr *)&saddr, sizeof(saddr)); + + +Error Codes in the J1939 Stack +------------------------------ + +This section lists all potential kernel error codes that can be exposed to user +space when interacting with the J1939 stack. It includes both standard error +codes and those derived from protocol-specific abort codes. + +- ``EAGAIN``: Operation would block; retry may succeed. One common reason is + that an active TP or ETP session exists, and an attempt was made to start a + new overlapping TP or ETP session between the same peers. + +- ``ENETDOWN``: Network is down. This occurs when the CAN interface is switched + to the "down" state. + +- ``ENOBUFS``: No buffer space available. This error occurs when the CAN + interface's transmit (TX) queue is full, and no more messages can be queued. + +- ``EOVERFLOW``: Value too large for defined data type. In J1939, this can + happen if the requested data lies outside of the queued buffer. For example, + if a CTS (Clear to Send) requests an offset not available in the kernel buffer + because user space did not provide enough data. + +- ``EBUSY``: Device or resource is busy. For example, this occurs if an + identical session is already active and the stack is unable to recover from + the condition. + +- ``EACCES``: Permission denied. This error can occur, for example, when + attempting to send broadcast messages, but the socket is not configured with + ``SO_BROADCAST``. + +- ``EADDRNOTAVAIL``: Address not available. This error occurs in cases such as: + + - When attempting to use ``getsockname(2)`` to retrieve the peer's address, + but the socket is not connected. + + - When trying to send data to or from a NAME, but address claiming for the + NAME was not performed or detected by the stack. + +- ``EBADFD``: File descriptor in bad state. This error can occur if: + + - Attempting to send data to an unbound socket. + + - The socket is bound but has no source name, and the source address is + ``J1939_NO_ADDR``. + + - The ``can_ifindex`` is incorrect. + +- ``EFAULT``: Bad address. Occurs mostly when the stack can't copy from or to a + sockptr, when there is insufficient data from user space, or when the buffer + provided by user space is not large enough for the requested data. + +- ``EINTR``: A signal occurred before any data was transmitted; see ``signal(7)``. + +- ``EINVAL``: Invalid argument passed. For example: + + - ``msg->msg_namelen`` is less than ``J1939_MIN_NAMELEN``. + + - ``addr->can_family`` is not equal to ``AF_CAN``. + + - An incorrect PGN was provided. + +- ``ENODEV``: No such device. This happens when the CAN network device cannot + be found for the provided ``can_ifindex`` or if ``can_ifindex`` is 0. + +- ``ENOMEM``: Out of memory. Typically related to issues with memory allocation + in the stack. + +- ``ENOPROTOOPT``: Protocol not available. This can occur when using + ``getsockopt(2)`` or ``setsockopt(2)`` if the requested socket option is not + available. + +- ``EDESTADDRREQ``: Destination address required. This error occurs: + + - In the case of ``connect(2)``, if the ``struct sockaddr *uaddr`` is ``NULL``. + + - In the case of ``send*(2)``, if there is an attempt to send an ETP message + to a broadcast address. + +- ``EDOM``: Argument out of domain. This error may happen if attempting to send + a TP or ETP message to a PGN that is reserved for control PGNs for TP or ETP + operations. + +- ``EIO``: I/O error. This can occur if the amount of data provided to the + socket for a TP or ETP session does not match the announced amount of data for + the session. + +- ``ENOENT``: No such file or directory. This can happen when the stack + attempts to transfer CTS or EOMA but cannot find a matching receiving socket + anymore. + +- ``ENOIOCTLCMD``: No ioctls are available for the socket layer. + +- ``EPERM``: Operation not permitted. For example, this can occur if a + requested action requires ``CAP_NET_ADMIN`` privileges. + +- ``ENETUNREACH``: Network unreachable. Most likely, this occurs when frames + cannot be transmitted to the CAN bus. + +- ``ETIME``: Timer expired. This can happen if a timeout occurs while + attempting to send a simple message, for example, when an echo message from + the controller is not received. + +- ``EPROTO``: Protocol error. + + - Used for various protocol-level errors in J1939, including: + + - Duplicate sequence number. + + - Unexpected EDPO or ECTS packet. + + - Invalid PGN or offset in EDPO/ECTS. + + - Number of EDPO packets exceeded CTS allowance. + + - Any other protocol-level error. + +- ``EMSGSIZE``: Message too long. + +- ``ENOMSG``: No message available. + +- ``EALREADY``: The ECU is already engaged in one or more connection-managed + sessions and cannot support another. + +- ``EHOSTUNREACH``: A timeout occurred, and the session was aborted. + +- ``EBADMSG``: CTS (Clear to Send) messages were received during an active data + transfer, causing an abort. + +- ``ENOTRECOVERABLE``: The maximum retransmission request limit was reached, + and the session cannot recover. + +- ``ENOTCONN``: An unexpected data transfer packet was received. + +- ``EILSEQ``: A bad sequence number was received, and the software could not + recover. + diff --git a/Documentation/networking/kcm.rst b/Documentation/networking/kcm.rst index db0f5560ac1c..71f44d0beaa3 100644 --- a/Documentation/networking/kcm.rst +++ b/Documentation/networking/kcm.rst @@ -200,7 +200,7 @@ while. Example use:: setsockopt(kcmfd, SOL_KCM, KCM_RECV_DISABLE, &val, sizeof(val)) -BFP programs for message delineation +BPF programs for message delineation ------------------------------------ BPF programs can be compiled using the BPF LLVM backend. For example, diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst index 03e1d3610333..5bfab01eff5a 100644 --- a/Documentation/networking/mptcp-sysctl.rst +++ b/Documentation/networking/mptcp-sysctl.rst @@ -30,6 +30,10 @@ allow_join_initial_addr_port - BOOLEAN Default: 1 +available_path_managers - STRING + Shows the available path managers choices that are registered. More + path managers may be available, but not loaded. + available_schedulers - STRING Shows the available schedulers choices that are registered. More packet schedulers may be available, but not loaded. @@ -72,6 +76,23 @@ enabled - BOOLEAN Default: 1 (enabled) +path_manager - STRING + Set the default path manager name to use for each new MPTCP + socket. In-kernel path management will control subflow + connections and address advertisements according to + per-namespace values configured over the MPTCP netlink + API. Userspace path management puts per-MPTCP-connection subflow + connection decisions and address advertisements under control of + a privileged userspace program, at the cost of more netlink + traffic to propagate all of the related events and commands. + + This is a per-namespace sysctl. + + * "kernel" - In-kernel path manager + * "userspace" - Userspace path manager + + Default: "kernel" + pm_type - INTEGER Set the default path manager type to use for each new MPTCP socket. In-kernel path management will control subflow @@ -84,6 +105,8 @@ pm_type - INTEGER This is a per-namespace sysctl. + Deprecated since v6.15, use path_manager instead. + * 0 - In-kernel path manager * 1 - Userspace path manager diff --git a/Documentation/networking/napi.rst b/Documentation/networking/napi.rst index f970a2be271a..d0e3953cae6a 100644 --- a/Documentation/networking/napi.rst +++ b/Documentation/networking/napi.rst @@ -171,12 +171,43 @@ a channel as an IRQ/NAPI which services queues of a given type. For example, a configuration of 1 ``rx``, 1 ``tx`` and 1 ``combined`` channel is expected to utilize 3 interrupts, 2 Rx and 2 Tx queues. +Persistent NAPI config +---------------------- + +Drivers often allocate and free NAPI instances dynamically. This leads to loss +of NAPI-related user configuration each time NAPI instances are reallocated. +The netif_napi_add_config() API prevents this loss of configuration by +associating each NAPI instance with a persistent NAPI configuration based on +a driver defined index value, like a queue number. + +Using this API allows for persistent NAPI IDs (among other settings), which can +be beneficial to userspace programs using ``SO_INCOMING_NAPI_ID``. See the +sections below for other NAPI configuration settings. + +Drivers should try to use netif_napi_add_config() whenever possible. + User API ======== User interactions with NAPI depend on NAPI instance ID. The instance IDs are only visible to the user thru the ``SO_INCOMING_NAPI_ID`` socket option. -It's not currently possible to query IDs used by a given device. + +Users can query NAPI IDs for a device or device queue using netlink. This can +be done programmatically in a user application or by using a script included in +the kernel source tree: ``tools/net/ynl/pyynl/cli.py``. + +For example, using the script to dump all of the queues for a device (which +will reveal each queue's NAPI ID): + +.. code-block:: bash + + $ kernel-source/tools/net/ynl/pyynl/cli.py \ + --spec Documentation/netlink/specs/netdev.yaml \ + --dump queue-get \ + --json='{"ifindex": 2}' + +See ``Documentation/netlink/specs/netdev.yaml`` for more details on +available operations and attributes. Software IRQ coalescing ----------------------- diff --git a/Documentation/networking/net_cachelines/inet_connection_sock.rst b/Documentation/networking/net_cachelines/inet_connection_sock.rst index 4a15627fc93b..8fae85ebb773 100644 --- a/Documentation/networking/net_cachelines/inet_connection_sock.rst +++ b/Documentation/networking/net_cachelines/inet_connection_sock.rst @@ -12,11 +12,11 @@ struct inet_sock icsk_inet read_mostly r struct request_sock_queue icsk_accept_queue struct inet_bind_bucket icsk_bind_hash read_mostly tcp_set_state struct inet_bind2_bucket icsk_bind2_hash read_mostly tcp_set_state,inet_put_port -unsigned_long icsk_timeout read_mostly inet_csk_reset_xmit_timer,tcp_connect -struct timer_list icsk_retransmit_timer read_mostly inet_csk_reset_xmit_timer,tcp_connect +struct timer_list icsk_retransmit_timer read_write inet_csk_reset_xmit_timer,tcp_connect struct timer_list icsk_delack_timer read_mostly inet_csk_reset_xmit_timer,tcp_connect u32 icsk_rto read_write tcp_cwnd_validate,tcp_schedule_loss_probe,tcp_connect_init,tcp_connect,tcp_write_xmit,tcp_push_one u32 icsk_rto_min +u32 icsk_rto_max read_mostly tcp_reset_xmit_timer u32 icsk_delack_max u32 icsk_pmtu_cookie read_write tcp_sync_mss,tcp_current_mss,tcp_send_syn_data,tcp_connect_init,tcp_connect struct tcp_congestion_ops icsk_ca_ops read_write tcp_cwnd_validate,tcp_tso_segs,tcp_ca_dst_init,tcp_connect_init,tcp_connect,tcp_write_xmit @@ -38,7 +38,6 @@ struct icsk_ack_u8 quick read_write w struct icsk_ack_u8 pingpong struct icsk_ack_u8 retry write_mostly read_write inet_csk_clear_xmit_timer,tcp_rearm_rto,tcp_event_new_data_sent,tcp_write_xmit,__tcp_send_ack,tcp_send_ack, struct icsk_ack_u8 ato read_mostly write_mostly tcp_dec_quickack_mode,tcp_event_ack_sent,__tcp_transmit_skb,__tcp_send_ack,tcp_send_ack -struct icsk_ack_unsigned_long timeout read_write read_write inet_csk_reset_xmit_timer,tcp_connect struct icsk_ack_u32 lrcvtime read_write tcp_finish_connect,tcp_connect,tcp_event_data_sent,__tcp_transmit_skb struct icsk_ack_u16 rcv_mss write_mostly read_mostly __tcp_select_window,__tcp_cleanup_rbuf,tcp_initialize_rcv_mss,tcp_connect_init struct icsk_mtup_int search_high read_write tcp_mtup_init,tcp_sync_mss,tcp_connect_init,tcp_mtu_check_reprobe,tcp_write_xmit diff --git a/Documentation/networking/net_cachelines/net_device.rst b/Documentation/networking/net_cachelines/net_device.rst index 15e31ece675f..6327e689e8a8 100644 --- a/Documentation/networking/net_cachelines/net_device.rst +++ b/Documentation/networking/net_cachelines/net_device.rst @@ -167,7 +167,7 @@ unsigned:1 wol_enabled unsigned:1 threaded napi_poll(napi_enable,dev_set_threaded) unsigned_long:1 see_all_hwtstamp_requests unsigned_long:1 change_proto_down -unsigned_long:1 netns_local +unsigned_long:1 netns_immutable unsigned_long:1 fcoe_mtu struct list_head net_notifier_list struct macsec_ops* macsec_ops diff --git a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst index de0263302f16..6e7b20afd2d4 100644 --- a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst +++ b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst @@ -86,6 +86,7 @@ u8 sysctl_tcp_sack u8 sysctl_tcp_window_scaling tcp_syn_options,tcp_parse_options u8 sysctl_tcp_timestamps u8 sysctl_tcp_early_retrans read_mostly tcp_schedule_loss_probe(tcp_write_xmit) +u32 sysctl_tcp_rto_max_ms u8 sysctl_tcp_recovery tcp_fastretrans_alert u8 sysctl_tcp_thin_linear_timeouts tcp_retrans_timer(on_thin_streams) u8 sysctl_tcp_slow_start_after_idle unlikely(tcp_cwnd_validate-network-not-starved) diff --git a/Documentation/networking/net_cachelines/snmp.rst b/Documentation/networking/net_cachelines/snmp.rst index 90ca2d92547d..bc96efc92cf5 100644 --- a/Documentation/networking/net_cachelines/snmp.rst +++ b/Documentation/networking/net_cachelines/snmp.rst @@ -36,6 +36,7 @@ unsigned_long LINUX_MIB_TIMEWAITRECYCLED unsigned_long LINUX_MIB_TIMEWAITKILLED unsigned_long LINUX_MIB_PAWSACTIVEREJECTED unsigned_long LINUX_MIB_PAWSESTABREJECTED +unsigned_long LINUX_MIB_TSECR_REJECTED unsigned_long LINUX_MIB_DELAYEDACKLOST unsigned_long LINUX_MIB_LISTENOVERFLOWS unsigned_long LINUX_MIB_LISTENDROPS diff --git a/Documentation/networking/net_cachelines/tcp_sock.rst b/Documentation/networking/net_cachelines/tcp_sock.rst index 1f79765072b1..bc9b2131bf7a 100644 --- a/Documentation/networking/net_cachelines/tcp_sock.rst +++ b/Documentation/networking/net_cachelines/tcp_sock.rst @@ -27,6 +27,7 @@ u32 dsack_dups u32 snd_una read_mostly read_write tcp_wnd_end,tcp_urg_mode,tcp_minshall_check,tcp_cwnd_validate(tx);tcp_ack,tcp_may_update_window,tcp_clean_rtx_queue(write),tcp_ack_tstamp(rx) u32 snd_sml read_write tcp_minshall_check,tcp_minshall_update u32 rcv_tstamp read_mostly tcp_ack +void * tcp_clean_acked read_mostly tcp_ack u32 lsndtime read_write tcp_slow_start_after_idle_check,tcp_event_data_sent u32 last_oow_ack_time u32 compressed_ack_rcv_nxt diff --git a/Documentation/networking/netconsole.rst b/Documentation/networking/netconsole.rst index 94c4680fdf3e..a0076b542e9c 100644 --- a/Documentation/networking/netconsole.rst +++ b/Documentation/networking/netconsole.rst @@ -17,6 +17,8 @@ Release prepend support by Breno Leitao <leitao@debian.org>, Jul 7 2023 Userdata append support by Matthew Wood <thepacketgeek@gmail.com>, Jan 22 2024 +Sysdata append support by Breno Leitao <leitao@debian.org>, Jan 15 2025 + Please send bug reports to Matt Mackall <mpm@selenic.com> Satyam Sharma <satyam.sharma@gmail.com>, and Cong Wang <xiyou.wangcong@gmail.com> @@ -45,7 +47,7 @@ following format:: r if present, prepend kernel version (release) to the message src-port source for UDP packets (defaults to 6665) src-ip source IP to use (interface address) - dev network interface (eth0) + dev network interface name (eth0) or MAC address tgt-port port for logging agent (6666) tgt-ip IP address for logging agent tgt-macaddr ethernet MAC address for logging agent (broadcast) @@ -62,6 +64,10 @@ or using IPv6:: insmod netconsole netconsole=@/,@fd00:1:2:3::1/ +or using a MAC address to select the egress interface:: + + linux netconsole=4444@10.0.0.1/22:33:44:55:66:77,9353@10.0.0.2/12:34:56:78:9a:bc + It also supports logging to multiple remote agents by specifying parameters for the multiple agents separated by semicolons and the complete string enclosed in "quotes", thusly:: @@ -238,6 +244,102 @@ Delete `userdata` entries with `rmdir`:: It is recommended to not write user data values with newlines. +Task name auto population in userdata +------------------------------------- + +Inside the netconsole configfs hierarchy, there is a file called +`taskname_enabled` under the `userdata` directory. This file is used to enable +or disable the automatic task name population feature. This feature +automatically populates the current task name that is scheduled in the CPU +sneding the message. + +To enable task name auto-population:: + + echo 1 > /sys/kernel/config/netconsole/target1/userdata/taskname_enabled + +When this option is enabled, the netconsole messages will include an additional +line in the userdata field with the format `taskname=<task name>`. This allows +the receiver of the netconsole messages to easily find which application was +currently scheduled when that message was generated, providing extra context +for kernel messages and helping to categorize them. + +Example:: + + echo "This is a message" > /dev/kmsg + 12,607,22085407756,-;This is a message + taskname=echo + +In this example, the message was generated while "echo" was the current +scheduled process. + +Kernel release auto population in userdata +------------------------------------------ + +Within the netconsole configfs hierarchy, there is a file named `release_enabled` +located in the `userdata` directory. This file controls the kernel release +(version) auto-population feature, which appends the kernel release information +to userdata dictionary in every message sent. + +To enable the release auto-population:: + + echo 1 > /sys/kernel/config/netconsole/target1/userdata/release_enabled + +Example:: + + echo "This is a message" > /dev/kmsg + 12,607,22085407756,-;This is a message + release=6.14.0-rc6-01219-g3c027fbd941d + +.. note:: + + This feature provides the same data as the "release prepend" feature. + However, in this case, the release information is appended to the userdata + dictionary rather than being included in the message header. + + +CPU number auto population in userdata +-------------------------------------- + +Inside the netconsole configfs hierarchy, there is a file called +`cpu_nr` under the `userdata` directory. This file is used to enable or disable +the automatic CPU number population feature. This feature automatically +populates the CPU number that is sending the message. + +To enable the CPU number auto-population:: + + echo 1 > /sys/kernel/config/netconsole/target1/userdata/cpu_nr + +When this option is enabled, the netconsole messages will include an additional +line in the userdata field with the format `cpu=<cpu_number>`. This allows the +receiver of the netconsole messages to easily differentiate and demultiplex +messages originating from different CPUs, which is particularly useful when +dealing with parallel log output. + +Example:: + + echo "This is a message" > /dev/kmsg + 12,607,22085407756,-;This is a message + cpu=42 + +In this example, the message was sent by CPU 42. + +.. note:: + + If the user has set a conflicting `cpu` key in the userdata dictionary, + both keys will be reported, with the kernel-populated entry appearing after + the user one. For example:: + + # User-defined CPU entry + mkdir -p /sys/kernel/config/netconsole/target1/userdata/cpu + echo "1" > /sys/kernel/config/netconsole/target1/userdata/cpu/value + + Output might look like:: + + 12,607,22085407756,-;This is a message + cpu=1 + cpu=42 # kernel-populated value + + Extended console: ================= diff --git a/Documentation/networking/netdevices.rst b/Documentation/networking/netdevices.rst index 1d37038e9fbe..6c2d8945f597 100644 --- a/Documentation/networking/netdevices.rst +++ b/Documentation/networking/netdevices.rst @@ -210,49 +210,55 @@ packets is preferred. struct net_device synchronization rules ======================================= ndo_open: - Synchronization: rtnl_lock() semaphore. + Synchronization: rtnl_lock() semaphore. In addition, netdev instance + lock if the driver implements queue management or shaper API. Context: process ndo_stop: - Synchronization: rtnl_lock() semaphore. + Synchronization: rtnl_lock() semaphore. In addition, netdev instance + lock if the driver implements queue management or shaper API. Context: process Note: netif_running() is guaranteed false ndo_do_ioctl: Synchronization: rtnl_lock() semaphore. - Context: process - This is only called by network subsystems internally, - not by user space calling ioctl as it was in before - linux-5.14. + This is only called by network subsystems internally, + not by user space calling ioctl as it was in before + linux-5.14. ndo_siocbond: - Synchronization: rtnl_lock() semaphore. + Synchronization: rtnl_lock() semaphore. In addition, netdev instance + lock if the driver implements queue management or shaper API. Context: process - Used by the bonding driver for the SIOCBOND family of - ioctl commands. + Used by the bonding driver for the SIOCBOND family of + ioctl commands. ndo_siocwandev: - Synchronization: rtnl_lock() semaphore. + Synchronization: rtnl_lock() semaphore. In addition, netdev instance + lock if the driver implements queue management or shaper API. Context: process Used by the drivers/net/wan framework to handle the SIOCWANDEV ioctl with the if_settings structure. ndo_siocdevprivate: - Synchronization: rtnl_lock() semaphore. + Synchronization: rtnl_lock() semaphore. In addition, netdev instance + lock if the driver implements queue management or shaper API. Context: process This is used to implement SIOCDEVPRIVATE ioctl helpers. These should not be added to new drivers, so don't use. ndo_eth_ioctl: - Synchronization: rtnl_lock() semaphore. + Synchronization: rtnl_lock() semaphore. In addition, netdev instance + lock if the driver implements queue management or shaper API. Context: process ndo_get_stats: - Synchronization: rtnl_lock() semaphore, or RCU. + Synchronization: RCU (can be called concurrently with the stats + update path). Context: atomic (can't sleep under RCU) ndo_start_xmit: @@ -284,6 +290,16 @@ ndo_set_rx_mode: Synchronization: netif_addr_lock spinlock. Context: BHs disabled +ndo_setup_tc: + ``TC_SETUP_BLOCK`` and ``TC_SETUP_FT`` are running under NFT locks + (i.e. no ``rtnl_lock`` and no device instance lock). The rest of + ``tc_setup_type`` types run under netdev instance lock if the driver + implements queue management or shaper API. + +Most ndo callbacks not specified in the list above are running +under ``rtnl_lock``. In addition, netdev instance lock is taken as well if +the driver implements queue management or shaper API. + struct napi_struct synchronization rules ======================================== napi->poll: @@ -298,6 +314,58 @@ napi->poll: softirq will be called with interrupts disabled by netconsole. +struct netdev_queue_mgmt_ops synchronization rules +================================================== + +All queue management ndo callbacks are holding netdev instance lock. + +RTNL and netdev instance lock +============================= + +Historically, all networking control operations were protected by a single +global lock known as ``rtnl_lock``. There is an ongoing effort to replace this +global lock with separate locks for each network namespace. Additionally, +properties of individual netdev are increasingly protected by per-netdev locks. + +For device drivers that implement shaping or queue management APIs, all control +operations will be performed under the netdev instance lock. Currently, this +instance lock is acquired within the context of ``rtnl_lock``. The drivers +can also explicitly request instance lock to be acquired via +``request_ops_lock``. In the future, there will be an option for individual +drivers to opt out of using ``rtnl_lock`` and instead perform their control +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. + +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`` + +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/networking/scaling.rst b/Documentation/networking/scaling.rst index 4eb50bcb9d42..99b6a61e5e31 100644 --- a/Documentation/networking/scaling.rst +++ b/Documentation/networking/scaling.rst @@ -49,14 +49,21 @@ destination address) and TCP/UDP (source port, destination port) tuples are swapped, the computed hash is the same. This is beneficial in some applications that monitor TCP/IP flows (IDS, firewalls, ...etc) and need both directions of the flow to land on the same Rx queue (and CPU). The -"Symmetric-XOR" is a type of RSS algorithms that achieves this hash -symmetry by XORing the input source and destination fields of the IP -and/or L4 protocols. This, however, results in reduced input entropy and -could potentially be exploited. Specifically, the algorithm XORs the input +"Symmetric-XOR" and "Symmetric-OR-XOR" are types of RSS algorithms that +achieve this hash symmetry by XOR/ORing the input source and destination +fields of the IP and/or L4 protocols. This, however, results in reduced +input entropy and could potentially be exploited. + +Specifically, the "Symmetric-XOR" algorithm XORs the input as follows:: # (SRC_IP ^ DST_IP, SRC_IP ^ DST_IP, SRC_PORT ^ DST_PORT, SRC_PORT ^ DST_PORT) +The "Symmetric-OR-XOR" algorithm, on the other hand, transforms the input as +follows:: + + # (SRC_IP | DST_IP, SRC_IP ^ DST_IP, SRC_PORT | DST_PORT, SRC_PORT ^ DST_PORT) + The result is then fed to the underlying RSS algorithm. Some advanced NICs allow steering packets to queues based on @@ -427,8 +434,10 @@ rps_dev_flow_table. The stack consults a CPU to hardware queue map which is maintained by the NIC driver. This is an auto-generated reverse map of the IRQ affinity table shown by /proc/interrupts. Drivers can use functions in the cpu_rmap (“CPU affinity reverse map”) kernel library -to populate the map. For each CPU, the corresponding queue in the map is -set to be one whose processing CPU is closest in cache locality. +to populate the map. Alternatively, drivers can delegate the cpu_rmap +management to the Kernel by calling netif_enable_cpu_rmap(). For each CPU, +the corresponding queue in the map is set to be one whose processing CPU is +closest in cache locality. Accelerated RFS Configuration diff --git a/Documentation/networking/statistics.rst b/Documentation/networking/statistics.rst index 75e017dfa825..518284e287b0 100644 --- a/Documentation/networking/statistics.rst +++ b/Documentation/networking/statistics.rst @@ -143,7 +143,7 @@ reading multiple stats as it internally performs a full dump of and reports only the stat corresponding to the accessed file. Sysfs files are documented in -`Documentation/ABI/testing/sysfs-class-net-statistics`. +Documentation/ABI/testing/sysfs-class-net-statistics. netlink diff --git a/Documentation/networking/strparser.rst b/Documentation/networking/strparser.rst index 6cab1f74ae05..8dc6bb04c710 100644 --- a/Documentation/networking/strparser.rst +++ b/Documentation/networking/strparser.rst @@ -112,7 +112,7 @@ Functions Callbacks ========= -There are six callbacks: +There are seven callbacks: :: @@ -180,10 +180,17 @@ There are six callbacks: struct contains two fields: offset and full_len. Offset is where the message starts in the skb, and full_len is the the length of the message. skb->len - offset may be greater - then full_len since strparser does not trim the skb. + than full_len since strparser does not trim the skb. :: + int (*read_sock)(struct strparser *strp, read_descriptor_t *desc, + sk_read_actor_t recv_actor); + + The read_sock callback is used by strparser instead of + sock->ops->read_sock, if provided. + :: + int (*read_sock_done)(struct strparser *strp, int err); read_sock_done is called when the stream parser is done reading diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst index f355f0166f1b..2966b7122f05 100644 --- a/Documentation/networking/switchdev.rst +++ b/Documentation/networking/switchdev.rst @@ -137,7 +137,7 @@ would be sub-port 0 on port 1 on switch 1. Port Features ^^^^^^^^^^^^^ -dev->netns_local +dev->netns_immutable If the switchdev driver (and device) only supports offloading of the default network namespace (netns), the driver should set this private flag to prevent diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst index 61ef9da10e28..b8fef8101176 100644 --- a/Documentation/networking/timestamping.rst +++ b/Documentation/networking/timestamping.rst @@ -140,6 +140,14 @@ SOF_TIMESTAMPING_TX_ACK: cumulative acknowledgment. The mechanism ignores SACK and FACK. This flag can be enabled via both socket options and control messages. +SOF_TIMESTAMPING_TX_COMPLETION: + Request tx timestamps on packet tx completion. The completion + timestamp is generated by the kernel when it receives packet a + completion report from the hardware. Hardware may report multiple + packets at once, and completion timestamps reflect the timing of the + report and not actual tx time. This flag can be enabled via both + socket options and control messages. + 1.3.2 Timestamp Reporting ^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/networking/xfrm_device.rst b/Documentation/networking/xfrm_device.rst index 66f6e9a9b59a..7f24c09f2694 100644 --- a/Documentation/networking/xfrm_device.rst +++ b/Documentation/networking/xfrm_device.rst @@ -126,7 +126,8 @@ been setup for offload, it first calls into xdo_dev_offload_ok() with the skb and the intended offload state to ask the driver if the offload will serviceable. This can check the packet information to be sure the offload can be supported (e.g. IPv4 or IPv6, no IPv4 options, etc) and -return true of false to signify its support. +return true or false to signify its support. In case driver doesn't implement +this callback, the stack provides reasonable defaults. Crypto offload mode: When ready to send, the driver needs to inspect the Tx packet for the diff --git a/Documentation/networking/xsk-tx-metadata.rst b/Documentation/networking/xsk-tx-metadata.rst index e76b0cfc32f7..df53a10ccac3 100644 --- a/Documentation/networking/xsk-tx-metadata.rst +++ b/Documentation/networking/xsk-tx-metadata.rst @@ -50,6 +50,10 @@ The flags field enables the particular offload: checksum. ``csum_start`` specifies byte offset of where the checksumming should start and ``csum_offset`` specifies byte offset where the device should store the computed checksum. +- ``XDP_TXMD_FLAGS_LAUNCH_TIME``: requests the device to schedule the + packet for transmission at a pre-determined time called launch time. The + value of launch time is indicated by ``launch_time`` field of + ``union xsk_tx_metadata``. Besides the flags above, in order to trigger the offloads, the first packet's ``struct xdp_desc`` descriptor should set ``XDP_TX_METADATA`` @@ -65,6 +69,63 @@ In this case, when running in ``XDK_COPY`` mode, the TX checksum is calculated on the CPU. Do not enable this option in production because it will negatively affect performance. +Launch Time +=========== + +The value of the requested launch time should be based on the device's PTP +Hardware Clock (PHC) to ensure accuracy. AF_XDP takes a different data path +compared to the ETF queuing discipline, which organizes packets and delays +their transmission. Instead, AF_XDP immediately hands off the packets to +the device driver without rearranging their order or holding them prior to +transmission. Since the driver maintains FIFO behavior and does not perform +packet reordering, a packet with a launch time request will block other +packets in the same Tx Queue until it is sent. Therefore, it is recommended +to allocate separate queue for scheduling traffic that is intended for +future transmission. + +In scenarios where the launch time offload feature is disabled, the device +driver is expected to disregard the launch time request. For correct +interpretation and meaningful operation, the launch time should never be +set to a value larger than the farthest programmable time in the future +(the horizon). Different devices have different hardware limitations on the +launch time offload feature. + +stmmac driver +------------- + +For stmmac, TSO and launch time (TBS) features are mutually exclusive for +each individual Tx Queue. By default, the driver configures Tx Queue 0 to +support TSO and the rest of the Tx Queues to support TBS. The launch time +hardware offload feature can be enabled or disabled by using the tc-etf +command to call the driver's ndo_setup_tc() callback. + +The value of the launch time that is programmed in the Enhanced Normal +Transmit Descriptors is a 32-bit value, where the most significant 8 bits +represent the time in seconds and the remaining 24 bits represent the time +in 256 ns increments. The programmed launch time is compared against the +PTP time (bits[39:8]) and rolls over after 256 seconds. Therefore, the +horizon of the launch time for dwmac4 and dwxlgmac2 is 128 seconds in the +future. + +igc driver +---------- + +For igc, all four Tx Queues support the launch time feature. The launch +time hardware offload feature can be enabled or disabled by using the +tc-etf command to call the driver's ndo_setup_tc() callback. When entering +TSN mode, the igc driver will reset the device and create a default Qbv +schedule with a 1-second cycle time, with all Tx Queues open at all times. + +The value of the launch time that is programmed in the Advanced Transmit +Context Descriptor is a relative offset to the starting time of the Qbv +transmission window of the queue. The Frst flag of the descriptor can be +set to schedule the packet for the next Qbv cycle. Therefore, the horizon +of the launch time for i225 and i226 is the ending time of the next cycle +of the Qbv transmission window of the queue. For example, when the Qbv +cycle time is set to 1 second, the horizon of the launch time ranges +from 1 second to 2 seconds, depending on where the Qbv cycle is currently +running. + Querying Device Capabilities ============================ @@ -74,6 +135,7 @@ Refer to ``xsk-flags`` features bitmask in - ``tx-timestamp``: device supports ``XDP_TXMD_FLAGS_TIMESTAMP`` - ``tx-checksum``: device supports ``XDP_TXMD_FLAGS_CHECKSUM`` +- ``tx-launch-time-fifo``: device supports ``XDP_TXMD_FLAGS_LAUNCH_TIME`` See ``tools/net/ynl/samples/netdev.c`` on how to query this information. diff --git a/Documentation/nvme/nvme-pci-endpoint-target.rst b/Documentation/nvme/nvme-pci-endpoint-target.rst index 66e7b7d869b4..b699595d1762 100644 --- a/Documentation/nvme/nvme-pci-endpoint-target.rst +++ b/Documentation/nvme/nvme-pci-endpoint-target.rst @@ -86,7 +86,7 @@ configurable through configfs before starting the controller. To avoid issues with excessive local memory usage for executing commands, MDTS defaults to 512 KB and is limited to a maximum of 2 MB (arbitrary limit). -Mimimum number of PCI Address Mapping Windows Required +Minimum number of PCI Address Mapping Windows Required ------------------------------------------------------ Most PCI endpoint controllers provide a limited number of mapping windows for diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst index dbb763a8de90..22fa925353cf 100644 --- a/Documentation/process/5.Posting.rst +++ b/Documentation/process/5.Posting.rst @@ -268,10 +268,15 @@ The tags in common use are: - Cc: the named person received a copy of the patch and had the opportunity to comment on it. -Be careful in the addition of tags to your patches, as only Cc: is appropriate -for addition without the explicit permission of the person named; using -Reported-by: is fine most of the time as well, but ask for permission if -the bug was reported in private. +Be careful in the addition of the aforementioned tags to your patches, as all +except for Cc:, Reported-by:, and Suggested-by: need explicit permission of the +person named. For those three implicit permission is sufficient if the person +contributed to the Linux kernel using that name and email address according +to the lore archives or the commit history -- and in case of Reported-by: +and Suggested-by: did the reporting or suggestion in public. Note, +bugzilla.kernel.org is a public place in this sense, but email addresses +used there are private; so do not expose them in tags, unless the person +used them in earlier contributions. Sending the patch diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index a0beca805362..d564362773b5 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -58,11 +58,11 @@ mcelog 0.6 mcelog --version iptables 1.4.2 iptables -V openssl & libcrypto 1.0.0 openssl version bc 1.06.95 bc --version -Sphinx\ [#f1]_ 2.4.4 sphinx-build --version +Sphinx\ [#f1]_ 3.4.3 sphinx-build --version GNU tar 1.28 tar --version gtags (optional) 6.6.5 gtags --version mkimage (optional) 2017.01 mkimage --version -Python (optional) 3.5.x python3 --version +Python (optional) 3.9.x python3 --version GNU AWK (optional) 5.1.0 gawk --version ====================== =============== ======================================== diff --git a/Documentation/process/code-of-conduct-interpretation.rst b/Documentation/process/code-of-conduct-interpretation.rst index 1d1150954be3..4cdef8360698 100644 --- a/Documentation/process/code-of-conduct-interpretation.rst +++ b/Documentation/process/code-of-conduct-interpretation.rst @@ -145,13 +145,16 @@ kernel community. Any decisions regarding enforcement recommendations will be brought to the TAB for implementation of enforcement with the relevant maintainers -if needed. A decision by the Code of Conduct Committee can be overturned -by the TAB by a two-thirds vote. +if needed. Once the TAB approves one or more of the measures outlined +in the scope of the ban by two-thirds of the members voting for the +measures, the Code of Conduct Committee will enforce the TAB approved +measures. Any Code of Conduct Committee members serving on the TAB will +not vote on the measures. At quarterly intervals, the Code of Conduct Committee and TAB will provide a report summarizing the anonymised reports that the Code of Conduct committee has received and their status, as well details of any -overridden decisions including complete and identifiable voting details. +TAB approved decisions including complete and identifiable voting details. Because how we interpret and enforce the Code of Conduct will evolve over time, this document will be updated when necessary to reflect any @@ -227,9 +230,11 @@ The scope of the ban for a period of time could include: such as mailing lists and social media sites Once the TAB approves one or more of the measures outlined in the scope of -the ban by a two-thirds vote, the Code of Conduct Committee will enforce -the TAB approved measure(s) in collaboration with the community, maintainers, -sub-maintainers, and kernel.org administrators. +the ban by two-thirds of the members voting for the measures, the Code of +Conduct Committee will enforce the TAB approved measure(s) in collaboration +with the community, maintainers, sub-maintainers, and kernel.org +administrators. Any Code of Conduct Committee members serving on the TAB +will not vote on the measures. The Code of Conduct Committee is mindful of the negative impact of seeking public apology and instituting ban could have on individuals. It is also diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst index daebce49cfdf..0e19d2f0d6bb 100644 --- a/Documentation/process/embargoed-hardware-issues.rst +++ b/Documentation/process/embargoed-hardware-issues.rst @@ -308,7 +308,7 @@ an involved disclosed party. The current ambassadors list: Google Kees Cook <keescook@chromium.org> - LLVM Nick Desaulniers <ndesaulniers@google.com> + LLVM Nick Desaulniers <nick.desaulniers+lkml@gmail.com> ============= ======================================================== If you want your organization to be added to the ambassadors list, please diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst index 3b5b5983fea8..c67ac12cf789 100644 --- a/Documentation/process/kernel-docs.rst +++ b/Documentation/process/kernel-docs.rst @@ -75,6 +75,17 @@ On-line docs Published books --------------- + * Title: **The Linux Memory Manager** + + :Author: Lorenzo Stoakes + :Publisher: No Starch Press + :Date: February 2025 + :Pages: 1300 + :ISBN: 978-1718504462 + :Notes: Memory management. Full draft available as early access for + pre-order, full release scheduled for Fall 2025. See + https://nostarch.com/linux-memory-manager for further info. + * Title: **Practical Linux System Administration: A Guide to Installation, Configuration, and Management, 1st Edition** :Author: Kenneth Hess diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index e497729525d5..1ac62dc3a66f 100644 --- a/Documentation/process/maintainer-netdev.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -311,6 +311,14 @@ to the mailing list, e.g.:: Posting as one thread is discouraged because it confuses patchwork (as of patchwork 2.2.2). +Co-posting selftests +-------------------- + +Selftests should be part of the same series as the code changes. +Specifically for fixes both code change and related test should go into +the same tree (the tests may lack a Fixes tag, which is expected). +Mixing code changes and test changes in a single commit is discouraged. + Preparing changes ----------------- 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/process/submit-checklist.rst b/Documentation/process/submit-checklist.rst index e531dd504b6c..beb7f94279fd 100644 --- a/Documentation/process/submit-checklist.rst +++ b/Documentation/process/submit-checklist.rst @@ -52,7 +52,8 @@ Provide documentation 4) All new module parameters are documented with ``MODULE_PARM_DESC()`` 5) All new userspace interfaces are documented in ``Documentation/ABI/``. - See ``Documentation/ABI/README`` for more information. + See Documentation/admin-guide/abi.rst (or ``Documentation/ABI/README``) + for more information. Patches that change userspace interfaces should be CCed to linux-api@vger.kernel.org. @@ -91,9 +92,12 @@ Build your code fix any issues. 2) Builds on multiple CPU architectures by using local cross-compile tools - or some other build farm. Note that ppc64 is a good architecture for - cross-compilation checking because it tends to use ``unsigned long`` for - 64-bit quantities. + or some other build farm. + Note that testing against architectures of different word sizes + (32- and 64-bit) and different endianness (big- and little-) is effective + in catching various portability issues due to false assumptions on + representable quantity range, data alignment, or endianness, among + others. 3) Newly-added code has been compiled with ``gcc -W`` (use ``make KCFLAGS=-W``). This will generate lots of noise, but is good diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 8fdc0ef3e604..cede4e7b29af 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -495,10 +495,10 @@ list archives. A "# Suffix" may also be used in this case to clarify. If a person has had the opportunity to comment on a patch, but has not provided such comments, you may optionally add a ``Cc:`` tag to the patch. -This is the only tag which might be added without an explicit action by the -person it names - but it should indicate that this person was copied on the -patch. This tag documents that potentially interested parties -have been included in the discussion. +This tag documents that potentially interested parties have been included in +the discussion. Note, this is one of only three tags you might be able to use +without explicit permission of the person named (see 'Tagging people requires +permission' below for details). Co-developed-by: states that the patch was co-created by multiple developers; it is used to give attribution to co-authors (in addition to the author @@ -544,9 +544,9 @@ hopefully inspires them to help us again in the future. The tag is intended for bugs; please do not use it to credit feature requests. The tag should be followed by a Closes: tag pointing to the report, unless the report is not available on the web. The Link: tag can be used instead of Closes: if the patch -fixes a part of the issue(s) being reported. Please note that if the bug was -reported in private, then ask for permission first before using the Reported-by -tag. +fixes a part of the issue(s) being reported. Note, the Reported-by tag is one +of only three tags you might be able to use without explicit permission of the +person named (see 'Tagging people requires permission' below for details). A Tested-by: tag indicates that the patch has been successfully tested (in some environment) by the person named. This tag informs maintainers that @@ -596,11 +596,11 @@ Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned in the patch changelog (after the '---' separator). A Suggested-by: tag indicates that the patch idea is suggested by the person -named and ensures credit to the person for the idea. Please note that this -tag should not be added without the reporter's permission, especially if the -idea was not posted in a public forum. That said, if we diligently credit our -idea reporters, they will, hopefully, be inspired to help us again in the -future. +named and ensures credit to the person for the idea: if we diligently credit +our idea reporters, they will, hopefully, be inspired to help us again in the +future. Note, this is one of only three tags you might be able to use without +explicit permission of the person named (see 'Tagging people requires +permission' below for details). A Fixes: tag indicates that the patch fixes an issue in a previous commit. It is used to make it easy to determine where a bug originated, which can help @@ -618,6 +618,21 @@ Finally, while providing tags is welcome and typically very appreciated, please note that signers (i.e. submitters and maintainers) may use their discretion in applying offered tags. +.. _tagging_people: + +Tagging people requires permission +---------------------------------- + +Be careful in the addition of the aforementioned tags to your patches, as all +except for Cc:, Reported-by:, and Suggested-by: need explicit permission of the +person named. For those three implicit permission is sufficient if the person +contributed to the Linux kernel using that name and email address according +to the lore archives or the commit history -- and in case of Reported-by: +and Suggested-by: did the reporting or suggestion in public. Note, +bugzilla.kernel.org is a public place in this sense, but email addresses +used there are private; so do not expose them in tags, unless the person +used them in earlier contributions. + .. _the_canonical_patch_format: The canonical patch format @@ -717,6 +732,12 @@ patch in the permanent changelog. If the ``from`` line is missing, then the ``From:`` line from the email header will be used to determine the patch author in the changelog. +The author may indicate their affiliation or the sponsor of the work +by adding the name of an organization to the ``from`` and ``SoB`` lines, +e.g.: + + From: Patch Author (Company) <author@example.com> + Explanation Body ^^^^^^^^^^^^^^^^ 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/quick-start.rst b/Documentation/rust/quick-start.rst index 4aa50e5fcb8c..6d2607870ba4 100644 --- a/Documentation/rust/quick-start.rst +++ b/Documentation/rust/quick-start.rst @@ -145,7 +145,7 @@ Rust standard library source **************************** The Rust standard library source is required because the build system will -cross-compile ``core`` and ``alloc``. +cross-compile ``core``. If ``rustup`` is being used, run:: diff --git a/Documentation/rust/testing.rst b/Documentation/rust/testing.rst index 568b71b415a4..f692494f7b74 100644 --- a/Documentation/rust/testing.rst +++ b/Documentation/rust/testing.rst @@ -97,7 +97,7 @@ operator are also supported as usual, e.g.: /// ``` /// # use kernel::{spawn_work_item, workqueue}; - /// spawn_work_item!(workqueue::system(), || pr_info!("x"))?; + /// spawn_work_item!(workqueue::system(), || pr_info!("x\n"))?; /// # Ok::<(), Error>(()) /// ``` @@ -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/scheduler/sched-bwc.rst b/Documentation/scheduler/sched-bwc.rst index 41ed2ceafc92..e881a945c188 100644 --- a/Documentation/scheduler/sched-bwc.rst +++ b/Documentation/scheduler/sched-bwc.rst @@ -59,7 +59,7 @@ At the same time, we can say that the worst case deadline miss, will be \Sum e_i; that is, there is a bounded tardiness (under the assumption that x+e is indeed WCET). -The interferenece when using burst is valued by the possibilities for +The interference when using burst is valued by the possibilities for missing the deadline and the average WCET. Test results showed that when there many cgroups or CPU is under utilized, the interference is limited. More details are shown in: diff --git a/Documentation/scheduler/sched-debug.rst b/Documentation/scheduler/sched-debug.rst index 4d3d24f2a439..b5a92a39eccd 100644 --- a/Documentation/scheduler/sched-debug.rst +++ b/Documentation/scheduler/sched-debug.rst @@ -2,7 +2,7 @@ Scheduler debugfs ================= -Booting a kernel with CONFIG_SCHED_DEBUG=y will give access to +Booting a kernel with debugfs enabled will give access to scheduler specific debug files under /sys/kernel/debug/sched. Some of those files are described below. diff --git a/Documentation/scheduler/sched-design-CFS.rst b/Documentation/scheduler/sched-design-CFS.rst index 8786f219fc73..b574a2644c77 100644 --- a/Documentation/scheduler/sched-design-CFS.rst +++ b/Documentation/scheduler/sched-design-CFS.rst @@ -96,7 +96,7 @@ picked and the current task is preempted. CFS uses nanosecond granularity accounting and does not rely on any jiffies or other HZ detail. Thus the CFS scheduler has no notion of "timeslices" in the way the previous scheduler had, and has no heuristics whatsoever. There is -only one central tunable (you have to switch on CONFIG_SCHED_DEBUG): +only one central tunable: /sys/kernel/debug/sched/base_slice_ns diff --git a/Documentation/scheduler/sched-domains.rst b/Documentation/scheduler/sched-domains.rst index 5e996fe973b1..15e3a4cb304a 100644 --- a/Documentation/scheduler/sched-domains.rst +++ b/Documentation/scheduler/sched-domains.rst @@ -73,9 +73,8 @@ Architectures may override the generic domain builder and the default SD flags for a given topology level by creating a sched_domain_topology_level array and calling set_sched_topology() with this array as the parameter. -The sched-domains debugging infrastructure can be enabled by enabling -CONFIG_SCHED_DEBUG and adding 'sched_verbose' to your cmdline. If you -forgot to tweak your cmdline, you can also flip the +The sched-domains debugging infrastructure can be enabled by 'sched_verbose' +to your cmdline. If you forgot to tweak your cmdline, you can also flip the /sys/kernel/debug/sched/verbose knob. This enables an error checking parse of the sched domains which should catch most possible errors (described above). It also prints out the domain structure in a visual format. diff --git a/Documentation/scheduler/sched-ext.rst b/Documentation/scheduler/sched-ext.rst index c4672d7df2f7..0b2654e2164b 100644 --- a/Documentation/scheduler/sched-ext.rst +++ b/Documentation/scheduler/sched-ext.rst @@ -107,8 +107,7 @@ detailed information: nr_rejected : 0 enable_seq : 1 -If ``CONFIG_SCHED_DEBUG`` is set, whether a given task is on sched_ext can -be determined as follows: +Whether a given task is on sched_ext can be determined as follows: .. code-block:: none @@ -294,6 +293,42 @@ dispatching, and must be dispatched to with ``scx_bpf_dsq_insert()``. See the function documentation and usage in ``tools/sched_ext/scx_simple.bpf.c`` for more information. +Task Lifecycle +-------------- + +The following pseudo-code summarizes the entire lifecycle of a task managed +by a sched_ext scheduler: + +.. code-block:: c + + ops.init_task(); /* A new task is created */ + ops.enable(); /* Enable BPF scheduling for the task */ + + while (task in SCHED_EXT) { + if (task can migrate) + ops.select_cpu(); /* Called on wakeup (optimization) */ + + ops.runnable(); /* Task becomes ready to run */ + + while (task is runnable) { + if (task is not in a DSQ) { + ops.enqueue(); /* Task can be added to a DSQ */ + + /* A CPU becomes available */ + + ops.dispatch(); /* Task is moved to a local DSQ */ + } + ops.running(); /* Task starts running on its assigned CPU */ + ops.tick(); /* Called every 1/HZ seconds */ + ops.stopping(); /* Task stops running (time slice expires or wait) */ + } + + ops.quiescent(); /* Task releases its assigned CPU (wait) */ + } + + ops.disable(); /* Disable BPF scheduling for the task */ + ops.exit_task(); /* Task is destroyed */ + Where to Look ============= diff --git a/Documentation/scheduler/sched-rt-group.rst b/Documentation/scheduler/sched-rt-group.rst index 80b05a3009ea..ab464335d320 100644 --- a/Documentation/scheduler/sched-rt-group.rst +++ b/Documentation/scheduler/sched-rt-group.rst @@ -102,6 +102,9 @@ The system wide settings are configured under the /proc virtual file system: * sched_rt_period_us takes values from 1 to INT_MAX. * sched_rt_runtime_us takes values from -1 to sched_rt_period_us. * A run time of -1 specifies runtime == period, ie. no limit. + * sched_rt_runtime_us/sched_rt_period_us > 0.05 inorder to preserve + bandwidth for fair dl_server. For accurate value check average of + runtime/period in /sys/kernel/debug/sched/fair_server/cpuX/ 2.2 Default behaviour diff --git a/Documentation/scheduler/sched-stats.rst b/Documentation/scheduler/sched-stats.rst index caea83d91c67..08b6bc9a315c 100644 --- a/Documentation/scheduler/sched-stats.rst +++ b/Documentation/scheduler/sched-stats.rst @@ -88,7 +88,7 @@ One of these is produced per domain for each cpu described. (Note that if CONFIG_SMP is not defined, *no* domains are utilized and these lines will not appear in the output. <name> is an extension to the domain field that prints the name of the corresponding sched domain. It can appear in -schedstat version 17 and above, and requires CONFIG_SCHED_DEBUG.) +schedstat version 17 and above. domain<N> <name> <cpumask> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 diff --git a/Documentation/scsi/st.rst b/Documentation/scsi/st.rst index d3b28c28d74c..b4a092faa9c8 100644 --- a/Documentation/scsi/st.rst +++ b/Documentation/scsi/st.rst @@ -157,6 +157,11 @@ enabled driver and mode options. The value in the file is a bit mask where the bit definitions are the same as those used with MTSETDRVBUFFER in setting the options. +Each directory contains the entry 'position_lost_in_reset'. If this value is +one, reading and writing to the device is blocked after device reset. Most +devices rewind the tape after reset and the writes/read don't access the +tape position the user expects. + A link named 'tape' is made from the SCSI device directory to the class directory corresponding to the mode 0 auto-rewind device (e.g., st0). 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/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst index 04254474fa04..a45174d165eb 100644 --- a/Documentation/sound/alsa-configuration.rst +++ b/Documentation/sound/alsa-configuration.rst @@ -58,7 +58,7 @@ debug 2 = verbose debug messages); This option appears only when ``CONFIG_SND_DEBUG=y``. This option can be dynamically changed via sysfs - /sys/modules/snd/parameters/debug file. + /sys/module/snd/parameters/debug file. Module snd-pcm-oss ------------------ diff --git a/Documentation/sound/designs/powersave.rst b/Documentation/sound/designs/powersave.rst index 138157452eb9..ca7d1e838b4d 100644 --- a/Documentation/sound/designs/powersave.rst +++ b/Documentation/sound/designs/powersave.rst @@ -25,15 +25,15 @@ operations. The ``power_save`` option is exported as writable. This means you can adjust the value via sysfs on the fly. For example, to turn on the automatic power-save mode with 10 seconds, write to -``/sys/modules/snd_ac97_codec/parameters/power_save`` (usually as root): +``/sys/module/snd_ac97_codec/parameters/power_save`` (usually as root): :: - # echo 10 > /sys/modules/snd_ac97_codec/parameters/power_save + # echo 10 > /sys/module/snd_ac97_codec/parameters/power_save Note that you might hear click noise/pop when changing the power state. Also, it often takes certain time to wake up from the -power-down to the active state. These are often hardly to fix, so +power-down to the active state. These are often hard to fix, so don't report extra bug reports unless you have a fix patch ;-) For HD-audio interface, there is another module option, diff --git a/Documentation/sound/soc/codec-to-codec.rst b/Documentation/sound/soc/codec-to-codec.rst index 0418521b6e03..973c147d9d82 100644 --- a/Documentation/sound/soc/codec-to-codec.rst +++ b/Documentation/sound/soc/codec-to-codec.rst @@ -68,7 +68,7 @@ file: .codec_dai_name = "codec-2-dai_name", .platform_name = "samsung-i2s.0", .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF - | SND_SOC_DAIFMT_CBM_CFM, + | SND_SOC_DAIFMT_CBP_CFP, .ignore_suspend = 1, .c2c_params = &dsp_codec_params, .num_c2c_params = 1, @@ -80,7 +80,7 @@ file: .codec_name = "codec-3, .codec_dai_name = "codec-3-dai_name", .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF - | SND_SOC_DAIFMT_CBM_CFM, + | SND_SOC_DAIFMT_CBP_CFP, .ignore_suspend = 1, .c2c_params = &dsp_codec_params, .num_c2c_params = 1, diff --git a/Documentation/sound/soc/dpcm.rst b/Documentation/sound/soc/dpcm.rst index 02419a6f8213..7b6aeab3c207 100644 --- a/Documentation/sound/soc/dpcm.rst +++ b/Documentation/sound/soc/dpcm.rst @@ -147,14 +147,16 @@ For the example above we have to define 4 FE DAI links and 6 BE DAI links. The FE DAI links are defined as follows :- :: + SND_SOC_DAILINK_DEFS(pcm0, + DAILINK_COMP_ARRAY(COMP_CPU("System Pin")), + DAILINK_COMP_ARRAY(COMP_DUMMY()), + DAILINK_COMP_ARRAY(COMP_PLATFORM("dsp-audio"))); + static struct snd_soc_dai_link machine_dais[] = { { .name = "PCM0 System", .stream_name = "System Playback", - .cpu_dai_name = "System Pin", - .platform_name = "dsp-audio", - .codec_name = "snd-soc-dummy", - .codec_dai_name = "snd-soc-dummy-dai", + SND_SOC_DAILINK_REG(pcm0), .dynamic = 1, .trigger = {SND_SOC_DPCM_TRIGGER_POST, SND_SOC_DPCM_TRIGGER_POST}, }, @@ -174,15 +176,16 @@ dynamic and will change depending on runtime config. The BE DAIs are configured as follows :- :: + SND_SOC_DAILINK_DEFS(headset, + DAILINK_COMP_ARRAY(COMP_CPU("ssp-dai.0")), + DAILINK_COMP_ARRAY(COMP_CODEC("rt5640.0-001c", "rt5640-aif1"))); + static struct snd_soc_dai_link machine_dais[] = { .....< FE DAI links here > { .name = "Codec Headset", - .cpu_dai_name = "ssp-dai.0", - .platform_name = "snd-soc-dummy", + SND_SOC_DAILINK_REG(headset), .no_pcm = 1, - .codec_name = "rt5640.0-001c", - .codec_dai_name = "rt5640-aif1", .ignore_suspend = 1, .ignore_pmdown_time = 1, .be_hw_params_fixup = hswult_ssp0_fixup, @@ -362,7 +365,7 @@ The machine driver sets some additional parameters to the DAI link i.e. .codec_dai_name = "modem-aif1", .codec_name = "modem", .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF - | SND_SOC_DAIFMT_CBM_CFM, + | SND_SOC_DAIFMT_CBP_CFP, .c2c_params = &dai_params, .num_c2c_params = 1, } diff --git a/Documentation/sound/soc/machine.rst b/Documentation/sound/soc/machine.rst index 9db132bc0070..1828f5edca3e 100644 --- a/Documentation/sound/soc/machine.rst +++ b/Documentation/sound/soc/machine.rst @@ -75,7 +75,7 @@ In the above struct, dai’s are registered using names but you can pass either dai name or device tree node but not both. Also, names used here for cpu/codec/platform dais should be globally unique. -Additionaly below example macro can be used to register cpu, codec and +Additionally below example macro can be used to register cpu, codec and platform dai:: SND_SOC_DAILINK_DEFS(wm2200_cpu_dsp, diff --git a/Documentation/sphinx/automarkup.py b/Documentation/sphinx/automarkup.py index a413f8dd5115..ecf54d22e9dc 100644 --- a/Documentation/sphinx/automarkup.py +++ b/Documentation/sphinx/automarkup.py @@ -11,13 +11,7 @@ from sphinx.errors import NoUri import re from itertools import chain -# -# Python 2 lacks re.ASCII... -# -try: - ascii_p3 = re.ASCII -except AttributeError: - ascii_p3 = 0 +from kernel_abi import get_kernel_abi # # Regex nastiness. Of course. @@ -26,28 +20,30 @@ except AttributeError: # :c:func: block (i.e. ":c:func:`mmap()`s" flakes out), so the last # bit tries to restrict matches to things that won't create trouble. # -RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=ascii_p3) +RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=re.ASCII) # # Sphinx 2 uses the same :c:type role for struct, union, enum and typedef # RE_generic_type = re.compile(r'\b(struct|union|enum|typedef)\s+([a-zA-Z_]\w+)', - flags=ascii_p3) + flags=re.ASCII) # # Sphinx 3 uses a different C role for each one of struct, union, enum and # typedef # -RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=ascii_p3) -RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=ascii_p3) -RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=ascii_p3) -RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=ascii_p3) +RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=re.ASCII) +RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=re.ASCII) +RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=re.ASCII) +RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=re.ASCII) # # Detects a reference to a documentation page of the form Documentation/... with # an optional extension # RE_doc = re.compile(r'(\bDocumentation/)?((\.\./)*[\w\-/]+)\.(rst|txt)') +RE_abi_file = re.compile(r'(\bDocumentation/ABI/[\w\-/]+)') +RE_abi_symbol = re.compile(r'(\b/(sys|config|proc)/[\w\-/]+)') RE_namespace = re.compile(r'^\s*..\s*c:namespace::\s*(\S+)\s*$') @@ -83,11 +79,10 @@ def markup_refs(docname, app, node): # # Associate each regex with the function that will markup its matches # - markup_func_sphinx2 = {RE_doc: markup_doc_ref, - RE_function: markup_c_ref, - RE_generic_type: markup_c_ref} - markup_func_sphinx3 = {RE_doc: markup_doc_ref, + markup_func = {RE_doc: markup_doc_ref, + RE_abi_file: markup_abi_file_ref, + RE_abi_symbol: markup_abi_ref, RE_function: markup_func_ref_sphinx3, RE_struct: markup_c_ref, RE_union: markup_c_ref, @@ -95,11 +90,6 @@ def markup_refs(docname, app, node): RE_typedef: markup_c_ref, RE_git: markup_git} - if sphinx.version_info[0] >= 3: - markup_func = markup_func_sphinx3 - else: - markup_func = markup_func_sphinx2 - match_iterators = [regex.finditer(t) for regex in markup_func] # # Sort all references by the starting position in text @@ -270,6 +260,54 @@ def markup_doc_ref(docname, app, match): else: return nodes.Text(match.group(0)) +# +# Try to replace a documentation reference for ABI symbols and files +# with a cross reference to that page +# +def markup_abi_ref(docname, app, match, warning=False): + stddom = app.env.domains['std'] + # + # Go through the dance of getting an xref out of the std domain + # + kernel_abi = get_kernel_abi() + + fname = match.group(1) + target = kernel_abi.xref(fname) + + # Kernel ABI doesn't describe such file or symbol + if not target: + if warning: + kernel_abi.log.warning("%s not found", fname) + return nodes.Text(match.group(0)) + + pxref = addnodes.pending_xref('', refdomain = 'std', reftype = 'ref', + reftarget = target, modname = None, + classname = None, refexplicit = False) + + # + # XXX The Latex builder will throw NoUri exceptions here, + # work around that by ignoring them. + # + try: + xref = stddom.resolve_xref(app.env, docname, app.builder, 'ref', + target, pxref, None) + except NoUri: + xref = None + # + # Return the xref if we got it; otherwise just return the plain text. + # + if xref: + return xref + else: + return nodes.Text(match.group(0)) + +# +# Variant of markup_abi_ref() that warns whan a reference is not found +# +def markup_abi_file_ref(docname, app, match): + return markup_abi_ref(docname, app, match, warning=True) + + def get_c_namespace(app, docname): source = app.env.doc2path(docname) with open(source) as f: diff --git a/Documentation/sphinx/cdomain.py b/Documentation/sphinx/cdomain.py index e6959af25402..e8ea80d4324c 100644 --- a/Documentation/sphinx/cdomain.py +++ b/Documentation/sphinx/cdomain.py @@ -1,6 +1,6 @@ # -*- coding: utf-8; mode: python -*- # pylint: disable=W0141,C0113,C0103,C0325 -u""" +""" cdomain ~~~~~~~ @@ -45,9 +45,6 @@ import re __version__ = '1.1' -# Get Sphinx version -major, minor, patch = sphinx.version_info[:3] - # Namespace to be prepended to the full name namespace = None @@ -145,7 +142,7 @@ class CObject(Base_CObject): } def handle_func_like_macro(self, sig, signode): - u"""Handles signatures of function-like macros. + """Handles signatures of function-like macros. If the objtype is 'function' and the signature ``sig`` is a function-like macro, the name of the macro is returned. Otherwise diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py index 5911bd0d7965..db6f0380de94 100644 --- a/Documentation/sphinx/kernel_abi.py +++ b/Documentation/sphinx/kernel_abi.py @@ -2,7 +2,7 @@ # coding=utf-8 # SPDX-License-Identifier: GPL-2.0 # -u""" +""" kernel-abi ~~~~~~~~~~ @@ -14,7 +14,7 @@ u""" :license: GPL Version 2, June 1991 see Linux/COPYING for details. The ``kernel-abi`` (:py:class:`KernelCmd`) directive calls the - scripts/get_abi.pl script to parse the Kernel ABI files. + scripts/get_abi.py script to parse the Kernel ABI files. Overview of directive's argument and options. @@ -32,107 +32,137 @@ u""" """ -import codecs import os -import subprocess -import sys import re -import kernellog +import sys from docutils import nodes, statemachine from docutils.statemachine import ViewList from docutils.parsers.rst import directives, Directive -from docutils.utils.error_reporting import ErrorString from sphinx.util.docutils import switch_source_input +from sphinx.util import logging + +srctree = os.path.abspath(os.environ["srctree"]) +sys.path.insert(0, os.path.join(srctree, "scripts/lib/abi")) + +from abi_parser import AbiParser + +__version__ = "1.0" + +logger = logging.getLogger('kernel_abi') +path = os.path.join(srctree, "Documentation/ABI") -__version__ = '1.0' +_kernel_abi = None + +def get_kernel_abi(): + """ + Initialize kernel_abi global var, if not initialized yet. + + This is needed to avoid warnings during Sphinx module initialization. + """ + global _kernel_abi + + if not _kernel_abi: + # Parse ABI symbols only once + _kernel_abi = AbiParser(path, logger=logger) + _kernel_abi.parse_abi() + _kernel_abi.check_issues() + + return _kernel_abi def setup(app): app.add_directive("kernel-abi", KernelCmd) - return dict( - version = __version__ - , parallel_read_safe = True - , parallel_write_safe = True - ) + return { + "version": __version__, + "parallel_read_safe": True, + "parallel_write_safe": True + } -class KernelCmd(Directive): - u"""KernelABI (``kernel-abi``) directive""" +class KernelCmd(Directive): + """KernelABI (``kernel-abi``) directive""" required_arguments = 1 - optional_arguments = 2 + optional_arguments = 3 has_content = False final_argument_whitespace = True + parser = None option_spec = { - "debug" : directives.flag, - "rst" : directives.unchanged + "debug": directives.flag, + "no-symbols": directives.flag, + "no-files": directives.flag, } def run(self): + kernel_abi = get_kernel_abi() + doc = self.state.document if not doc.settings.file_insertion_enabled: raise self.warning("docutils: file insertion disabled") - srctree = os.path.abspath(os.environ["srctree"]) - - args = [ - os.path.join(srctree, 'scripts/get_abi.pl'), - 'rest', - '--enable-lineno', - '--dir', os.path.join(srctree, 'Documentation', self.arguments[0]), - ] - - if 'rst' in self.options: - args.append('--rst-source') - - lines = subprocess.check_output(args, cwd=os.path.dirname(doc.current_source)).decode('utf-8') - nodeList = self.nestedParse(lines, self.arguments[0]) - return nodeList - - def nestedParse(self, lines, fname): env = self.state.document.settings.env content = ViewList() node = nodes.section() - if "debug" in self.options: - code_block = "\n\n.. code-block:: rst\n :linenos:\n" - for l in lines.split("\n"): - code_block += "\n " + l - lines = code_block + "\n\n" + abi_type = self.arguments[0] - line_regex = re.compile(r"^\.\. LINENO (\S+)\#([0-9]+)$") - ln = 0 - n = 0 - f = fname + if "no-symbols" in self.options: + show_symbols = False + else: + show_symbols = True - for line in lines.split("\n"): - n = n + 1 - match = line_regex.search(line) - if match: - new_f = match.group(1) + if "no-files" in self.options: + show_file = False + else: + show_file = True - # Sphinx parser is lazy: it stops parsing contents in the - # middle, if it is too big. So, handle it per input file - if new_f != f and content: - self.do_parse(content, node) - content = ViewList() + tab_width = self.options.get('tab-width', + self.state.document.settings.tab_width) - # Add the file to Sphinx build dependencies - env.note_dependency(os.path.abspath(f)) - - f = new_f - - # sphinx counts lines from 0 - ln = int(match.group(2)) - 1 + old_f = None + n = 0 + n_sym = 0 + for msg, f, ln in kernel_abi.doc(show_file=show_file, + show_symbols=show_symbols, + filter_path=abi_type): + n_sym += 1 + msg_list = statemachine.string2lines(msg, tab_width, + convert_whitespace=True) + if "debug" in self.options: + lines = [ + "", "", ".. code-block:: rst", + " :linenos:", "" + ] + for m in msg_list: + lines.append(" " + m) else: - content.append(line, f, ln) - - kernellog.info(self.state.document.settings.env.app, "%s: parsed %i lines" % (fname, n)) + lines = msg_list - if content: - self.do_parse(content, node) + for line in lines: + # sphinx counts lines from 0 + content.append(line, f, ln - 1) + n += 1 + + if f != old_f: + # Add the file to Sphinx build dependencies + env.note_dependency(os.path.abspath(f)) + + old_f = f + + # Sphinx doesn't like to parse big messages. So, let's + # add content symbol by symbol + if content: + self.do_parse(content, node) + content = ViewList() + + if show_symbols and not show_file: + logger.verbose("%s ABI: %i symbols (%i ReST lines)" % (abi_type, n_sym, n)) + elif not show_symbols and show_file: + logger.verbose("%s ABI: %i files (%i ReST lines)" % (abi_type, n_sym, n)) + else: + logger.verbose("%s ABI: %i data (%i ReST lines)" % (abi_type, n_sym, n)) return node.children diff --git a/Documentation/sphinx/kernel_feat.py b/Documentation/sphinx/kernel_feat.py index 03ace5f01b5c..e3a51867f27b 100644 --- a/Documentation/sphinx/kernel_feat.py +++ b/Documentation/sphinx/kernel_feat.py @@ -1,7 +1,7 @@ # coding=utf-8 # SPDX-License-Identifier: GPL-2.0 # -u""" +""" kernel-feat ~~~~~~~~~~~ @@ -56,7 +56,7 @@ def setup(app): class KernelFeat(Directive): - u"""KernelFeat (``kernel-feat``) directive""" + """KernelFeat (``kernel-feat``) directive""" required_arguments = 1 optional_arguments = 2 diff --git a/Documentation/sphinx/kernel_include.py b/Documentation/sphinx/kernel_include.py index 638762442336..8db176045bc5 100755 --- a/Documentation/sphinx/kernel_include.py +++ b/Documentation/sphinx/kernel_include.py @@ -2,7 +2,7 @@ # -*- coding: utf-8; mode: python -*- # pylint: disable=R0903, C0330, R0914, R0912, E0401 -u""" +""" kernel-include ~~~~~~~~~~~~~~ @@ -56,7 +56,7 @@ def setup(app): class KernelInclude(Include): # ============================================================================== - u"""KernelInclude (``kernel-include``) directive""" + """KernelInclude (``kernel-include``) directive""" def run(self): env = self.state.document.settings.env diff --git a/Documentation/sphinx/kerneldoc.py b/Documentation/sphinx/kerneldoc.py index ec1ddfff1863..39ddae6ae7dd 100644 --- a/Documentation/sphinx/kerneldoc.py +++ b/Documentation/sphinx/kerneldoc.py @@ -39,7 +39,7 @@ from docutils.statemachine import ViewList from docutils.parsers.rst import directives, Directive import sphinx from sphinx.util.docutils import switch_source_input -import kernellog +from sphinx.util import logging __version__ = '1.0' @@ -56,16 +56,12 @@ class KernelDocDirective(Directive): 'functions': directives.unchanged, } has_content = False + logger = logging.getLogger('kerneldoc') def run(self): env = self.state.document.settings.env cmd = [env.config.kerneldoc_bin, '-rst', '-enable-lineno'] - # Pass the version string to kernel-doc, as it needs to use a different - # dialect, depending what the C domain supports for each specific - # Sphinx versions - cmd += ['-sphinx-version', sphinx.__version__] - filename = env.config.kerneldoc_srctree + '/' + self.arguments[0] export_file_patterns = [] @@ -109,8 +105,7 @@ class KernelDocDirective(Directive): cmd += [filename] try: - kernellog.verbose(env.app, - 'calling kernel-doc \'%s\'' % (" ".join(cmd))) + self.logger.verbose("calling kernel-doc '%s'" % (" ".join(cmd))) p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE) out, err = p.communicate() @@ -120,8 +115,8 @@ class KernelDocDirective(Directive): if p.returncode != 0: sys.stderr.write(err) - kernellog.warn(env.app, - 'kernel-doc \'%s\' failed with return code %d' % (" ".join(cmd), p.returncode)) + self.logger.warning("kernel-doc '%s' failed with return code %d" + % (" ".join(cmd), p.returncode)) return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))] elif env.config.kerneldoc_verbosity > 0: sys.stderr.write(err) @@ -148,8 +143,8 @@ class KernelDocDirective(Directive): return node.children except Exception as e: # pylint: disable=W0703 - kernellog.warn(env.app, 'kernel-doc \'%s\' processing failed with: %s' % - (" ".join(cmd), str(e))) + self.logger.warning("kernel-doc '%s' processing failed with: %s" % + (" ".join(cmd), str(e))) return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))] def do_parse(self, result, node): diff --git a/Documentation/sphinx/kernellog.py b/Documentation/sphinx/kernellog.py deleted file mode 100644 index 0bc00c138cad..000000000000 --- a/Documentation/sphinx/kernellog.py +++ /dev/null @@ -1,22 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 -# -# Sphinx has deprecated its older logging interface, but the replacement -# only goes back to 1.6. So here's a wrapper layer to keep around for -# as long as we support 1.4. -# -# We don't support 1.4 anymore, but we'll keep the wrappers around until -# we change all the code to not use them anymore :) -# -import sphinx -from sphinx.util import logging - -logger = logging.getLogger('kerneldoc') - -def warn(app, message): - logger.warning(message) - -def verbose(app, message): - logger.verbose(message) - -def info(app, message): - logger.info(message) diff --git a/Documentation/sphinx/kfigure.py b/Documentation/sphinx/kfigure.py index 97166333b727..f1a7f13c9c60 100644 --- a/Documentation/sphinx/kfigure.py +++ b/Documentation/sphinx/kfigure.py @@ -1,6 +1,6 @@ # -*- coding: utf-8; mode: python -*- # pylint: disable=C0103, R0903, R0912, R0915 -u""" +""" scalable figure and image handling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -59,12 +59,14 @@ from docutils.parsers.rst import directives from docutils.parsers.rst.directives import images import sphinx from sphinx.util.nodes import clean_astext -import kernellog +from sphinx.util import logging Figure = images.Figure __version__ = '1.0.0' +logger = logging.getLogger('kfigure') + # simple helper # ------------- @@ -163,14 +165,14 @@ def setup(app): def setupTools(app): - u""" + """ Check available build tools and log some *verbose* messages. This function is called once, when the builder is initiated. """ global dot_cmd, dot_Tpdf, convert_cmd, rsvg_convert_cmd # pylint: disable=W0603 global inkscape_cmd, inkscape_ver_one # pylint: disable=W0603 - kernellog.verbose(app, "kfigure: check installed tools ...") + logger.verbose("kfigure: check installed tools ...") dot_cmd = which('dot') convert_cmd = which('convert') @@ -178,7 +180,7 @@ def setupTools(app): inkscape_cmd = which('inkscape') if dot_cmd: - kernellog.verbose(app, "use dot(1) from: " + dot_cmd) + logger.verbose("use dot(1) from: " + dot_cmd) try: dot_Thelp_list = subprocess.check_output([dot_cmd, '-Thelp'], @@ -190,10 +192,11 @@ def setupTools(app): dot_Tpdf_ptn = b'pdf' dot_Tpdf = re.search(dot_Tpdf_ptn, dot_Thelp_list) else: - kernellog.warn(app, "dot(1) not found, for better output quality install " - "graphviz from https://www.graphviz.org") + logger.warning( + "dot(1) not found, for better output quality install graphviz from https://www.graphviz.org" + ) if inkscape_cmd: - kernellog.verbose(app, "use inkscape(1) from: " + inkscape_cmd) + logger.verbose("use inkscape(1) from: " + inkscape_cmd) inkscape_ver = subprocess.check_output([inkscape_cmd, '--version'], stderr=subprocess.DEVNULL) ver_one_ptn = b'Inkscape 1' @@ -204,26 +207,27 @@ def setupTools(app): else: if convert_cmd: - kernellog.verbose(app, "use convert(1) from: " + convert_cmd) + logger.verbose("use convert(1) from: " + convert_cmd) else: - kernellog.verbose(app, + logger.verbose( "Neither inkscape(1) nor convert(1) found.\n" - "For SVG to PDF conversion, " - "install either Inkscape (https://inkscape.org/) (preferred) or\n" - "ImageMagick (https://www.imagemagick.org)") + "For SVG to PDF conversion, install either Inkscape (https://inkscape.org/) (preferred) or\n" + "ImageMagick (https://www.imagemagick.org)" + ) if rsvg_convert_cmd: - kernellog.verbose(app, "use rsvg-convert(1) from: " + rsvg_convert_cmd) - kernellog.verbose(app, "use 'dot -Tsvg' and rsvg-convert(1) for DOT -> PDF conversion") + logger.verbose("use rsvg-convert(1) from: " + rsvg_convert_cmd) + logger.verbose("use 'dot -Tsvg' and rsvg-convert(1) for DOT -> PDF conversion") dot_Tpdf = False else: - kernellog.verbose(app, + logger.verbose( "rsvg-convert(1) not found.\n" - " SVG rendering of convert(1) is done by ImageMagick-native renderer.") + " SVG rendering of convert(1) is done by ImageMagick-native renderer." + ) if dot_Tpdf: - kernellog.verbose(app, "use 'dot -Tpdf' for DOT -> PDF conversion") + logger.verbose("use 'dot -Tpdf' for DOT -> PDF conversion") else: - kernellog.verbose(app, "use 'dot -Tsvg' and convert(1) for DOT -> PDF conversion") + logger.verbose("use 'dot -Tsvg' and convert(1) for DOT -> PDF conversion") # integrate conversion tools @@ -257,13 +261,12 @@ def convert_image(img_node, translator, src_fname=None): # in kernel builds, use 'make SPHINXOPTS=-v' to see verbose messages - kernellog.verbose(app, 'assert best format for: ' + img_node['uri']) + logger.verbose('assert best format for: ' + img_node['uri']) if in_ext == '.dot': if not dot_cmd: - kernellog.verbose(app, - "dot from graphviz not available / include DOT raw.") + logger.verbose("dot from graphviz not available / include DOT raw.") img_node.replace_self(file2literal(src_fname)) elif translator.builder.format == 'latex': @@ -290,10 +293,11 @@ def convert_image(img_node, translator, src_fname=None): if translator.builder.format == 'latex': if not inkscape_cmd and convert_cmd is None: - kernellog.warn(app, - "no SVG to PDF conversion available / include SVG raw." - "\nIncluding large raw SVGs can cause xelatex error." - "\nInstall Inkscape (preferred) or ImageMagick.") + logger.warning( + "no SVG to PDF conversion available / include SVG raw.\n" + "Including large raw SVGs can cause xelatex error.\n" + "Install Inkscape (preferred) or ImageMagick." + ) img_node.replace_self(file2literal(src_fname)) else: dst_fname = path.join(translator.builder.outdir, fname + '.pdf') @@ -306,15 +310,14 @@ def convert_image(img_node, translator, src_fname=None): _name = dst_fname[len(str(translator.builder.outdir)) + 1:] if isNewer(dst_fname, src_fname): - kernellog.verbose(app, - "convert: {out}/%s already exists and is newer" % _name) + logger.verbose("convert: {out}/%s already exists and is newer" % _name) else: ok = False mkdir(path.dirname(dst_fname)) if in_ext == '.dot': - kernellog.verbose(app, 'convert DOT to: {out}/' + _name) + logger.verbose('convert DOT to: {out}/' + _name) if translator.builder.format == 'latex' and not dot_Tpdf: svg_fname = path.join(translator.builder.outdir, fname + '.svg') ok1 = dot2format(app, src_fname, svg_fname) @@ -325,7 +328,7 @@ def convert_image(img_node, translator, src_fname=None): ok = dot2format(app, src_fname, dst_fname) elif in_ext == '.svg': - kernellog.verbose(app, 'convert SVG to: {out}/' + _name) + logger.verbose('convert SVG to: {out}/' + _name) ok = svg2pdf(app, src_fname, dst_fname) if not ok: @@ -354,7 +357,7 @@ def dot2format(app, dot_fname, out_fname): with open(out_fname, "w") as out: exit_code = subprocess.call(cmd, stdout = out) if exit_code != 0: - kernellog.warn(app, + logger.warning( "Error #%d when calling: %s" % (exit_code, " ".join(cmd))) return bool(exit_code == 0) @@ -388,13 +391,14 @@ def svg2pdf(app, svg_fname, pdf_fname): pass if exit_code != 0: - kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd))) + logger.warning("Error #%d when calling: %s" % + (exit_code, " ".join(cmd))) if warning_msg: - kernellog.warn(app, "Warning msg from %s: %s" - % (cmd_name, str(warning_msg, 'utf-8'))) + logger.warning( "Warning msg from %s: %s" % + (cmd_name, str(warning_msg, 'utf-8'))) elif warning_msg: - kernellog.verbose(app, "Warning msg from %s (likely harmless):\n%s" - % (cmd_name, str(warning_msg, 'utf-8'))) + logger.verbose("Warning msg from %s (likely harmless):\n%s" % + (cmd_name, str(warning_msg, 'utf-8'))) return bool(exit_code == 0) @@ -418,7 +422,8 @@ def svg2pdf_by_rsvg(app, svg_fname, pdf_fname): # use stdout and stderr from parent exit_code = subprocess.call(cmd) if exit_code != 0: - kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd))) + logger.warning("Error #%d when calling: %s" % + (exit_code, " ".join(cmd))) ok = bool(exit_code == 0) return ok @@ -440,7 +445,7 @@ class kernel_image(nodes.image): pass class KernelImage(images.Image): - u"""KernelImage directive + """KernelImage directive Earns everything from ``.. image::`` directive, except *remote URI* and *glob* pattern. The KernelImage wraps a image node into a @@ -476,7 +481,7 @@ class kernel_figure(nodes.figure): """Node for ``kernel-figure`` directive.""" class KernelFigure(Figure): - u"""KernelImage directive + """KernelImage directive Earns everything from ``.. figure::`` directive, except *remote URI* and *glob* pattern. The KernelFigure wraps a figure node into a kernel_figure @@ -513,15 +518,15 @@ def visit_kernel_render(self, node): app = self.builder.app srclang = node.get('srclang') - kernellog.verbose(app, 'visit kernel-render node lang: "%s"' % (srclang)) + logger.verbose('visit kernel-render node lang: "%s"' % srclang) tmp_ext = RENDER_MARKUP_EXT.get(srclang, None) if tmp_ext is None: - kernellog.warn(app, 'kernel-render: "%s" unknown / include raw.' % (srclang)) + logger.warning( 'kernel-render: "%s" unknown / include raw.' % srclang) return if not dot_cmd and tmp_ext == '.dot': - kernellog.verbose(app, "dot from graphviz not available / include raw.") + logger.verbose("dot from graphviz not available / include raw.") return literal_block = node[0] @@ -552,7 +557,7 @@ class kernel_render(nodes.General, nodes.Inline, nodes.Element): pass class KernelRender(Figure): - u"""KernelRender directive + """KernelRender directive Render content by external tool. Has all the options known from the *figure* directive, plus option ``caption``. If ``caption`` has a diff --git a/Documentation/sphinx/load_config.py b/Documentation/sphinx/load_config.py index 8b416bfd75ac..ec50e1ee5223 100644 --- a/Documentation/sphinx/load_config.py +++ b/Documentation/sphinx/load_config.py @@ -9,7 +9,7 @@ from sphinx.util.osutil import fs_encoding def loadConfig(namespace): # ------------------------------------------------------------------------------ - u"""Load an additional configuration file into *namespace*. + """Load an additional configuration file into *namespace*. The name of the configuration file is taken from the environment ``SPHINX_CONF``. The external configuration file extends (or overwrites) the diff --git a/Documentation/sphinx/maintainers_include.py b/Documentation/sphinx/maintainers_include.py index dcad0fff4723..d31cff867436 100755 --- a/Documentation/sphinx/maintainers_include.py +++ b/Documentation/sphinx/maintainers_include.py @@ -3,7 +3,7 @@ # -*- coding: utf-8; mode: python -*- # pylint: disable=R0903, C0330, R0914, R0912, E0401 -u""" +""" maintainers-include ~~~~~~~~~~~~~~~~~~~ @@ -37,7 +37,7 @@ def setup(app): ) class MaintainersInclude(Include): - u"""MaintainersInclude (``maintainers-include``) directive""" + """MaintainersInclude (``maintainers-include``) directive""" required_arguments = 0 def parse_maintainers(self, path): diff --git a/Documentation/sphinx/rstFlatTable.py b/Documentation/sphinx/rstFlatTable.py index 16bea0632555..180fbb50c337 100755 --- a/Documentation/sphinx/rstFlatTable.py +++ b/Documentation/sphinx/rstFlatTable.py @@ -2,7 +2,7 @@ # -*- coding: utf-8; mode: python -*- # pylint: disable=C0330, R0903, R0912 -u""" +""" flat-table ~~~~~~~~~~ @@ -99,7 +99,7 @@ class colSpan(nodes.General, nodes.Element): pass # pylint: disable=C0103,C0321 class FlatTable(Table): # ============================================================================== - u"""FlatTable (``flat-table``) directive""" + """FlatTable (``flat-table``) directive""" option_spec = { 'name': directives.unchanged @@ -135,7 +135,7 @@ class FlatTable(Table): class ListTableBuilder(object): # ============================================================================== - u"""Builds a table from a double-stage list""" + """Builds a table from a double-stage list""" def __init__(self, directive): self.directive = directive @@ -212,7 +212,7 @@ class ListTableBuilder(object): raise SystemMessagePropagation(error) def parseFlatTableNode(self, node): - u"""parses the node from a :py:class:`FlatTable` directive's body""" + """parses the node from a :py:class:`FlatTable` directive's body""" if len(node) != 1 or not isinstance(node[0], nodes.bullet_list): self.raiseError( @@ -225,7 +225,7 @@ class ListTableBuilder(object): self.roundOffTableDefinition() def roundOffTableDefinition(self): - u"""Round off the table definition. + """Round off the table definition. This method rounds off the table definition in :py:member:`rows`. 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/tools/rv/rv-mon-sched.rst b/Documentation/tools/rv/rv-mon-sched.rst new file mode 100644 index 000000000000..da0fe4c79ae5 --- /dev/null +++ b/Documentation/tools/rv/rv-mon-sched.rst @@ -0,0 +1,69 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============ +rv-mon-sched +============ +----------------------------- +Scheduler monitors collection +----------------------------- + +:Manual section: 1 + +SYNOPSIS +======== + +**rv mon sched** [*OPTIONS*] + +**rv mon <NESTED_MONITOR>** [*OPTIONS*] + +**rv mon sched:<NESTED_MONITOR>** [*OPTIONS*] + +DESCRIPTION +=========== + +The scheduler monitor collection is a container for several monitors to model +the behaviour of the scheduler. Each monitor describes a specification that +the scheduler should follow. + +As a monitor container, it will enable all nested monitors and set them +according to OPTIONS. +Nevertheless nested monitors can also be activated independently both by name +and by specifying sched: , e.g. to enable only monitor tss you can do any of: + + # rv mon sched:tss + + # rv mon tss + +See kernel documentation for further information about this monitor: +<https://docs.kernel.org/trace/rv/monitor_sched.html> + +OPTIONS +======= + +.. include:: common_ikm.rst + +NESTED MONITOR +============== + +The available nested monitors are: + * scpd: schedule called with preemption disabled + * snep: schedule does not enable preempt + * sncid: schedule not called with interrupt disabled + * snroc: set non runnable on its own context + * sco: scheduling context operations + * tss: task switch while scheduling + +SEE ALSO +======== + +**rv**\(1), **rv-mon**\(1) + +Linux kernel *RV* documentation: +<https://www.kernel.org/doc/html/latest/trace/rv/index.html> + +AUTHOR +====== + +Written by Gabriele Monaco <gmonaco@redhat.com> + +.. include:: common_appendix.rst 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/postprocess/decode_msr.py b/Documentation/trace/postprocess/decode_msr.py index aa9cc7abd5c2..f5609b16f589 100644 --- a/Documentation/trace/postprocess/decode_msr.py +++ b/Documentation/trace/postprocess/decode_msr.py @@ -32,6 +32,6 @@ for j in sys.stdin: break if r: j = j.replace(" " + m.group(2), " " + r + "(" + m.group(2) + ")") - print j, + print(j) 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/trace/rv/monitor_sched.rst b/Documentation/trace/rv/monitor_sched.rst new file mode 100644 index 000000000000..24b2c62a3bc2 --- /dev/null +++ b/Documentation/trace/rv/monitor_sched.rst @@ -0,0 +1,171 @@ +Scheduler monitors +================== + +- Name: sched +- Type: container for multiple monitors +- Author: Gabriele Monaco <gmonaco@redhat.com>, Daniel Bristot de Oliveira <bristot@kernel.org> + +Description +----------- + +Monitors describing complex systems, such as the scheduler, can easily grow to +the point where they are just hard to understand because of the many possible +state transitions. +Often it is possible to break such descriptions into smaller monitors, +sharing some or all events. Enabling those smaller monitors concurrently is, +in fact, testing the system as if we had one single larger monitor. +Splitting models into multiple specification is not only easier to +understand, but gives some more clues when we see errors. + +The sched monitor is a set of specifications to describe the scheduler behaviour. +It includes several per-cpu and per-task monitors that work independently to verify +different specifications the scheduler should follow. + +To make this system as straightforward as possible, sched specifications are *nested* +monitors, whereas sched itself is a *container*. +From the interface perspective, sched includes other monitors as sub-directories, +enabling/disabling or setting reactors to sched, propagates the change to all monitors, +however single monitors can be used independently as well. + +It is important that future modules are built after their container (sched, in +this case), otherwise the linker would not respect the order and the nesting +wouldn't work as expected. +To do so, simply add them after sched in the Makefile. + +Specifications +-------------- + +The specifications included in sched are currently a work in progress, adapting the ones +defined in by Daniel Bristot in [1]. + +Currently we included the following: + +Monitor tss +~~~~~~~~~~~ + +The task switch while scheduling (tss) monitor ensures a task switch happens +only in scheduling context, that is inside a call to `__schedule`:: + + | + | + v + +-----------------+ + | thread | <+ + +-----------------+ | + | | + | schedule_entry | schedule_exit + v | + sched_switch | + +--------------- | + | sched | + +--------------> -+ + +Monitor sco +~~~~~~~~~~~ + +The scheduling context operations (sco) monitor ensures changes in a task state +happen only in thread context:: + + + | + | + v + sched_set_state +------------------+ + +------------------ | | + | | thread_context | + +-----------------> | | <+ + +------------------+ | + | | + | schedule_entry | schedule_exit + v | + | + scheduling_context -+ + +Monitor snroc +~~~~~~~~~~~~~ + +The set non runnable on its own context (snroc) monitor ensures changes in a +task state happens only in the respective task's context. This is a per-task +monitor:: + + | + | + v + +------------------+ + | other_context | <+ + +------------------+ | + | | + | sched_switch_in | sched_switch_out + v | + sched_set_state | + +------------------ | + | own_context | + +-----------------> -+ + +Monitor scpd +~~~~~~~~~~~~ + +The schedule called with preemption disabled (scpd) monitor ensures schedule is +called with preemption disabled:: + + | + | + v + +------------------+ + | cant_sched | <+ + +------------------+ | + | | + | preempt_disable | preempt_enable + v | + schedule_entry | + schedule_exit | + +----------------- can_sched | + | | + +----------------> -+ + +Monitor snep +~~~~~~~~~~~~ + +The schedule does not enable preempt (snep) monitor ensures a schedule call +does not enable preemption:: + + | + | + v + preempt_disable +------------------------+ + preempt_enable | | + +------------------ | non_scheduling_context | + | | | + +-----------------> | | <+ + +------------------------+ | + | | + | schedule_entry | schedule_exit + v | + | + scheduling_contex -+ + +Monitor sncid +~~~~~~~~~~~~~ + +The schedule not called with interrupt disabled (sncid) monitor ensures +schedule is not called with interrupt disabled:: + + | + | + v + schedule_entry +--------------+ + schedule_exit | | + +----------------- | can_sched | + | | | + +----------------> | | <+ + +--------------+ | + | | + | irq_disable | irq_enable + v | + | + cant_sched -+ + +References +---------- + +[1] - https://bristot.me/linux-task-model diff --git a/Documentation/translations/it_IT/process/submit-checklist.rst b/Documentation/translations/it_IT/process/submit-checklist.rst index 692be4af9c9b..5bf1b4adebc1 100644 --- a/Documentation/translations/it_IT/process/submit-checklist.rst +++ b/Documentation/translations/it_IT/process/submit-checklist.rst @@ -58,9 +58,10 @@ Fornite documentazione 4) Tutti i nuovi parametri dei moduli sono documentati con ``MODULE_PARM_DESC()``. 5) Tutte le nuove interfacce verso lo spazio utente sono documentate in - ``Documentation/ABI/``. Leggete ``Documentation/ABI/README`` per maggiori - informazioni. Le patch che modificano le interfacce utente dovrebbero - essere inviate in copia anche a linux-api@vger.kernel.org. + ``Documentation/ABI/``. Leggete Documentation/admin-guide/abi.rst + (o ``Documentation/ABI/README``) per maggiori informazioni. + Le patch che modificano le interfacce utente dovrebbero essere inviate + in copia anche a linux-api@vger.kernel.org. 6) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate ``Documentation/userspace-api/ioctl/ioctl-number.rst``. diff --git a/Documentation/translations/ja_JP/SubmitChecklist b/Documentation/translations/ja_JP/SubmitChecklist deleted file mode 100644 index 1759c6b452d6..000000000000 --- a/Documentation/translations/ja_JP/SubmitChecklist +++ /dev/null @@ -1,105 +0,0 @@ -NOTE: -This is a version of Documentation/process/submit-checklist.rst into Japanese. -This document is maintained by Takenori Nagano <t-nagano@ah.jp.nec.com> -and the JF Project team <http://www.linux.or.jp/JF/>. -If you find any difference between this document and the original file -or a problem with the translation, -please contact the maintainer of this file or JF project. - -Please also note that the purpose of this file is to be easier to read -for non English (read: Japanese) speakers and is not intended as a -fork. So if you have any comments or updates of this file, please try -to update the original English file first. - -Last Updated: 2008/07/14 -================================== -これは、 -linux-2.6.26/Documentation/process/submit-checklist.rst の和訳です。 - -翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ > -翻訳日： 2008/07/14 -翻訳者： Takenori Nagano <t-nagano at ah dot jp dot nec dot com> -校正者： Masanori Kobayashi さん <zap03216 at nifty dot ne dot jp> -================================== - - -Linux カーネルパッチ投稿者向けチェックリスト -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -本書では、パッチをより素早く取り込んでもらいたい開発者が実践すべき基本的な事柄 -をいくつか紹介します。ここにある全ての事柄は、Documentation/process/submitting-patches.rst -などのLinuxカーネルパッチ投稿に際しての心得を補足するものです。 - - 1: 妥当なCONFIGオプションや変更されたCONFIGオプション、つまり =y, =m, =n - 全てで正しくビルドできることを確認してください。その際、gcc及びリンカが - warningやerrorを出していないことも確認してください。 - - 2: allnoconfig, allmodconfig オプションを用いて正しくビルドできることを - 確認してください。 - - 3: 手許のクロスコンパイルツールやOSDLのPLMのようなものを用いて、複数の - アーキテクチャにおいても正しくビルドできることを確認してください。 - - 4: 64bit長の'unsigned long'を使用しているppc64は、クロスコンパイルでの - チェックに適当なアーキテクチャです。 - - 5: カーネルコーディングスタイルに準拠しているかどうか確認してください(!) - - 6: CONFIGオプションの追加・変更をした場合には、CONFIGメニューが壊れていない - ことを確認してください。 - - 7: 新しくKconfigのオプションを追加する際には、必ずそのhelpも記述してください。 - - 8: 適切なKconfigの依存関係を考えながら慎重にチェックしてください。 - ただし、この作業はマシンを使ったテストできちんと行うのがとても困難です。 - うまくやるには、自分の頭で考えることです。 - - 9: sparseを利用してちゃんとしたコードチェックをしてください。 - -10: 'make checkstack' を利用し、問題が発見されたら修正してください。 - 'make checkstack' は明示的に問題を示しませんが、どれか - １つの関数が512バイトより大きいスタックを使っていれば、修正すべき候補と - なります。 - -11: グローバルなkernel API を説明する kernel-doc をソースの中に含めてください。 - ( staticな関数においては必須ではありませんが、含めてもらっても結構です ) - そして、'make htmldocs' もしくは 'make mandocs' を利用して追記した - ドキュメントのチェックを行い、問題が見つかった場合には修正を行ってください。 - -12: CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SLAB, - CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK, - CONFIG_DEBUG_ATOMIC_SLEEP これら全てを同時に有効にして動作確認を - 行ってください。 - -13: CONFIG_SMP, CONFIG_PREEMPT を有効にした場合と無効にした場合の両方で - ビルドした上、動作確認を行ってください。 - -14: lockdepの機能を全て有効にした上で、全てのコードパスを評価してください。 - -15: /proc に新しいエントリを追加した場合には、Documentation/ 配下に - 必ずドキュメントを追加してください。 - -16: 新しいブートパラメータを追加した場合には、 - 必ずDocumentation/admin-guide/kernel-parameters.rst に説明を追加してください。 - -17: 新しくmoduleにパラメータを追加した場合には、MODULE_PARM_DESC()を - 利用して必ずその説明を記述してください。 - -18: 新しいuserspaceインタフェースを作成した場合には、Documentation/ABI/ に - Documentation/ABI/README を参考にして必ずドキュメントを追加してください。 - -19: 少なくともslabアロケーションとpageアロケーションに失敗した場合の - 挙動について、fault-injectionを利用して確認してください。 - Documentation/fault-injection/ を参照してください。 - - 追加したコードがかなりの量であったならば、サブシステム特有の - fault-injectionを追加したほうが良いかもしれません。 - -20: 新たに追加したコードは、`gcc -W'でコンパイルしてください。 - このオプションは大量の不要なメッセージを出力しますが、 - "warning: comparison between signed and unsigned" のようなメッセージは、 - バグを見つけるのに役に立ちます。 - -21: 投稿したパッチが -mm パッチセットにマージされた後、全ての既存のパッチや - VM, VFS およびその他のサブシステムに関する様々な変更と、現時点でも共存 - できることを確認するテストを行ってください。 diff --git a/Documentation/translations/ja_JP/disclaimer-ja_JP.rst b/Documentation/translations/ja_JP/disclaimer-ja_JP.rst new file mode 100644 index 000000000000..46a026000407 --- /dev/null +++ b/Documentation/translations/ja_JP/disclaimer-ja_JP.rst @@ -0,0 +1,24 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _translations_ja_JP_disclaimer: + +========================== +免責条項 (Disclaimer) 抄訳 +========================== + +.. note:: 【訳註】 + この文書は、 + :ref:`Disclaimer (英語版) <translations_disclaimer>` + の一部を翻訳したものです。全文は英語版を参照願います。 + +Documentation/translations/ja_JP/ 以下のファイルは、対応する +Documentation/ 以下のファイル (原文) の日本語訳です。 +翻訳と原文との違いや翻訳上の問題を見つけたら、 +MAINTAINERS に記載の維持管理者に知らせてください。 +翻訳が原文の更新に追いついていない場合は、それを日本語版に反映するパッチの +投稿も歓迎です。 + +なお、この翻訳の目的は非英語 (ここでは日本語) 話者への便宜提供であり、 +フォークを意図したものではない事を念頭においてください。したがって、 +このファイルの内容に対するコメントや更新すべきことがあれば、先に原文の +更新を検討してください。 diff --git a/Documentation/translations/ja_JP/index.rst b/Documentation/translations/ja_JP/index.rst index 0b476b429e3b..4159b417bfdd 100644 --- a/Documentation/translations/ja_JP/index.rst +++ b/Documentation/translations/ja_JP/index.rst @@ -11,7 +11,9 @@ .. toctree:: :maxdepth: 1 + disclaimer-ja_JP process/howto + process/submit-checklist .. raw:: latex diff --git a/Documentation/translations/ja_JP/process/howto.rst b/Documentation/translations/ja_JP/process/howto.rst index d9ba40588e46..5e307f90982c 100644 --- a/Documentation/translations/ja_JP/process/howto.rst +++ b/Documentation/translations/ja_JP/process/howto.rst @@ -1,35 +1,18 @@ -.. raw:: latex +.. SPDX-License-Identifier: GPL-2.0 - \kerneldocCJKoff - -NOTE: -This is a version of Documentation/process/howto.rst translated into Japanese. -This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com> -If you find any difference between this document and the original file or -a problem with the translation, please contact the maintainer of this file. - -Please also note that the purpose of this file is to be easier to -read for non English (read: Japanese) speakers and is not intended as -a fork. So if you have any comments or updates for this file, please -try to update the original English file first. - ----------------------------------- - -.. raw:: latex - - \kerneldocCJKon - -この文書は、 -Documentation/process/howto.rst -の和訳です。 - -翻訳者： Tsugikazu Shibata <tshibata@ab.jp.nec.com> - ----------------------------------- +.. Originally contributed by Tsugikazu Shibata Linux カーネル開発のやり方 ========================== +.. note:: 【訳註】 + この文書は、 + Documentation/process/howto.rst + の翻訳です。 + 免責条項については、 + :ref:`免責条項の抄訳 <translations_ja_JP_disclaimer>` および、 + :ref:`Disclaimer (英語版) <translations_disclaimer>` を参照してください。 + これは上のトピック( Linux カーネル開発のやり方)の重要な事柄を網羅した ドキュメントです。ここには Linux カーネル開発者になるための方法とLinux カーネル開発コミュニティと共に活動するやり方を学ぶ方法が含まれています。 diff --git a/Documentation/translations/ja_JP/process/submit-checklist.rst b/Documentation/translations/ja_JP/process/submit-checklist.rst new file mode 100644 index 000000000000..fb3b9e3bd8ee --- /dev/null +++ b/Documentation/translations/ja_JP/process/submit-checklist.rst @@ -0,0 +1,163 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. Translated by Akira Yokosawa <akiyks@gmail.com> + +.. An old translation of this document of a different origin was at + Documentation/translations/ja_JP/SubmitChecklist, which can be found + in the pre-v6.14 tree if you are interested. + Please note that this translation is independent of the previous one. + +====================================== +Linux カーネルパッチ投稿チェックリスト +====================================== + +.. note:: 【訳註】 + この文書は、 + Documentation/process/submit-checklist.rst + の翻訳です。 + 免責条項については、 + :ref:`免責条項の抄訳 <translations_ja_JP_disclaimer>` および、 + :ref:`Disclaimer (英語版) <translations_disclaimer>` を参照してください。 + +以下は、カーネルパッチの投稿時に、そのスムーズな受け入れのために心がける +べき基本的な事項です。 + +これは、 Documentation/process/submitting-patches.rst およびその他の +Linux カーネルパッチ投稿に関する文書を踏まえ、それを補足するものです。 + +.. note:: 【訳註】 + 可能な項目については、パッチもしくはパッチ内の更新を暗黙の主語として、 + その望ましい状態を表す文体とします。その他、原義を損なわない範囲で + 係り結びを調整するなど、簡潔で把握しやすい箇条書きを目指します。 + + +コードのレビュー +================ + +1) 利用する機能について、その機能を定義・宣言しているファイルを + ``#include`` している。 + 他のヘッダーファイル経由での取り込みに依存しない。 + +2) Documentation/process/coding-style.rst に詳述されている一般的なスタイル + についてチェック済み。 + +3) メモリバリアー (例, ``barrier()``, ``rmb()``, ``wmb()``) について、 + そのすべてに、作用と目的、及び必要理由についての説明がソースコード内の + コメントとして記述されている。 + + +Kconfig 変更のレビュー +====================== + +1) 新規の、もしくは変更された ``CONFIG`` オプションについて、それが関係する + コンフィグメニューへの悪影響がない。また、 + Documentation/kbuild/kconfig-language.rst の + "Menu attibutes: default value" に記載の例外条件を満たす場合を除き、 + そのデフォルトが無効になっている。 + +2) 新規の ``Kconfig`` オプションにヘルプテキストがある。 + +3) 妥当な ``Kconfig`` の組み合わせについて注意深くレビューされている。 + これをテストでやり切るのは困難で、知力が決め手となる。 + +ドキュメンテーションの作成 +========================== + +1) グローバルなカーネル API が :ref:`kernel-doc <kernel_doc>` の形式で + ドキュメント化されている (静的関数には求められないが、付けてもよい)。 + +2) 新規 ``/proc`` エントリーが、すべて ``Documentation/`` 以下に記載されて + いる。 + +3) 新規カーネル・ブート・パラメータが、すべて + ``Documentation/admin-guide/kernel-parameters.rst`` に記載されている。 + +4) 新規モジュール・パラメータが、すべて ``MODULE_PARM_DESC()`` によって記述 + されている。 + +5) 新規ユーザースペース・インターフェースが、すべて ``Documentaion/ABI/`` + 以下に記載されている。詳しくは、 Documentation/admin-guide/abi.rst + (もしくは ``Documentation/ABI/README``) を参照。 + ユーザースペース・インターフェースを変更するパッチは、 + linux-api@vger.kernel.org にも CC すべし。 + +6) なんらかの ioctl を追加するパッチは、 + ``Documentation/userspace-api/ioctl/ioctl-number.rst`` + の更新を伴う。 + +ツールによるコードのチェック +============================ + +1) スタイル・チェッカー (``scripts/checkpatch.pl``) によって、犯しがちな + パッチ・スタイルの違反がないことを確認済み。 + 指摘される違反を残す場合は、それを正当化できること。 + +2) sparse により入念にチェック済み。 + +3) ``make checkstack`` で指摘される問題があれば、それが修正済み。 + ``checkstack`` は問題点を明示的には指摘しないが、 スタック消費が + 512 バイトを越える関数は見直しの候補。 + +コードのビルド +============== + +1) 以下の条件でクリーンにビルドできる。 + + a) 適用可能な、および ``=y``, ``=m``, ``=n`` を変更した ``CONFIG`` + オプションでのビルド。 + ``gcc`` およびリンカーからの警告・エラーがないこと。 + + b) ``allnoconfig`` と ``allmodconfig`` がパス + + c) ``O=builddir`` を指定してのビルド + + d) Documentation/ 以下の変更に関して、ドキュメントのビルドで新たな警告や + エラーが出ない。 + ``make htmldocs`` または ``make pdfdocs`` でビルドし、問題があれば修正。 + +2) ローカルのクロス・コンパイル・ツール、その他のビルド環境 (訳註: build farm) + を使って、複数の CPU アーキテクチャ向けにビルドできる。 + 特に、ワードサイズ (32 ビットと 64 ビット) やエンディアン (ビッグとリトル) + の異なるアーキテクチャを対象とするテストは、表現可能数値範囲・データ整列・ + エンディアンなどについての誤った仮定に起因する様々な移植上の問題を捕える + のに効果的。 + +3) 新規に追加されたコードについて (``make KCFLAGS=-W`` を使って) + ``gcc -W`` でコンパイル。 + これは多くのノイズを伴うが、 + ``warning: comparison between signed and unsigned`` + の類いのバグをあぶり出すのに効果的。 + +4) 変更されるソースコードが、下記の ``Kconfig`` シンボルに関連するカーネル + API や機能に依存 (もしくは利用) する場合、それらの ``Kconfig`` シンボルが、 + 無効、および (可能なら) ``=m`` の場合を組み合わせた複数のビルドを + (全部まとめてではなく、いろいろなランダムの組み合わせで) テスト済み。 + + ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, + ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, + ``CONFIG_NET``, ``CONFIG_INET=n`` (ただし、後者は ``CONFIG_NET=y`` + との組み合わせ)。 + +コードのテスト +============== + +1) ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, + ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``, + ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``, + ``CONFIG_PROVE_RCU`` および ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` をすべて + 同時に有効にしてのテスト済み。 + +2) ``CONFIG_SMP`` と ``CONFIG_PREEMPT`` が有効と無効の場合について、ビルドと + ランタイムのテスト済み。 + +3) lockdep の機能をすべて有効にしての実行で、すべてのコード経路が確認済み。 + +4) 最低限、slab と ページ・アロケーションの失敗に関する誤り注入 + (訳註: fault injection) によるチェック済み。 + 詳しくは、 Documentation/fault-injection/index.rst を参照。 + 新規のコードが多い場合は、サブシステム対象の誤り注入を追加するのが望ましい + 可能性あり。 + +5) linux-next の最新タグに対するテストにより、他でキューイングされている + パッチや、VM、VFS、その他のサブシステム内のすべての変更と組み合わせての + 動作を確認済み。 diff --git a/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst b/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst index 7d4d694967c7..9d444b9c46d3 100644 --- a/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst +++ b/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst @@ -287,7 +287,7 @@ revelada involucrada. La lista de embajadores actuales: Google Kees Cook <keescook@chromium.org> - LLVM Nick Desaulniers <ndesaulniers@google.com> + LLVM Nick Desaulniers <nick.desaulniers+lkml@gmail.com> ============= ======================================================== Si quiere que su organización se añada a la lista de embajadores, por diff --git a/Documentation/translations/sp_SP/process/submit-checklist.rst b/Documentation/translations/sp_SP/process/submit-checklist.rst index 0d6651f9d871..e7107cc97001 100644 --- a/Documentation/translations/sp_SP/process/submit-checklist.rst +++ b/Documentation/translations/sp_SP/process/submit-checklist.rst @@ -97,9 +97,10 @@ y en otros lugares con respecto al envío de parches del kernel de Linux. ``MODULE_PARM_DESC()``. 18) Todas las nuevas interfaces de espacio de usuario están documentadas - en ``Documentation/ABI/``. Consulte ``Documentation/ABI/README`` para - obtener más información. Los parches que cambian las interfaces del - espacio de usuario deben ser CCed a linux-api@vger.kernel.org. + en ``Documentation/ABI/``. Consulte Documentation/admin-guide/abi.rst + (o ``Documentation/ABI/README``) para obtener más información. + Los parches que cambian las interfaces del espacio de usuario deben + ser CCed a linux-api@vger.kernel.org. 19) Se ha comprobado con la inyección de al menos errores de asignación de slab y página. Consulte ``Documentation/fault-injection/``. diff --git a/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst index dc728c739e28..b35d24464be9 100644 --- a/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst +++ b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst @@ -112,7 +112,7 @@ CFS usa una granularidad de nanosegundos y no depende de ningún jiffy o detalles como HZ. De este modo, el gestor de tareas CFS no tiene noción de "ventanas de tiempo" de la forma en que tenía el gestor de tareas previo, y tampoco tiene heurísticos. Únicamente hay un parámetro -central ajustable (se ha de cambiar en CONFIG_SCHED_DEBUG): +central ajustable: /sys/kernel/debug/sched/base_slice_ns diff --git a/Documentation/translations/zh_CN/admin-guide/README.rst b/Documentation/translations/zh_CN/admin-guide/README.rst index e679cbc3c89d..1bdafdc4c8e2 100644 --- a/Documentation/translations/zh_CN/admin-guide/README.rst +++ b/Documentation/translations/zh_CN/admin-guide/README.rst @@ -146,7 +146,7 @@ Linux内核6.x版本 <http://kernel.org/> "make xconfig" 基于Qt的配置工具。 - "make gconfig" 基于GTK+的配置工具。 + "make gconfig" 基于GTK的配置工具。 "make oldconfig" 基于现有的 ./.config 文件选择所有选项，并询问 新配置选项。 diff --git a/Documentation/translations/zh_CN/dev-tools/ubsan.rst b/Documentation/translations/zh_CN/dev-tools/ubsan.rst index 2487696b3772..81ef6f77caeb 100644 --- a/Documentation/translations/zh_CN/dev-tools/ubsan.rst +++ b/Documentation/translations/zh_CN/dev-tools/ubsan.rst @@ -3,7 +3,14 @@ .. include:: ../disclaimer-zh_CN.rst :Original: Documentation/dev-tools/ubsan.rst -:Translator: Dongliang Mu <dzm91@hust.edu.cn> + +:翻译: + + 慕冬亮 Dongliang Mu <dzm91@hust.edu.cn> + +:校译: + + 王昱力 WangYuli <wangyuli@uniontech.com> 未定义行为消毒剂 - UBSAN ==================================== @@ -55,30 +62,20 @@ GCC自4.9.x [1_] （详见 ``-fsanitize=undefined`` 选项及其子选项）版� 使用如下内核配置启用UBSAN:: - CONFIG_UBSAN=y - -使用如下内核配置检查整个内核:: - - CONFIG_UBSAN_SANITIZE_ALL=y - -为了在特定文件或目录启动代码插桩，需要在相应的内核Makefile中添加一行类似内容: + CONFIG_UBSAN=y -- 单文件（如main.o）:: - - UBSAN_SANITIZE_main.o := y - -- 一个目录中的所有文件:: - - UBSAN_SANITIZE := y - -即使设置了``CONFIG_UBSAN_SANITIZE_ALL=y``，为了避免文件被插桩，可使用:: +排除要被检测的文件:: UBSAN_SANITIZE_main.o := n -与:: +排除一个目录中的所有文件:: UBSAN_SANITIZE := n +当全部文件都被禁用，可通过如下方式为特定文件启用:: + + UBSAN_SANITIZE_main.o := y + 未对齐的内存访问检测可通过开启独立选项 - CONFIG_UBSAN_ALIGNMENT 检测。 该选项在支持未对齐访问的架构上(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y) 默认为关闭。该选项仍可通过内核配置启用，但它将产生大量的UBSAN报告。 diff --git a/Documentation/translations/zh_CN/disclaimer-zh_CN.rst b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst index 3c6db094a63c..37681c0b2a01 100644 --- a/Documentation/translations/zh_CN/disclaimer-zh_CN.rst +++ b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst @@ -1,9 +1,7 @@ :orphan: -.. warning:: +.. note:: 此文件的目的是为让中文读者更容易阅读和理解，而不是作为一个分支。 因此， 如果您对此文件有任何意见或更新，请先尝试更新原始英文文件。 - -.. note:: - 如果您发现本文档与原始文件有任何不同或者有翻译问题，请联系该文件的译者， - 或者请求时奎亮的帮助：<alexs@kernel.org>。 + 如果您发现本文档与原始文件有任何不同或者有翻译问题，请发建议或者补丁给 + 该文件的译者，或者请求中文文档维护者和审阅者的帮助。 diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 7574e1673180..cc512ca54172 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -26,7 +26,13 @@ 顺便说下，中文文档也需要遵守内核编码风格，风格中中文和英文的主要不同就是中文 的字符标点占用两个英文字符宽度，所以，当英文要求不要超过每行100个字符时， 中文就不要超过50个字符。另外，也要注意'-'，'='等符号与相关标题的对齐。在将 -补丁提交到社区之前，一定要进行必要的 ``checkpatch.pl`` 检查和编译测试。 +补丁提交到社区之前，一定要进行必要的 ``checkpatch.pl`` 检查和编译测试，确保 +在 ``make htmldocs/pdfdocs`` 中不增加新的告警，最后，安装检查你生成的 +html/pdf 文件，确认它们看起来是正常的。 + +提交之前请确认你的补丁可以正常提交到中文文档维护库: +https://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git/ +如果你的补丁依赖于其他人的补丁, 可以与其他人商量后由某一个人合并提交。 与Linux 内核社区一起工作 ------------------------ diff --git a/Documentation/translations/zh_CN/mm/balance.rst b/Documentation/translations/zh_CN/mm/balance.rst index 6fd79209c307..f877c0cfa39a 100644 --- a/Documentation/translations/zh_CN/mm/balance.rst +++ b/Documentation/translations/zh_CN/mm/balance.rst @@ -64,7 +64,7 @@ kswapd并不真正需要平衡高内存区，因为中断上下文并不请求� 如果从进程内存和shm中偷取页面可以减轻该页面节点中任何区的内存压力，而该区的内存压力 已经低于其水位，则会进行偷取。 -watemark[WMARK_MIN/WMARK_LOW/WMARK_HIGH]/low_on_memory/zone_wake_kswapd： +watermark[WMARK_MIN/WMARK_LOW/WMARK_HIGH]/low_on_memory/zone_wake_kswapd： 这些是每个区的字段，用于确定一个区何时需要平衡。当页面数低于水位[WMARK_MIN]时， hysteric 的字段low_on_memory被设置。这个字段会一直被设置，直到空闲页数变成水位 [WMARK_HIGH]。当low_on_memory被设置时，页面分配请求将尝试释放该区域的一些页面（如果 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/translations/zh_CN/process/submit-checklist.rst b/Documentation/translations/zh_CN/process/submit-checklist.rst index 10536b74aeec..0e524f1c1af5 100644 --- a/Documentation/translations/zh_CN/process/submit-checklist.rst +++ b/Documentation/translations/zh_CN/process/submit-checklist.rst @@ -82,8 +82,8 @@ Linux内核补丁提交检查单 17) 所有新的模块参数都记录在 ``MODULE_PARM_DESC()`` 18) 所有新的用户空间接口都记录在 ``Documentation/ABI/`` 中。有关详细信息， - 请参阅 ``Documentation/ABI/README`` 。更改用户空间接口的补丁应该抄送 - linux-api@vger.kernel.org。 + 请参阅 Documentation/admin-guide/abi.rst (或 ``Documentation/ABI/README``)。 + 更改用户空间接口的补丁应该抄送 linux-api@vger.kernel.org\ 。 19) 已通过至少注入slab和page分配失败进行检查。请参阅 ``Documentation/fault-injection/`` 。 如果新代码是实质性的，那么添加子系统特定的故障注入可能是合适的。 diff --git a/Documentation/translations/zh_CN/security/credentials.rst b/Documentation/translations/zh_CN/security/credentials.rst new file mode 100644 index 000000000000..91c353dfb622 --- /dev/null +++ b/Documentation/translations/zh_CN/security/credentials.rst @@ -0,0 +1,479 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/security/credentials.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +============= +Linux中的凭据 +============= + +作者: David Howells <dhowells@redhat.com> + +.. contents:: :local: + +概述 +==== + +当一个对象对另一个对象进行操作时，Linux执行的安全检查包含几个部分： + + 1. 对象 + + 对象是可以直接由用户空间程序操作的系统中的实体。Linux具有多种可操作 + 的对象，包括： + + - 任务 + - 文件/索引节点 + - 套接字 + - 消息队列 + - 共享内存段 + - 信号量 + - 密钥 + + 所有这些对象的描述的一部分是一组凭据。集合中的内容取决于对象的类型。 + + 2. 对象所有权 + + 大多数对象的凭据中会有一个子集用来表示该对象的所有权。 + 这用于资源核算和限制（如磁盘配额和任务资源限制）。 + + 例如，在标准的UNIX文件系统中，这将由标记在索引节点上的UID定义。 + + 3. 对象上下文 + + 此外在这些对象的凭据中，将有一个子集表示对象的“对象上下文”。 + 这可能与（2）中相同，也可能不同 —— 例如，在标准的UNIX文件中， + 这是由标记在索引节点上的UID和GID定义的。 + + 对象上下文是进行安全计算的一部分，当对象被操作时会用到。 + + 4. 主体 + + 主体是正在对其他对象执行操作的对象。 + + 系统中的大多数对象是不活动的：他们不会对系统中的其他对象起作用。 + 进程/任务是明显的例外：它们可以访问和操纵其他对象。 + + 任务之外的其他对象在某些情况下也可以是主体。例如，打开的文件可以使用 + 名为 ``fcntl(F_SETOWN)`` 的任务给它的UID和EUID向一个任务发送SIGIO + 信号。在这种情况下，文件结构也会有一个主体上下文。 + + 5. 主体上下文 + + 主体对其凭据有一个额外的解释。其凭据的一个子集形成了“主体上下文”。主体 + 上下文在主体执行操作时作为安全计算的一部分使用。 + + 例如，Linux任务在操作文件时会有FSUID、FSGID和附加组列表 —— 这些凭据 + 与通常构成任务的对象上下文的真实UID和GID是相互独立的。 + + 6. 操作 + + Linux提供许多操作，主体可以对对象执行这些操作。可用的操作集取决于主体 + 和对象的性质。 + + + 操作包括读取、写入、创建和删除文件，以及派生（forking）或发送 + 信号（signalling）和跟踪（tracing）任务等。 + + 7. 规则，访问控制列表和安全计算 + + 当主体对对象进行操作时，会进行安全计算。这涉及到使用主体上下文、对象 + 上下文和操作，并搜索一个或多个规则集，以确定在给定这些上下文的情况下， + 主体是否被授予或拒绝以所需方式对对象进行操作的权限。 + + 主要有两个规则来源： + + a. 自主访问控制（DAC）： + + 有时，对象的描述中会包含一组规则。这就是所谓的“访问控制列表”或‘ACL’。 + 一个Linux文件可以提供多个ACL。 + + 例如，传统的UNIX文件包括一个权限掩码，它是一个简化的ACL，具有三个固定的 + 主体类别（“用户”、“组”和“其他”），每一个都可以被授予一定的特权（如“读取”、 + “写入”和“执行” —— 无论这些映射对于对象意味着什么）。然而，UNIX文件权限不 + 允许任意指定主体，因此用途有限。 + + Linux文件还可以支持POSIX ACL。这是一个规则列表，为任意主体授予各种权限。 + + b. 强制访问控制（MAC）： + + 整个系统可能有一个或多个规则集，适用于所有主体和对象，不考虑它们的来源。 + SELinux和Smack就是这种情况的例子。 + + 在SELinux和Smack的情况下，每个对象在其凭据中都被赋予一个标签。当请求执 + 行操作时，它们使用主体标签、对象标签和操作，寻找一个规则，该规则表示此操 + 作是授予还是拒绝的。 + + +凭据类型 +======== + +Linux内核支持以下类型的凭据： + + 1. 传统的UNIX凭据。 + + - 真实用户ID + - 真实组ID + + UID和GID由大多数（如果不是全部）Linux对象携带，即使有时它们需要被虚构出 + 来（例如FAT或CIFS文件，这些文件来源于Windows）。这些（通常）定义了该对象 + 的对象上下文，但任务在某些情况下略有不同。 + + - 有效用户ID，保存用户ID和FS用户ID + - 有效组ID，保存组ID和FS组ID + - 补充组 + + 这些是仅由任务使用的额外凭据。通常，一个EUID/EGID/GROUPS 被用作主体上下文， + 而真实UID/GID 被用作对象上下文。对于任务，这并不总是正确的。 + + 2. 能力 + + - 允许的能力集合 + - 可继承的能力集合 + - 有效的能力集合 + - 能力边界集合 + + 这些仅由任务携带，表示授予任务的超出普通任务权限的能力。这些可以通过传统 + UNIX凭据的更改进行隐式操作，但也可以通过 ``capset()`` 系统调用直接操作。 + + 允许的能力是指进程可以通过 ``capset()`` 将其添加到其有效或允许集合中的 + 那些能力。这个可继承的集合也可能受到这样的限制。 + + 有效能力是任务本身实际可以使用的能力。 + + 可继承能力是那些可以通过 ``execve()`` 传递的能力。 + + 边界集限制了通过 ``execve()`` 继承的能力，特别是在以UID 0执行二进制文件时。 + + 3. 安全管理标记（securebits） + + 它们用于控制上述凭据在特定操作如execve()中的操作和继承方式。它们并不直接 + 用作对象或主体凭据使用。 + + 4. 密钥和密钥环 + + 这些仅由任务携带。它们用于携带和缓存不适合放入其他标准UNIX凭据中的安全令牌。 + 它们用诸如使网络文件系统密钥在进程执行的文件访问时可用，而无需让普通程序了解 + 涉及的安全细节。 + + 密钥环是一种特殊类型的密钥。它们携带一组其他密钥，并可以搜索来查找所需的密钥。 + 每个进程可以订阅多个密钥环： + + 每线程密钥 + 每进程密钥环 + 每会话密钥环 + + 当进程访问一个密钥时，若尚不存在，则通常会将其缓存在一个密钥环中，以便将来的 + 访问时找到该密钥。 + + 有关密钥的更多信息，请参见 ``Documentation/translations/zh_CN/security/keys/*`` 。 + + 5. LSM + + Linux安全模块允许在任务执行操作时施加额外的控制。目前，Linux支持几种LSM选项。 + + 一些工作通过标记系统中的对象，并应用一组规则（策略）说明某个标签的任务可以对 + 另一标签的对象执行哪些操作。 + + 6. AF_KEY + + 这是一种基于套接字网络协议栈中的凭据管理[RFC 2367]。本文档中没有讨论它,因为不 + 直接与任务和文件凭据进行交互，而是保留了系统级的凭据。 + + +当打开一个文件时，打开任务的主体上下文的一部分会记录在创建的文件结构中。 +这使得使用该文件结构的操作可以使用这些凭据，而不是发出操作的任务的主体上下文。 +一个例子是在网络文件系统上打开的文件，打开文件的凭据应该被呈现给服务器，而不管 +实际进行读取或写入操作的是谁。 + + +文件标记 +======== + +存储在磁盘上或通过网络获取的文件可能具有注释，构成该文件的对象安全上下文。 +根据文件系统的类型，这些注释可能包括以下一项或多项： + + * UNIX UID, GID, mode; + * Windows user ID; + * Access control list; + * LSM security label; + * UNIX exec privilege escalation bits (SUID/SGID); + * File capabilities exec privilege escalation bits. + +将这些与任务的主体安全上下文进行比较，并根据比较结果允许或禁止执行某些操作。 +在execve()的情况下，特权提升位起作用，并且可能允许由可执行文件的注释决定的 +进程获得额外的特权。 + + +任务凭据 +======== + +在Linux中，一个任务的所有凭据都保存在一个引用计数结构体‘struct cred’中， +通过(uid, gid)或(groups, keys, LSM security)进行访问。每个任务在其 +task_struct中通过一个名为‘cred’的指针指向其凭据。 + +一旦一组凭据已经准备好并提交，除非以下几种情况，否则不能更改： + + 1. 其引用计数可以更改； + + 2. 它所指向的 group_info 结构体的引用计数可以更改； + + 3. 它所指向的安全数据的引用计数可以更改； + + 4. 它所指向的任何密钥环的引用计数可以更改； + + 5. 它所指向的任何密钥环可以被撤销、过期或其安全属性可以更改； + + 6. 它所指向的任何密钥环的内容可以更改（密钥环的整个目的就是作为一组共享凭据， + 可由具有适当访问权限的任何人修改）。 + +要更改cred结构体中的任何内容，必须遵循复制和替换的原则。首先进行复制，然后修 +改副本，最后使用RCU（读-复制-更新）将任务指针更改为指向新的副本。有一些封装可 +用于帮助执行这个过程（见下文）。 + +一个任务只能修改自己的凭据；不再允许一个任务修改另一个任务的凭据。 +这意味着 ``capset()`` 系统调用不再允许使用除当前进程之外的任何PID。 +此外， ``keyctl_instantiate()`` 和 ``keyctl_negate()`` 函数也不再 +允许在请求进程中附加到特定于进程的密钥环，因为实例化进程可能需要创建它们。 + + +不可变凭据 +---------- + +一旦一组凭据已经被公开（例如通过调用 ``commit_creds()`` ），必须将其视为 +不可变的,除了两个例外情况： + + 1. 引用计数可以被修改。 + + 2. 虽然无法更改一组凭据的密钥环订阅，但订阅的密钥环的内容可以被更改。 + +为了在编译时捕获意外的凭据修改，struct task_struct具有_const_指针指向其凭据集， +struct file也是如此。此外，某些函数如 ``get_cred()`` 和 ``put_cred()`` 在 +const指针上操作，因此不需要进行类型转换，但需要临时放弃const限定，以便能够修改 +引用计数。 + + +访问任务凭据 +------------ + +任务只能修改自己的凭据，允许当前进程可以读取或替换自己的凭据，无需任何形式锁定的 +情况下 —— 这极大简化了事情。它可以调用:: + + const struct cred *current_cred() + +获取指向其凭据结构的指针，并且之后不必释放它。 + +有一些方便的封装用于检索任务凭据的特定方面（在每种情况下都只返回值）:: + + uid_t current_uid(void) Current's real UID + gid_t current_gid(void) Current's real GID + uid_t current_euid(void) Current's effective UID + gid_t current_egid(void) Current's effective GID + uid_t current_fsuid(void) Current's file access UID + gid_t current_fsgid(void) Current's file access GID + kernel_cap_t current_cap(void) Current's effective capabilities + struct user_struct *current_user(void) Current's user account + +还有一些方便的封装，用于检索任务凭据的特定关联对:: + + void current_uid_gid(uid_t *, gid_t *); + void current_euid_egid(uid_t *, gid_t *); + void current_fsuid_fsgid(uid_t *, gid_t *); + +在从当前任务的凭据中检索后，通过其参数返回这些值对。 + + +此外，还有一个函数用于获取当前进程的当前凭据集的引用:: + + const struct cred *get_current_cred(void); + +以及用于获取对一个实际上不存在于struct cred中的凭据的引用的函数:: + + struct user_struct *get_current_user(void); + struct group_info *get_current_groups(void); + +分别获得对当前进程的 user accounting structure 和补充组列表的引用。 + +一旦获得引用，就必须使用 ``put_cred（）``, ``free_uid（）`` 或 +``put_group_info（）`` 来适当释放它。 + + +访问其他任务的凭据 +------------------ + +虽然一个任务可以在不需要锁定的情况下访问自己的凭据，但想要访问另一个任务 +的凭据的任务并非如此。它必须使用RCU读锁和 ``rcu_dereference（）``。 + +``rcu_dereference()`` 是由:: + + const struct cred *__task_cred(struct task_struct *task); + +这应该在RCU读锁中使用，如下例所示:: + + void foo(struct task_struct *t, struct foo_data *f) + { + const struct cred *tcred; + ... + rcu_read_lock(); + tcred = __task_cred(t); + f->uid = tcred->uid; + f->gid = tcred->gid; + f->groups = get_group_info(tcred->groups); + rcu_read_unlock(); + ... + } + +如果需要长时间持有另一个任务的凭据，并且可能在此过程中休眠，则调用方 +应该使用以下函数来获取对这些凭据的引用:: + + const struct cred *get_task_cred(struct task_struct *task); + +这个函数内部完成了所有的RCU操作。当使用完这些凭据时，调用方必须调用put_cred() +函数释放它们。 + +.. note:: + ``__task_cred()`` 的结果不应直接传递给 ``get_cred()`` ， + 因为这可能与 ``commit_cred()`` 发生竞争条件。 + +还有一些方便的函数可以访问另一个任务凭据的特定部分，将RCU操作对调用方隐藏起来:: + + uid_t task_uid(task) Task's real UID + uid_t task_euid(task) Task's effective UID + +如果调用方在此时已经持有RCU读锁，则应使用:: + + __task_cred(task)->uid + __task_cred(task)->euid + +类似地，如果需要访问任务凭据的多个方面，应使用RCU读锁，调用 ``__task_cred()`` +函数，将结果存储在临时指针中，然后从临时指针中调用凭据的各个方面，最后释放锁。 +这样可以防止多次调用昂贵的RCU操作。 + +如果需要访问另一个任务凭据的其他单个方面，可以使用:: + + task_cred_xxx(task, member) + +这里的‘member’是cred结构体的非指针成员。例如:: + + uid_t task_cred_xxx(task, suid); + +将从任务中检索‘struct cred::suid’，并执行适当的RCU操作。对于指针成员， +不能使用这种形式，因为它们指向的内容可能在释放RCU读锁的瞬间消失。 + + +修改凭据 +-------- + +如先前提到的，一个任务只能修改自己的凭据，不能修改其他任务的凭据。这意味 +着它不需要使用任何锁来修改自己的凭据。 + +要修改当前进程的凭据，函数应首先调用:: + + struct cred *prepare_creds(void); + +这将锁定current->cred_replace_mutex，然后分配并构建当前进程凭据的副本。 +如果成功，函数返回时仍然保持互斥锁。如果不成功（内存不足），则返回NULL。 + +互斥锁防止 ``ptrace()`` 在进行凭据构建和更改的安全检查时更改进程的ptrace +状态，因为ptrace状态可能会改变结果，特别是在 ``execve()`` 的情况下。 + +新的凭据集应适当地进行修改，并进行任何安全检查和挂钩。在此时，当前和建议的 +凭据集都可用，因为current_cred()将返回当前的凭据集。 + +在替换组列表时，必须在将其添加到凭据之前对新列表进行排序，因为使用二分查找 +测试成员资格。实际上，这意味着在set_groups()或set_current_groups()之 +前应调用groups_sort()。groups_sort()不能在共享的 ``struct group_list`` +上调用，因为即使数组已经排序，它也可能作为排序过程的一部分对元素进行排列。 + +当凭据集准备好时，应通过调用以下函数将其提交给当前进程:: + + int commit_creds(struct cred *new); + +这将修改凭据和进程的各个方面，给LSM提供机会做同样的修改，然后使用 +``rcu_assign_pointer()`` 将新的凭据实际提交给 ``current->cred`` ， +释放 ``current->cred_replace_mutex`` 以允许 ``ptrace()`` 进行操 +作，并通知调度程序和其他组件有关更改的情况。 + +该函数保证返回0，以便可以在诸如 ``sys_setresuid()`` 函数的末尾进行尾调用。 + +请注意，该函数会消耗调用者对新凭据的引用。调用者在此之后不应调用 +``put_cred()`` 释放新凭据。 + +此外，一旦新的凭据上调用了该函数，就不能进一步更改这些凭据。 + + +如果在调用 ``prepare_creds()`` 之后安全检查失败或发生其他错误， +则应调用以下函数:: + + void abort_creds(struct cred *new); + +这将释放 ``prepare_creds()`` 获取的 ``current->cred_replace_mutex`` 的锁， +并释放新的凭据。 + +一个典型的凭据修改函数看起来像这样:: + + int alter_suid(uid_t suid) + { + struct cred *new; + int ret; + + new = prepare_creds(); + if (!new) + return -ENOMEM; + + new->suid = suid; + ret = security_alter_suid(new); + if (ret < 0) { + abort_creds(new); + return ret; + } + + return commit_creds(new); + } + + +管理凭据 +-------- + +有一些函数用来辅助凭据管理: + + - ``void put_cred(const struct cred *cred);`` + + 这将释放对给定凭据集的引用。如果引用计数为零，凭据集将由 + RCU系统安排进行销毁。 + + - ``const struct cred *get_cred(const struct cred *cred);`` + + 这将获取对活动凭据集的引用。返回指向凭据集的指针。 + + - ``struct cred *get_new_cred(struct cred *cred);`` + + 这将获取对当前正在构建且可变的凭据集的引用。返回指向凭据集的指针。 + +打开文件凭据 +============ + +当打开新文件时，会获取对打开任务凭据的引用，并将其附加到文件结构体的 +``f_cred`` 字段中，替代原来的 ``f_uid`` 和 ``f_gid`` 。原来访问 +``file->f_uid`` 和 ``file->f_gid`` 的代码现在应访问 ``file->f_cred->fsuid`` +和 ``file->f_cred->fsgid`` 。 + +安全访问 ``f_cred`` 的情况下可以不使用RCU或加锁，因为指向凭据的指针 +以及指向的凭据结构的内容在文件结构的整个生命周期中保持不变，除非是 +上述列出的例外情况（参阅任务凭据部分）。 + +为了避免“混淆代理”权限提升攻击，在打开的文件后续操作时，访问控制检查 +应该使用这些凭据，而不是使用“当前”的凭据，因为该文件可能已经被传递给 +一个更具特权的进程。 + +覆盖VFS对凭据的使用 +=================== + +在某些情况下，需要覆盖VFS使用的凭据，可以通过使用不同的凭据集调用 +如 ``vfs_mkdir()`` 来实现。以下是一些进行此操作的位置: + + * ``sys_faccessat()``. + * ``do_coredump()``. + * nfs4recover.c. diff --git a/Documentation/translations/zh_CN/security/index.rst b/Documentation/translations/zh_CN/security/index.rst index d8aacd1930d9..78d9d4b36dca 100644 --- a/Documentation/translations/zh_CN/security/index.rst +++ b/Documentation/translations/zh_CN/security/index.rst @@ -15,20 +15,20 @@ .. toctree:: :maxdepth: 1 + credentials + snp-tdx-threat-model lsm sak + self-protection siphash + tpm/index digsig landlock TODOLIST: -* credentials -* snp-tdx-threat-model * IMA-templates * keys/index * lsm-development * SCTP -* self-protection -* tpm/index * secrets/index * ipe diff --git a/Documentation/translations/zh_CN/security/keys/index.rst b/Documentation/translations/zh_CN/security/keys/index.rst new file mode 100644 index 000000000000..7c28d003fb0a --- /dev/null +++ b/Documentation/translations/zh_CN/security/keys/index.rst @@ -0,0 +1,22 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/keys/index.rst + +:翻译: + + +======== +内核密钥 +======== + +.. toctree:: + :maxdepth: 1 + + +TODOLIST: +* core +* ecryptfs +* request-key +* trusted-encrypted diff --git a/Documentation/translations/zh_CN/security/secrets/index.rst b/Documentation/translations/zh_CN/security/secrets/index.rst new file mode 100644 index 000000000000..5ea78713f10e --- /dev/null +++ b/Documentation/translations/zh_CN/security/secrets/index.rst @@ -0,0 +1,17 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/secrets/index.rst + +:翻译: + +===================== +密钥文档 +===================== + +.. toctree:: + + +TODOLIST: + +* coco diff --git a/Documentation/translations/zh_CN/security/self-protection.rst b/Documentation/translations/zh_CN/security/self-protection.rst new file mode 100644 index 000000000000..3c8a68b1e1be --- /dev/null +++ b/Documentation/translations/zh_CN/security/self-protection.rst @@ -0,0 +1,271 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst +:Original: Documentation/security/self-protection.rst + +:翻译: + + 张巍 zhangwei <zhangwei@cqsoftware.com.cn> + +============ +内核自我保护 +============ + +内核自我保护是指在Linux内核中设计与实现的各种系统与结构 +以防止内核本身的安全漏洞问题。它涵盖了广泛问题，包括去除 +整个类的漏洞，阻止安全漏洞利用方法，以及主动检测攻击尝 +试。并非所有的话题都在本文中涉及，但它应该为了解内核自我 +保护提供一个合理的起点，并解答常见的问题。（当然，欢迎提 +交补丁！） + +在最坏的情况下，我们假设一个非特权的本地攻击者对内核内存 +有任意读写访问权限。虽然在许多情况下，漏洞被利用时并不会 +提供此级别的访问权限，但如果我们能防御最坏情况，也能应对 +权限较低的攻击。一个更高的标准，且需要牢记的是保护内核免 +受具有特权的本地攻击者的攻击，因为root用户可以有更多权限。 +（尤其是当他们能够加载任意内核模块时） + +成功的自我保护的目标是：有效、默认开启、不需要开发者主动 +选择、没有性能影响、不妨碍内核调试、并且没有测试。虽然很 +难满足所有的这些目标，但明确提到这些目标非常重要，因为这 +些方面需要被探索、解决或接受。 + +========== +攻击面缩减 +========== + +防止安全漏洞最基本的防御方式是减少可以被用来重定向执行的 +内核区域。这包括限制用户公开使用的API、使内核API更难被错 +误使用、最小化可写内核内存区域等。 + +严格的内核内存权限 +------------------- + +当所有内核内存都是可写的，攻击者可以轻松地重定向执行流。 +为了减少这种攻击目标的可用性，内核需要更严格的权限集来 +保护其内存。 + +可执行代码和只读数据必须不可写 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +任何具有可执行内存的区域必须不可写，显然这也包括内核文本 +本身。我们还必须考虑其他地方：内核模块、JIT内存等，（在 +某些情况下，为了支持像指令替代、断点、kprobes等功能，这些 +区域会暂时被设置为可写。如果这些功能必须存在于内核中，它 +们的实现方式是：在更新期间将内存临时设置可写，然后再恢复 +为原始权限。） + +为了支持这一点，CONFIG_STRICT_KERNEL_RWX 和 +CONFIG_STRICT_MODULE_RWX 的设计旨在确保代码不可写，数据不 +可执行，以及只读数据既不可写也不可执行。 + +大多数架构默认支持这些选项，且用户无法选择。对于一些像arm +这种希望能够选择这些选项的架构，可以在架构Kconfig中选择 +ARCH_OPTIONAL_KERNEL_RWX以启用Kconfig提示。 +CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT决定在启用 +ARCH_OPTIONAL_KERNEL_RWX时的默认设置。 + +函数指针和敏感变量必须不可写 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +内核内存中有大量的函数指针，这些指针被内核查找并用于继续执行 +（例如，描述符/向量表、文件/网络等操作结构等）。这些变量的数 +量必须减少到最低限度 + +许多像这样的变量可以通过设置为"const"来实现只读，从而使它们 +存放在内核的.rodata段而非.data段，从而获得内核严格内存权限的 +保护。 + +对于在_init是仅初始化一次的变量，可以使用_ro_after_init属性 +进行标记。 + +剩下的变量通常是那些更新频率较低的（例如GDT）。这些变量需要另 +一个机制（类似于上述提到的对内核代码所做的临时例外），以便在 +其余生命周期内保持只读状态。（例如，在进行更新时，只有执行 +更新的CPU线程会被授予对内存的不可中断写入访问权限。） + +将内核内存与用户空间内存分隔开 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +内核绝对不可以执行用户空间内存，同时，内核也不得在没有明确预 +期的情况下访问用户内存空间。这些规则可以通过一些硬件限制来支 +持（如x86的SMEP/SMAP，ARM的PXN/PAN）或通过仿真（如ARM的内存 +域）来强制执行。通过这种方式阻止用户空间内存的访问，攻击者就 +无法将执行和数据解析转移到易于控制的用户空间内存，从而迫使攻 +击完全在内核中进行。 + +减少对系统调用的访问 +-------------------- + +对于64位系统，一种消除许多系统调用最简单的方法是构建时不启用 +CONFIG_CONPAT。然而，这种情况通常不可行。 + +“seccomp”系统为用户空间提供了一种可选功能，提供了一种减少可供 +运行中进程使用内核入口点数量的方法。这限制了可以访问内核代码 +的范围，可能降低了某个特定漏洞被攻击者利用的可能性。 + +一个改进的方向是创建有效的方法，仅允许受信任的进程访问例如兼 +容模式、用户命名空间、BPF创建和性能分析等功能。这将把内核入口 +点范围限制在通常可以被非特权用户空间进程访问的较常见集合中 + +限制对内核模块的访问 +-------------------- + +内核绝不应允许非特权用户加载特定的内核模块，因为这可能为攻击者 +提供一个意外扩展的可用攻击面的方法。（通过已预定义子系统按需加 +载模块，如MODULE_ALIAS_*，被认为是“预期的”，但即便如此，也应对 +这些情况给予更多的关注。）例如，通过非特权的套接字API加载文件 +系统模块是没有意义的：只有root用户或物理本地用户应该触发文件系 +统模块的加载。（在某些情况下，这甚至可能存在争议。） + +为了防止特权用户的攻击，系统可能需要完全禁止模块加载（例如，通 +过单体内核构建或modules_disabled sysctl），或者使用签名模块（例 +如，CONFIG_MODULE_SIG_FORCE或通过LoadPin保护的dm-crypt），以防 +止root用户通过模块加载器加载任意内核代码。 + +内存完整性 +---------- + +内核中有许多内存结构在攻击过程中被定期泛滥用以获取执行控制，迄今 +为止，最常见的是堆栈缓冲区溢出，在这种攻击中，堆栈上存储的返回地 +址被覆盖。除此之外，还有许多其他类型的攻击，防护措施也应运而生。 + +堆栈缓冲区溢出 +-------------- + +经典的堆栈缓冲区溢出攻击是指超出栈上分配的变量预期大小，从而将一 +个受控值写入栈帧的返回地址。最常见的防御措施是堆栈保护 +（CONFIG_STACKPROTECTOR），它在函数返回前会验证栈上的“stack canary”。 +其他防御措施还包括影子堆栈等。 + +堆栈深度溢出 +------------ + +一个不太容易被理解的攻击方式是利用bug触发内核通过深度函数调用或 +大的堆栈分配来消耗堆栈内存。通过这种攻击，攻击者可以将数据写入内 +核预分配堆栈空间之外的敏感结构。为了更好的防护这种攻击，必须进行 +两项重要的更改：将敏感的线程信息结构转移到其他地方，并在堆栈底部 +添加一个故障内存洞，以捕获这些溢出 + +栈内存完整性 +------------ + +用于跟踪堆空闲列表的结构可以在分配和释放时进行完整性检查，以确保它 +们不会被用来操作其它内存区域。 + +计算器完整性 +------------ + +内核中的许多地方使用原子计数器来跟踪对象引用或执行类似的生命周期管 +理。当这些计数器可能发生溢出时（无论是上溢还是下溢），这通常会暴露 +出使用后释放（use-after-free）漏洞。通过捕捉原子计数器溢出，这类漏 +洞就可以消失。 + +大小计算溢出检测 +---------------- + +与计算器溢出类似，整数溢出（通常是大小计算）需要在运行时进行检测， +以防止这类在传统上会导致能够写入内核缓冲区末尾之外的漏洞。 + +概率性防御 +---------- + +尽管许多防御措施可以被认定是确定的（例如，只读内存不能写入），但 +有些确保措施仅提供统计防御，即攻击者必须收集足够的关于运行系统的 +信息才能突破防御。尽管这些防御并不完美，但它们确实提供了有意义的 +保护。 + +栈保护、迷惑技术和其他秘密 +-------------------------- + +值得注意的是，像之前讨论的栈保护这样的技术，从技术上来说是统计性防 +御，因为它们依赖于一个秘密值，而这样的值可能会通过信息泄露漏洞而被 +发现。 + +对于想JIT（及时翻译器）这样的情况，其中可执行内容可能部分由用户空间 +控制，也需要类似的秘密之来迷惑。 + +至关重要的是，所使用的秘密值必须是独立的（例如，每个栈使用不同的栈 +保护值），并且具有高熵（例如，随机数生成器（RNG）是否正常工作？）， +以最大限度地提高其成功率。 + +内核地址空间布局随机化（KASLR） +------------------------------- + +由于内核内存的位置几乎总是攻击成功的关键因素，因此使内核内存位置变 +得非确定性会增加攻击的难度。（请注意，这反过来提高了信息泄露的价 +值，因为泄露的信息可以用来发现目标内存位置。） + +文本和模块基址 +-------------- + +通过在启动时重新设定内核的物理基地址和虚拟基地址 +（CONFIG_RANDOMIZE_BASE）,那些需要利用内核代码的攻击将会受阻。此外 +通过偏移模块加载基地址，意味着即使系统每次启动时按相同顺序加载同一 +组模块，这些模块也不会与内核文本的其余部分公用一个基地址。 + +堆栈基地址 +---------- + +如果进程之间内核堆栈的基地址不相同，甚至在不同系统调用之间也不相同， +那么栈上或超出栈的目标位置就会变得更加难以确定。 + +动态内存基址 +------------ + +很多内核的动态内存（例如kmalloc，vmalloc等）由于早期启动初始化的顺 +序，最终布局是相对确定的。如果这些区域的基地址在启动之间不相同，攻 +击者就无法轻易定位它们，必须依赖于针对该区域的信息泄露才能成功。 + +结构布局 +-------- + +通过在每次构建时对敏感结构的布局进行随机化处理，攻击这必须将攻击调 +节到已知的内核版本，或者泄露足够的内核内存来确定结构布局，然后才能 +对其进行操作。 + +防止信息泄露 +------------ + +由于敏感结构的位置是攻击的主要目标，因此防止内核内存地址和内核内存 +内容泄露非常重要（因为它们可能包含内核地址或者其他敏感数据，例如 +栈保护值）。 + +内核地址 +-------- + +将内核地址打印到用户空间会泄露有关内核内存布局的敏感信息。在使用任 +何打印符号打印原始地址时，目前%px,%p[ad]（和在某些情况下的%p[sSb]） +时。使用这些格式符写入的文件需要限制为只有特权进程可读。 + +在4.14及以前的内核版本中，使用%p格式符打印的是原始地址。从4.15-rcl +版本开始，使用%p格式符打印的地址会在打印前进行哈希处理。 + +[*]如果启用KALLSYMS并且符号查找失败，则打印原始地址；如果没有启用 +KALLSYSM，则会直接打印原始地址。 + +唯一标识符 +---------- + +内核内存地址绝不可能用作向用户空间公开的标识符。相反，应该使用原子 +计数器，IDR（ID映射表）或类似的唯一标识符。 + +内存初始化 +---------- + +复制到用户空间的内存必须始终被完全初始化，如果没有显式地使用memset() +函数进行初始化，那就需要修改编译器，确保清除结构中的空洞。 + +内存清除 +-------- + +在释放内存时，最好对内存内容进行清除处理，以防止攻击者重用内存中以前 +的内容。例如，在系统调用返回时清除堆栈（CONFIG_GCC_PLUGIN_STACKLEAK）, +在释放堆内容是清除其内容。这有助于防止许多未初始化变量攻击、堆栈内容 +泄露、堆内容泄露以及使用后释放攻击（user-after-free）。 + +目标追踪 +-------- + +为了帮助消除导致内核地址被写入用户空间的各种错误，需要跟踪写入的目标。 +如果缓冲区的目标是用户空间（例如，基于seq_file的/proc文件），则应该自 +动审查敏感值。 diff --git a/Documentation/translations/zh_CN/security/snp-tdx-threat-model.rst b/Documentation/translations/zh_CN/security/snp-tdx-threat-model.rst new file mode 100644 index 000000000000..b51eeaebab67 --- /dev/null +++ b/Documentation/translations/zh_CN/security/snp-tdx-threat-model.rst @@ -0,0 +1,209 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/security/snp-tdx-threat-model.rst + +:翻译: + + 毛玉贤 Yuxian Mao <maoyuxian@cqsoftware.com.cn> + +========================== +Linux中x86虚拟化的机密计算 +========================== + +.. contents:: :local: + +By: Elena Reshetova <elena.reshetova@intel.com> and Carlos Bilbao <carlos.bilbao.osdev@gmail.com> + +动机 +==== + +在x86虚拟环境中从事机密计算工作的内核开发人员，是基于一组与传统Linux内核 +威胁模型有所不同的假设条件下开展工作的。传统意义上，Linux威胁模型承认攻 +击者可以存在于用户空间，以及一小部分能够通过各种网络接口或有限的硬件特定 +暴露接口（如USB、Thunderbolt）与内核交互的外部攻击者。本文档的目的是解释 +在机密计算领域中出现的额外攻击向量，并讨论为 Linux 内核提出的保护机制。 + +概述与术语 +========== + +机密计算（Confidential Computing，简称CoCo）是一个广泛的术语，涵盖了多种 +旨在保护数据在使用过程中（与静态数据或传输数据相比）的机密性和完整性的安 +全技术。从本质上讲，机密计算（CoCo）解决方案提供了一个受信任执行环境（TEE）， +在该环境中可以进行安全的数据处理，因此，它们通常根据预期在TEE中运行的软件 +来进一步划分为不同的子类型。本文档专注于一类针对虚拟化环境的机密计算技术 +（Confidential Computing, CoCo），这些技术允许在可信执行环境 +（Trusted Execution Environment, TEE）中运行虚拟机（VM）。从现在起，本文档 +将把这一类机密计算（CoCo）技术称为“虚拟化环境（VE）中的机密计算（CoCo）”。 + +在虚拟化环境中，机密计算（CoCo）指的是一组硬件和/或软件技术，这些技术能够 +为在CoCo虚拟机（VM）内运行的软件提供更强的安全保障。具体来说，机密计算允许 +其用户确认所有软件组件的可信度，从而将其包含在精简的受信任计算基（TCB）中， +这是基于机密计算具备验证这些受信组件状态的能力。 + +虽然不同技术之间的具体实现细节有所不同，但所有现有机制都旨在为虚拟机的客户 +内存和执行状态（vCPU寄存器）提供更高的机密性和完整性，更严格地控制客户中断 +注入，并提供一些额外机制来控制客户与宿主机之间的页映射。有关x86特定解决方案 +的更多细节，可以参考 +:doc:`Intel Trust Domain Extensions (TDX) </arch/x86/tdx>` 和 +`AMD Memory Encryption <https://www.amd.com/system/files/techdocs/sev-snp-strengthening-vm-isolation-with-integrity-protection-and-more.pdf>`_. + +基本的机密计算（CoCo）客户布局包括宿主机、客户机、用于客户机与宿主机之间通信 +的接口、能够支持CoCo虚拟机（VM）的平台，以及一个在客户VM和底层平台之间充当安 +全管理员的可信中介。宿主机侧的虚拟机监视器（VMM）通常由传统VMM功能的一个子集 +组成，并仍然负责客户机生命周期的管理，即创建或销毁CoCo虚拟机、管理其对系统资 +源的访问等。然而，由于它通常不在CoCo VM的可信计算基（TCB）内，其访问权限受到 +限制，以确保实现安全目标。 + +在下图中，"<--->" 线表示机密计算（CoCo）安全管理员与其余组件之间的双向通信通 +道或接口，这些组件包括客户机、宿主机和硬件（数据流）:: + + +-------------------+ +-----------------------+ + | CoCo guest VM |<---->| | + +-------------------+ | | + | Interfaces | | CoCo security manager | + +-------------------+ | | + | Host VMM |<---->| | + +-------------------+ | | + | | + +--------------------+ | | + | CoCo platform |<--->| | + +--------------------+ +-----------------------+ + +机密计算（CoCo）安全管理器的具体细节在在不同技术之间存在显著差异。例如，在某 +些情况下，它可能通过硬件（HW）实现，而在其他情况下，它可能是纯软件（SW）实现。 + +现有的Linux内核威胁模型 +======================= + +当前Linux内核威胁模型的总体组件包括:: + + +-----------------------+ +-------------------+ + | |<---->| Userspace | + | | +-------------------+ + | External attack | | Interfaces | + | vectors | +-------------------+ + | |<---->| Linux Kernel | + | | +-------------------+ + +-----------------------+ +-------------------+ + | Bootloader/BIOS | + +-------------------+ + +-------------------+ + | HW platform | + +-------------------+ + +在启动过程中，引导加载程序（bootloader）和内核之间也存在通信，但本图并未明确 +表示这一点。“接口”框表示允许内核与用户空间之间通信的各种接口。 这包括系统调用、 +内核 API、设备驱动程序等。 + +现有的 Linux 内核威胁模型通常假设其在一个受信任的硬件平台上执行，并且所有固件 +和启动加载程序都包含在该平台的受信任计算基（TCB）中。主要攻击者驻留在用户空间 +中，来自用户空间的所有数据通常被认为是不可信的，除非用户空间具有足够的特权来 +执行受信任的操作。此外，通常还会考虑外部攻击者，包括那些能够访问启用的外部网络 +（例如以太网、无线网络、蓝牙）、暴露的硬件接口（例如 USB、Thunderbolt），以及 +能够离线修改磁盘内容的攻击者。 + +关于外部攻击途径，值得注意的是，在大多数情况下，外部攻击者会首先尝试利用用户空 +间的漏洞，但攻击者也可能直接针对内核，特别是在宿主机具有物理访问权限的情况下。直 +接攻击内核的例子包括漏洞 CVE-2019-19524、CVE-2022-0435 和 CVE-2020-24490。 + +机密计算威胁模型及其安全目标 +============================ + +机密计算在上述攻击者列表中增加了一种新的攻击者类型：可能存在行为不当的宿主机 +（这可能包括传统虚拟机监视器VMM的部分组件或全部），由于其较大的软件攻击面， +通常被置于CoCo VM TCB之外。需要注意的是，这并不意味着宿主机或VMM是故意恶意的， +而是强调拥有一个较小的CoCo VM TCB具有安全价值。这种新型的攻击者可以被视为一种 +更强大的外部攻击者，因为它位于同一物理机器上（与远程网络攻击者不同），并且对 +客户机内核与大部分硬件的通信具有控制权:: + + +------------------------+ + | CoCo guest VM | + +-----------------------+ | +-------------------+ | + | |<--->| | Userspace | | + | | | +-------------------+ | + | External attack | | | Interfaces | | + | vectors | | +-------------------+ | + | |<--->| | Linux Kernel | | + | | | +-------------------+ | + +-----------------------+ | +-------------------+ | + | | Bootloader/BIOS | | + +-----------------------+ | +-------------------+ | + | |<--->+------------------------+ + | | | Interfaces | + | | +------------------------+ + | CoCo security |<--->| Host/Host-side VMM | + | manager | +------------------------+ + | | +------------------------+ + | |<--->| CoCo platform | + +-----------------------+ +------------------------+ + +传统上，宿主机对客户机数据拥有无限访问权限，并可以利用这种访问权限来攻击客户虚 +拟机。然而，机密计算（CoCo）系统通过添加诸如客户数据保密性和完整性保护等安全 +特性来缓解此类攻击。该威胁模型假设这些安全特性是可用且完好的。 + +这个 **Linux内核机密计算虚拟机（CoCo VM）的安全目标** 可以总结如下： + +1. 保护CoCo客户机私有内存和寄存器的机密性和完整性。 + +2. 防止宿主机特权升级到CoCo客户机Linux内核。虽然宿主机（及主机端虚拟机管理程序） + 确实需要一定的特权来创建、销毁或暂停访客，但防止特权升级的部分目标是确保这些 + 操作不会为攻击者提供获取客户机内核访问权限的途径。 + +上述安全目标导致了两个主要的**Linux内核机密计算虚拟机（CoCo VM）资产**： + +1. 客户机内核执行上下文。 +2. 客户机内核私有内存。 + +宿主机对CoCo客户机资源具有完全控制权，并可以随时拒绝访问这些资源。资源的示例包 +括CPU时间、客户机可以消耗的内存、网络带宽等。因此，宿主机对CoCo客户机的拒绝服务 +（DoS）攻击超出了此威胁模型的范围。 + +Linux CoCo虚拟机攻击面是指从CoCo客户机Linux内核暴露到不受信任的主机的任何接口， +这些接口未被CoCo技术的软硬件保护所覆盖。这包括所有可能的侧信道攻击以及瞬态执 +行侧信道攻击。显式（非旁道）接口的示例包括访问端口I/O、内存映射I/O（MMIO）和 +直接内存访问（DMA）接口、访问PCI配置空间、特定于虚拟机管理程序（VMM）的超调用 +（指向主机端VMM）、访问共享内存页、主机允许注入到访客内核的中断，以及特定于 +CoCo技术的超调用（如果存在）。此外，在CoCo系统中，宿主机通常控制创建CoCo客户机 +的过程：它有方法将固件和引导程序镜像、内核镜像以及内核命令行加载到客户机中。所有 +这些数据在通过证明机制确认其完整性和真实性之前，都应视为不可信的。 + +下表显示了针对CoCo客户机Linux内核的威胁矩阵，但并未讨论潜在的缓解策略。该矩阵涉 +及的是CoCo特定版本的客户机、宿主机和平台。 + +.. list-table:: CoCo Linux客户机内核威胁矩阵 + :widths: auto + :align: center + :header-rows: 1 + + * - 威胁名称 + - 威胁描述 + + * - 客户机恶意配置 + - 一个行为不当的主机修改了以下其中一个客户机的配置： + + 1. 客户机固件或引导加载程序 + + 2. 客户机内核或模块二进制文件 + + 3. 客户机命令行参数 + + 这使得宿主机能够破坏在CoCo客户虚拟机内部运行代码的完整性，从而违反了机密计算 + （CoCo）的安全目标。 + + * - CoCo客户机数据攻击 + - 一个行为不当的宿主机对CoCo客户虚拟机与宿主机管理的物理或虚拟设备之间传输的数 + 据拥有完全控制权。这使得宿主机可以对这类数据的保密性、完整性和新鲜性进行任何攻击。 + + * - 格式错误的运行时输入 + - 一个行为不当的宿主机通过客户机内核代码使用的任意通信接口注入格式错误的输入。 + 如果代码没有正确处理这些输入，这可能导致从宿主机到客户机内核的特权提升。这包 + 括传统的侧信道攻击和/或瞬态执行攻击路径。 + + * - 恶意运行时输入 + - 一个行为不当的宿主机通过客户机内核代码使用的任意通信接口注入特定的输入值。与之前 + 的攻击向量（格式错误的运行时输入）不同，这个输入并非格式错误，而是其值被精心设 + 计以影响客户机内核的安全性。这类输入的例子包括向客户机提供恶意的时间或向客户机 + 的随机数生成器提供熵值。此外，如果它导致客户机内核执行特定操作（例如处理主机注 + 入的中断），此类事件的时序本身也可能成为一种攻击路径。这种攻击是对提供的宿主机输 + 入具有抵抗性的一种方式。 diff --git a/Documentation/translations/zh_CN/security/tpm/index.rst b/Documentation/translations/zh_CN/security/tpm/index.rst new file mode 100644 index 000000000000..707646590647 --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/index.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/index.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +================ +可信平台模块文档 +================ + +.. toctree:: + + tpm_event_log + tpm-security + tpm_tis + tpm_vtpm_proxy + xen-tpmfront + tpm_ftpm_tee diff --git a/Documentation/translations/zh_CN/security/tpm/tpm-security.rst b/Documentation/translations/zh_CN/security/tpm/tpm-security.rst new file mode 100644 index 000000000000..26818d28c98f --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm-security.rst @@ -0,0 +1,151 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm-security.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +TPM安全 +======= + +本文档的目的是描述我们如何使内核使用TPM在面对外部窥探和数据包篡改 +攻击（文献中称为被动和主动中间人攻击）时保持合理的稳健性。当前的 +安全文档适用于TPM2.0。 + +介绍 +---- + +TPM通常是一个通过某种低带宽总线连接到PC的独立芯片。虽然有一些 +例外，例如Intel PTT，它是运行在靠近CPU的软件环境中的软件TPM， +容易受到不同类型的攻击，但目前大多数强化的安全环境要求使用独立 +硬件TPM，这是本文讨论的使用场景。 + +总线上的窥探和篡改攻击 +---------------------- + +当前的技术状态允许使用 `TPM Genie`_ 硬件中间人，这是一种简单的外部设备，可以在 +任何系统或笔记本电脑上几秒钟内安装。最近成功演示了针对 `Windows Bitlocker TPM`_ +系统的攻击。最近同样的攻击针对 `基于TPM的Linux磁盘加密`_ 方案也遭到了同样的攻击。 +下一阶段的研究似乎是入侵总线上现有的设备以充当中间人，因此攻击者需要物理访问几 +秒钟的要求可能不再存在。然而，本文档的目标是尽可能在这种环境下保护TPM的机密性和 +完整性，并尝试确保即使我们不能防止攻击，至少可以检测到它。 + +不幸的是，大多数TPM功能，包括硬件重置功能，都能被能够访问总线的攻击 +者控制，因此下面我们将讨论一些可能出现的干扰情况。 + +测量（PCR）完整性 +----------------- + +由于攻击者可以向TPM发送自己的命令，他们可以发送任意的PCR扩展，从而破 +坏测量系统，这将是一种烦人的拒绝服务攻击。然而，针对密封到信任测量中 +的实体，有两类更严重的攻击。 + +1. 攻击者可以拦截来自系统的所有PCR扩展，并完全替换为自己的值，产生 + 一个未篡改状态的重现，这会使PCR测量证明状态是可信的，并释放密钥。 + +2. 攻击者可能会在某个时刻重置TPM，清除PCR，然后发送自己的测量，从而 + 有效地覆盖TPM已经完成的启动时间测量。 + +第一种攻击可以通过始终对PCR扩展和读取命令进行HMAC保护来防止，这意味着 +如果没有在响应中产生可检测的HMAC失败，则测量值无法被替换。然而第二种 +攻击只能通过依赖某种机制来检测，这种机制会在TPM重置后发生变化。 + +秘密保护 +-------- + +某些进出TPM的信息,如密钥密封、私钥导入和随机数生成容易被拦截，而仅仅 +使用HMAC保护无法防止这种情况。因此，对于这些类型的命令，我们必须使用 +请求和响应加密来防止秘密信息的泄露。 + +与TPM建立初始信任 +----------------- + +为了从一开始就提供安全性，必须建立一个初始的共享或非对称秘密，并且该 +秘钥必须对攻击者不可知。最明显的途径是使用背书和存储种子，这些可以用 +来派生非对称密钥。然而，使用这些密钥很困难，因为将它们传递给内核的唯 +一方法是通过命令行，这需要在启动系统中进行广泛的支持，而且无法保证任 +何一个层次不会有任何形式的授权。 + +Linux内核选择的机制是从空种子使用标准的存储种子参数派生出主椭圆曲线 +密钥。空种子有两个优势：首先该层次物理上无法具有授权，因此我们始终可 +以使用它；其次空种子在TPM重置时会发生变化，这意味着如果我们在当天开始 +时基于空种子建立信任，如果TPM重置且种子变化，则所有派生的密钥进行加盐 +处理的会话都将失败。 + +显然，在没有任何其他共享秘密的情况下使用空种子，我们必须创建并读取初始 +公钥，这当然可能会被总线中间人拦截并替换。然而，TPM有一个密钥认证机制 +（使用EK背书证书，创建认证身份密钥，并用该密钥认证空种子主密钥），但由 +于它过于复杂，无法在内核中运行，因此我们保留空主密钥名称的副本，通过 +sysfs导出，以便用户空间在启动时进行完整的认证。这里的明确保证是，如果空 +主密钥认证成功，那么从当天开始的所有TPM交易都是安全的；如果认证失败，则 +说明系统上有中间人（并且任何在启动期间使用的秘密可能已被泄露）。 + +信任堆叠 +-------- + +在当前的空主密钥场景中，TPM必须在交给下一个使用者之前完全清除。然而， +内核将派生出的空种子密钥的名称传递给用户空间，用户空间可以通过认证来 +验证该名称。因此，这种名称传递链也可以用于各个启动组件之间（通过未指 +定的机制）。例如grub可以使用空种子方案来实现安全性，并将名称交给内核。 +内核可以派生出密钥和名称，并确定如果它们与交接的版本不同，则表示发生 +了篡改。因此可以通过名称传递将任意启动组件（从UEFI到grub到内核）串联 +起来，只要每个后续组件知道如何收集该名称,并根据其派生的密钥进行验证。 + +会话属性 +-------- + +所有内核使用的TPM命令都允许会话。HMAC会话可用于检查请求和响应的完整性， +而解密和加密标志可用于保护参数和响应。HMAC和加密密钥通常是从共享授权秘 +钥推导出来的，但对于许多内核操作来说，这些密钥是已知的（通常为空）。因 +此内核使用空主密钥作为盐密钥来创建每个HMAC会话，这样就为会话密钥的派生 +提供了加密输入。因此内核仅需创建一次空主密钥（作为一个易失的TPM句柄）， +并将其保存在tpm_chip中，用于每次在内核中使用TPM时。由于内核资源管理器缺 +乏去间隙化，当前每次操作都需要创建和销毁会话，但未来可能会将单个会话重用 +用于内核中的HMAC、加密和解密会话。 + +保护类型 +-------- + +对于每个内核操作，我们使用空主密钥加盐的HMAC来保护完整性。此外我们使用参数 +加密来保护密钥密封，并使用参数解密来保护密钥解封和随机数生成。 + +空主密钥认证在用户空间的实现 +============================ + +每个TPM都会附带几个X.509证书，通常用于主背书密钥。本文档假设存在椭圆曲线 +版本的证书，位于01C00002，但也同样适用于RSA证书(位于01C00001)。 + +认证的第一步是使用 `TCG EK Credential Profile`_ 模板进行主密钥的创建，该 +模板允许将生成的主密钥与证书中的主密钥进行比较（公钥必须匹配）。需要注意 +的是，生成EK主密钥需要EK层级密码，但EC主密钥的预生成版本应位于81010002， +并且可以无需密钥授权对其执行TPM2_ReadPublic()操作。接下来，证书本身必须 +经过验证，以确保其可以追溯到制造商根证书（该根证书应公开在制造商网站上）。 +完成此步骤后将在TPM内部生成一个认证密钥（AK），并使用TPM2_MakeCredential、 +AK的名称和EK公钥加密一个秘密。然后TPM执行TPM2_ActivateCredential，只有在 +TPM、EK和AK之间的绑定关系成立时，才能恢复秘密。现在，生成的AK可以用于对由 +内核导出的空主密钥进行认证。由于TPM2_MakeCredential/ActivateCredential操作 +相对复杂，下面将描述一种涉及外部生成私钥的简化过程。 + +这个过程是通常基于隐私CA认证过程的简化缩写。假设此时认证由TPM所有者进行， +所有者只能访问所有者层次。所有者创建一个外部公/私钥对（假设是椭圆曲线）， +并使用内部包装过程将私钥进行封装以便导入，该私钥被其父级由EC派生的存储主密 +钥保护。TPM2_Import()操作使用一个以EK主密钥为盐值的参数解密HMAC会话（这也不 +需要EK密钥授权），意味着内部封装密钥是加密参数，因此除非TPM拥有认证的EK，否 +则无法执行导入操作。如果该命令成功执行并且HMAC在返回时通过验证，我们就知道 +我们有一个只为认证TPM加载的私钥副本。现在该密钥已加载到TPM中，并且存储主密 +钥已被清除（以释放空间用于生成空密钥）。 + +现在根据 `TCG TPM v2.0 Provisioning Guidance`_ 中的存储配置生成空EC主密钥； +该密钥的名称（即公钥区域的哈希值）被计算出来并与内核在/sys/class/tpm/tpm0/null_name +中提供的空种子名称进行比较。如果名称不匹配，TPM就被认为是受损的。如果名称匹配， +用户执行TPM2_Certify()，使用空主密钥作为对象句柄，使用加载的私钥作为签名句柄， +并提供随机的合格数据。返回的certifyInfo的签名将与加载的私钥的公钥部分进行验证， +并检查合格数据以防止重放。如果所有测试都通过，用户就可以确信TPM的完整性和隐私 +性在整个内核启动过程中得到了保护。 + +.. _TPM Genie: https://www.nccgroup.trust/globalassets/about-us/us/documents/tpm-genie.pdf +.. _Windows Bitlocker TPM: https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network +.. _基于TPM的Linux磁盘加密: https://www.secura.com/blog/tpm-sniffing-attacks-against-non-bitlocker-targets +.. _TCG EK Credential Profile: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/ +.. _TCG TPM v2.0 Provisioning Guidance: https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/ diff --git a/Documentation/translations/zh_CN/security/tpm/tpm_event_log.rst b/Documentation/translations/zh_CN/security/tpm/tpm_event_log.rst new file mode 100644 index 000000000000..9c173291ac3e --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm_event_log.rst @@ -0,0 +1,49 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm_event_log.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +=========== +TPM事件日志 +=========== + +本文档简要介绍了什么是TPM日志，以及它是如何从预启动固件移交到操作系统的。 + +介绍 +==== + +预启动固件维护一个事件日志，每当它将某些内容哈希到任何一个PCR寄存器时，该 +日志会添加新条目。这些事件按类型分类，并包含哈希后的PCR寄存器值。通常，预 +启动固件会哈希那些即将移交执行权或与启动过程相关的组件。 + +其主要应用是远程认证，而它之所以有用的原因在[1]中第一部分很好地阐述了： + +认证用于向挑战者提供有关平台状态的信息。然而，PCR的内容难以解读；因此，当 +PCR内容附有测量日志时，认证通常会更有用。尽管测量日志本身并不可信，但它们 +包含比PCR内容更为丰富的信息集。PCR内容用于对测量日志进行验证。 + +UEFI事件日志 +============ + +UEFI提供的事件日志有一些比较奇怪的特性。 + +在调用ExitBootServices()之前，Linux EFI引导加载程序会将事件日志复制到由 +引导加载程序自定义的配置表中。不幸的是，通过ExitBootServices()生成的事件 +并不会出现在这个表里。 + +固件提供了一个所谓的最终事件配置表排序来解决这个问题。事件会在第一次调用 +EFI_TCG2_PROTOCOL.GetEventLog()后被镜像到这个表中。 + +这引出了另一个问题：无法保证它不会在 Linux EFI stub 开始运行之前被调用。 +因此，在 stub 运行时，它需要计算并将最终事件表的大小保存到自定义配置表中， +以便TPM驱动程序可以在稍后连接来自自定义配置表和最终事件表的两个事件日志时 +跳过这些事件。 + +参考文献 +======== + +- [1] https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/ +- [2] The final concatenation is done in drivers/char/tpm/eventlog/efi.c diff --git a/Documentation/translations/zh_CN/security/tpm/tpm_ftpm_tee.rst b/Documentation/translations/zh_CN/security/tpm/tpm_ftpm_tee.rst new file mode 100644 index 000000000000..5901eee32563 --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm_ftpm_tee.rst @@ -0,0 +1,31 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm_ftpm_tee.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +=========== +固件TPM驱动 +=========== + +本文档描述了固件可信平台模块（fTPM）设备驱动。 + +介绍 +==== + +该驱动程序是用于ARM的TrustZone环境中实现的固件的适配器。该驱动 +程序允许程序以与硬件TPM相同的方式与TPM进行交互。 + +设计 +==== + +该驱动程序充当一个薄层，传递命令到固件实现的TPM并接收其响应。驱动 +程序本身并不包含太多逻辑，更像是固件与内核/用户空间之间的一个管道。 + +固件本身基于以下论文： +https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/ftpm1.pdf + +当驱动程序被加载时，它会向用户空间暴露 ``/dev/tpmX`` 字符设备，允许 +用户空间通过该设备与固件TPM进行通信。 diff --git a/Documentation/translations/zh_CN/security/tpm/tpm_tis.rst b/Documentation/translations/zh_CN/security/tpm/tpm_tis.rst new file mode 100644 index 000000000000..0fb009f93e10 --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm_tis.rst @@ -0,0 +1,43 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm_tis.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +TPM FIFO接口驱动 +================ + +TCG PTP规范定义了两种接口类型：FIFO和CRB。前者基于顺序的读写操作， +后者基于包含完整命令或响应的缓冲区。 + +FIFO（先进先出）接口被tpm_tis_core依赖的驱动程序使用。最初，Linux只 +有一个名为tpm_tis的驱动，覆盖了内存映射（即 MMIO）接口，但后来它被 +扩展以支持TCG标准所支持的其他物理接口。 + +由于历史原因，最初的MMIO驱动被称为tpm_tis，而FIFO驱动的框架被命名为 +tpm_tis_core。在tpm_tis中的“tis”后缀来自TPM接口规范，这是针对TPM1.x +芯片的硬件接口规范。 + +通信基于一个由TPM芯片通过硬件总线或内存映射共享的20KiB 缓冲区，具体 +取决于物理接线。该缓冲区进一步分为五个相等大小的4KiB缓冲区，为CPU和 +TPM之间的通信提供等效的寄存器集。这些通信端点在TCG术语中称为localities。 + +当内核想要向TPM芯片发送命令时，它首先通过在TPM_ACCESS寄存器中设置 +requestUse位来保留locality0。当访问被授予时，该位由芯片清除。一旦完成 +通信，内核会写入TPM_ACCESS.activeLocality位。这告诉芯片该本地性已被 +释放。 + +待处理的本地性由芯片按优先级降序逐个服务，一次一个： + +- Locality0优先级最低。 +- Locality5优先级最高。 + +关于localities的更多信息和含义，请参阅TCG PC客户端平台TPM 配置文件规范的第3.2节。 + +参考文献 +======== + +TCG PC客户端平台TPM配置文件（PTP）规范 +https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/ diff --git a/Documentation/translations/zh_CN/security/tpm/tpm_vtpm_proxy.rst b/Documentation/translations/zh_CN/security/tpm/tpm_vtpm_proxy.rst new file mode 100644 index 000000000000..bc92cfb684c3 --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm_vtpm_proxy.rst @@ -0,0 +1,51 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm_vtpm_proxy.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +========================== +Linux容器的虚拟TPM代理驱动 +========================== + +| 作者： +| Stefan Berger <stefanb@linux.vnet.ibm.com> + +本文档描述了用于Linux容器的虚拟可信平台模块（vTPM）代理设备驱动。 + +介绍 +==== + +这项工作的目标是为每个Linux容器提供TPM功能。这使得程序能够像与物理系统 +上的TPM交互一样，与容器中的TPM进行交互。每个容器都会获得一个唯一的、模 +拟的软件TPM。 + +设计 +==== + +为了使每个容器都能使用模拟的软件TPM，容器管理栈需要创建一对设备，其中 +包括一个客户端TPM字符设备 ``/dev/tpmX`` （X=0,1,2...）和一个‘服务器端’ +文件描述符。当文件描述符传被递给TPM模拟器时，前者通过创建具有适当主次 +设备号的字符设备被移入容器，然后，容器内的软件可以使用字符设备发送TPM +命令，模拟器将通过文件描述符接收这些命令，并用它来发送响应。 + +为了支持这一点，虚拟TPM代理驱动程序提供了一个设备 ``/dev/vtpmx`` ，该设备 +用于通过ioctl创建设备对。ioctl将其作为配置设备的输入标志，例如这些标志指示 +TPM模拟器是否支持TPM1.2或TPM2功能。ioctl的结果是返回‘服务器端’的文件描述符 +以及创建的字符设备的主次设备号。此外，还会返回TPM字符设备的编号。例如，如果 +创建了 ``/dev/tpm10`` ，则返回编号（ ``dev_num`` ）10。 + +一旦设备被创建，驱动程序将立即尝试与TPM进行通信。来自驱动程序的所有命令 +都可以从ioctl返回的文件描述符中读取。这些命令应该立即得到响应。 + +UAPI +==== + +该API在以下内核代码中： + +include/uapi/linux/vtpm_proxy.h +drivers/char/tpm/tpm_vtpm_proxy.c + +函数：vtpmx_ioc_new_dev diff --git a/Documentation/translations/zh_CN/security/tpm/xen-tpmfront.rst b/Documentation/translations/zh_CN/security/tpm/xen-tpmfront.rst new file mode 100644 index 000000000000..fa085d98a99b --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/xen-tpmfront.rst @@ -0,0 +1,114 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/xen-tpmfront.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +================ +Xen的虚拟TPM接口 +================ + +作者：Matthew Fioravante (JHUAPL), Daniel De Graaf (NSA) + +本文档描述了用于Xen的虚拟可信平台模块（vTPM）子系统。假定读者熟悉 +Xen和Linux的构建和安装，并对TPM和vTPM概念有基本的理解。 + +介绍 +---- + +这项工作的目标是为虚拟客户操作系统（在Xen中称为DomU）提供TPM功能。这使得 +程序能够像与物理系统上的TPM交互一样，与虚拟系统中的TPM进行交互。每个客户 +操作系统都会获得一个唯一的、模拟的软件TPM。然而，vTPM的所有秘密（如密钥、 +NVRAM 等）由vTPM管理域进行管理，该域将这些秘密封存到物理TPM中。如果创建这 +些域（管理域、vTPM域和客户域）的过程是可信的，vTPM子系统就能将根植于硬件 +TPM的信任链扩展到Xen中的虚拟机。vTPM的每个主要组件都作为一个独立的域实现， +从而通过虚拟机监控程序（hypervisor）提供安全隔离。 + +这个mini-os vTPM 子系统是建立在IBM和Intel公司之前的vTPM工作基础上的。 + + +设计概述 +-------- + +vTPM的架构描述如下:: + + +------------------+ + | Linux DomU | ... + | | ^ | + | v | | + | xen-tpmfront | + +------------------+ + | ^ + v | + +------------------+ + | mini-os/tpmback | + | | ^ | + | v | | + | vtpm-stubdom | ... + | | ^ | + | v | | + | mini-os/tpmfront | + +------------------+ + | ^ + v | + +------------------+ + | mini-os/tpmback | + | | ^ | + | v | | + | vtpmmgr-stubdom | + | | ^ | + | v | | + | mini-os/tpm_tis | + +------------------+ + | ^ + v | + +------------------+ + | Hardware TPM | + +------------------+ + +* Linux DomU: + 希望使用vTPM的基于Linux的客户机。可能有多个这样的实例。 + +* xen-tpmfront.ko: + Linux内核虚拟TPM前端驱动程序。该驱动程序为基于Linux的DomU提供 + vTPM访问。 + +* mini-os/tpmback: + Mini-os TPM后端驱动程序。Linux前端驱动程序通过该后端驱动程序连 + 接，以便在Linux DomU和其vTPM之间进行通信。该驱动程序还被 + vtpmmgr-stubdom用于与vtpm-stubdom通信。 + +* vtpm-stubdom: + 一个实现vTPM的mini-os存根域。每个正在运行的vtpm-stubdom实例与系统 + 上的逻辑vTPM之间有一一对应的关系。vTPM平台配置寄存器（PCRs）通常都 + 初始化为零。 + +* mini-os/tpmfront: + Mini-os TPM前端驱动程序。vTPM mini-os域vtpm-stubdom使用该驱动程序 + 与vtpmmgr-stubdom通信。此驱动程序还用于与vTPM域通信的mini-os域，例 + 如 pv-grub。 + +* vtpmmgr-stubdom: + 一个实现vTPM管理器的mini-os域。系统中只有一个vTPM管理器，并且在整个 + 机器生命周期内应一直运行。此域调节对系统中物理TPM的访问，并确保每个 + vTPM的持久状态。 + +* mini-os/tpm_tis: + Mini-osTPM1.2版本TPM 接口规范（TIS）驱动程序。该驱动程序由vtpmmgr-stubdom + 用于直接与硬件TPM通信。通信通过将硬件内存页映射到vtpmmgr-stubdom来实现。 + +* 硬件TPM: + 固定在主板上的物理 TPM。 + +与Xen的集成 +----------- + +vTPM驱动程序的支持已在Xen4.3中通过libxl工具堆栈添加。有关设置vTPM和vTPM +管理器存根域的详细信息，请参见Xen文档（docs/misc/vtpm.txt）。一旦存根域 +运行，与磁盘或网络设备相同，vTPM设备将在域的配置文件中进行设置 + +为了使用诸如IMA（完整性测量架构）等需要在initrd之前加载TPM的功能，必须将 +xen-tpmfront驱动程序编译到内核中。如果不使用这些功能，驱动程序可以作为 +模块编译，并像往常一样加载。 diff --git a/Documentation/translations/zh_TW/admin-guide/README.rst b/Documentation/translations/zh_TW/admin-guide/README.rst index a6e34c200ea3..0b038074d9d1 100644 --- a/Documentation/translations/zh_TW/admin-guide/README.rst +++ b/Documentation/translations/zh_TW/admin-guide/README.rst @@ -149,7 +149,7 @@ Linux內核6.x版本 <http://kernel.org/> "make xconfig" 基於Qt的配置工具。 - "make gconfig" 基於GTK+的配置工具。 + "make gconfig" 基於GTK的配置工具。 "make oldconfig" 基於現有的 ./.config 文件選擇所有選項，並詢問 新配置選項。 diff --git a/Documentation/translations/zh_TW/process/submit-checklist.rst b/Documentation/translations/zh_TW/process/submit-checklist.rst index 0ecb187753e4..a0cb91a6945f 100644 --- a/Documentation/translations/zh_TW/process/submit-checklist.rst +++ b/Documentation/translations/zh_TW/process/submit-checklist.rst @@ -85,8 +85,8 @@ Linux內核補丁提交檢查單 17) 所有新的模塊參數都記錄在 ``MODULE_PARM_DESC()`` 18) 所有新的用戶空間接口都記錄在 ``Documentation/ABI/`` 中。有關詳細信息， - 請參閱 ``Documentation/ABI/README`` 。更改用戶空間接口的補丁應該抄送 - linux-api@vger.kernel.org。 + 請參閱 Documentation/admin-guide/abi.rst (或 ``Documentation/ABI/README``)。 + 更改用戶空間接口的補丁應該抄送 linux-api@vger.kernel.org\ 。 19) 已通過至少注入slab和page分配失敗進行檢查。請參閱 ``Documentation/fault-injection/`` 。 如果新代碼是實質性的，那麼添加子系統特定的故障注入可能是合適的。 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/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index bf555c2270f5..1998dc146c56 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -1050,7 +1050,7 @@ Its attributes are: midi1_num_groups The number of groups for MIDI 1.0 (0-16) ui_hint UI-hint of this FB 0: unknown, 1: receiver, 2: sender, 3: both - midi_ci_verison Supported MIDI-CI version number (8 bit) + midi_ci_version Supported MIDI-CI version number (8 bit) is_midi1 Legacy MIDI 1.0 device (0-2) 0: MIDI 2.0 device, 1: MIDI 1.0 without restriction, or diff --git a/Documentation/userspace-api/accelerators/ocxl.rst b/Documentation/userspace-api/accelerators/ocxl.rst index db7570d5e50d..4e213af70237 100644 --- a/Documentation/userspace-api/accelerators/ocxl.rst +++ b/Documentation/userspace-api/accelerators/ocxl.rst @@ -3,8 +3,11 @@ OpenCAPI (Open Coherent Accelerator Processor Interface) ======================================================== OpenCAPI is an interface between processors and accelerators. It aims -at being low-latency and high-bandwidth. The specification is -developed by the `OpenCAPI Consortium <http://opencapi.org/>`_. +at being low-latency and high-bandwidth. + +The specification was developed by the OpenCAPI Consortium, and is now +available from the `Compute Express Link Consortium +<https://computeexpresslink.org/resource/opencapi-specification-archive/>`_. It allows an accelerator (which could be an FPGA, ASICs, ...) to access the host memory coherently, using virtual addresses. An OpenCAPI diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst new file mode 100644 index 000000000000..535f49047ce6 --- /dev/null +++ b/Documentation/userspace-api/dma-buf-heaps.rst @@ -0,0 +1,25 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================== +Allocating dma-buf using heaps +============================== + +Dma-buf Heaps are a way for userspace to allocate dma-buf objects. They are +typically used to allocate buffers from a specific allocation pool, or to share +buffers across frameworks. + +Heaps +===== + +A heap represents a specific allocator. The Linux kernel currently supports the +following heaps: + + - The ``system`` heap allocates virtually contiguous, cacheable, buffers. + + - The ``cma`` heap allocates physically contiguous, cacheable, + buffers. Only present if a CMA region is present. Such a region is + usually created either through the kernel commandline through the + `cma` parameter, a memory region Device-Tree node with the + `linux,cma-default` property set, or through the `CMA_SIZE_MBYTES` or + `CMA_SIZE_PERCENTAGE` Kconfig options. Depending on the platform, it + might be called ``reserved``, ``linux,cma``, or ``default-pool``. 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 b1395d94b3fd..b8c73be4fb11 100644 --- a/Documentation/userspace-api/index.rst +++ b/Documentation/userspace-api/index.rst @@ -44,7 +44,9 @@ Devices and I/O :maxdepth: 1 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 6d1465315df3..7a1409ecc238 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -85,6 +85,8 @@ Code Seq# Include File Comments 0x10 20-2F arch/s390/include/uapi/asm/hypfs.h 0x12 all linux/fs.h BLK* ioctls linux/blkpg.h + linux/blkzoned.h + linux/blk-crypto.h 0x15 all linux/fs.h FS_IOC_* ioctls 0x1b all InfiniBand Subsystem <http://infiniband.sourceforge.net/> @@ -331,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 @@ -370,10 +373,12 @@ Code Seq# Include File Comments 0xB7 all uapi/linux/remoteproc_cdev.h <mailto:linux-remoteproc@vger.kernel.org> 0xB7 all uapi/linux/nsfs.h <mailto:Andrei Vagin <avagin@openvz.org>> 0xB8 01-02 uapi/misc/mrvl_cn10k_dpi.h Marvell CN10K DPI driver +0xB8 all uapi/linux/mshv.h Microsoft Hyper-V /dev/mshv driver + <mailto:linux-hyperv@vger.kernel.org> 0xC0 00-0F linux/usb/iowarrior.h -0xCA 00-0F uapi/misc/cxl.h +0xCA 00-0F uapi/misc/cxl.h Dead since 6.15 0xCA 10-2F uapi/misc/ocxl.h -0xCA 80-BF uapi/scsi/cxlflash_ioctl.h +0xCA 80-BF uapi/scsi/cxlflash_ioctl.h Dead since 6.15 0xCB 00-1F CBM serial IEC bus in development: <mailto:michael.klein@puffin.lb.shuttle.de> 0xCC 00-0F drivers/misc/ibmvmc.h pseries VMC 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 d639c61cb472..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: October 2024 +: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/media/drivers/uvcvideo.rst b/Documentation/userspace-api/media/drivers/uvcvideo.rst index a290f9fadae9..dbb30ad389ae 100644 --- a/Documentation/userspace-api/media/drivers/uvcvideo.rst +++ b/Documentation/userspace-api/media/drivers/uvcvideo.rst @@ -181,6 +181,7 @@ Argument: struct uvc_xu_control_mapping UVC_CTRL_DATA_TYPE_BOOLEAN Boolean UVC_CTRL_DATA_TYPE_ENUM Enumeration UVC_CTRL_DATA_TYPE_BITMASK Bitmask + UVC_CTRL_DATA_TYPE_RECT Rectangular area UVCIOC_CTRL_QUERY - Query a UVC XU control @@ -255,3 +256,66 @@ Argument: struct uvc_xu_control_query __u8 query Request code to send to the device __u16 size Control data size (in bytes) __u8 *data Control value + + +Driver-specific V4L2 controls +----------------------------- + +The uvcvideo driver implements the following UVC-specific controls: + +``V4L2_CID_UVC_REGION_OF_INTEREST_RECT (struct)`` + This control determines the region of interest (ROI). ROI is a + rectangular area represented by a struct :c:type:`v4l2_rect`. The + rectangle is in global sensor coordinates using pixel units. It is + independent of the field of view, not impacted by any cropping or + scaling. + + Use ``V4L2_CTRL_WHICH_MIN_VAL`` and ``V4L2_CTRL_WHICH_MAX_VAL`` to query + the range of rectangle sizes. + + Setting a ROI allows the camera to optimize the capture for the region. + The value of ``V4L2_CID_REGION_OF_INTEREST_AUTO`` control determines + the detailed behavior. + + An example of use of this control, can be found in the: + `Chrome OS USB camera HAL. + <https://chromium.googlesource.com/chromiumos/platform2/+/refs/heads/release-R121-15699.B/camera/hal/usb/>` + + +``V4L2_CID_UVC_REGION_OF_INTEREST_AUTO (bitmask)`` + This determines which, if any, on-board features should track to the + Region of Interest specified by the current value of + ``V4L2_CID_UVD__REGION_OF_INTEREST_RECT``. + + Max value is a mask indicating all supported Auto Controls. + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_EXPOSURE`` + - Setting this bit causes automatic exposure to track the region of + interest instead of the whole image. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_IRIS`` + - Setting this bit causes automatic iris to track the region of interest + instead of the whole image. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_WHITE_BALANCE`` + - Setting this bit causes automatic white balance to track the region + of interest instead of the whole image. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_FOCUS`` + - Setting this bit causes automatic focus adjustment to track the region + of interest instead of the whole image. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_FACE_DETECT`` + - Setting this bit causes automatic face detection to track the region of + interest instead of the whole image. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_DETECT_AND_TRACK`` + - Setting this bit enables automatic face detection and tracking. The + current value of ``V4L2_CID_REGION_OF_INTEREST_RECT`` may be updated by + the driver. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_IMAGE_STABILIZATION`` + - Setting this bit enables automatic image stabilization. The + current value of ``V4L2_CID_REGION_OF_INTEREST_RECT`` may be updated by + the driver. + * - ``V4L2_UVC_REGION_OF_INTEREST_AUTO_HIGHER_QUALITY`` + - Setting this bit enables automatically capture the specified region + with higher quality if possible. diff --git a/Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst b/Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst index 34d6a0a1f4d3..70b5966aaff8 100644 --- a/Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst +++ b/Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst @@ -6,7 +6,7 @@ Remote Controller's sysfs nodes ******************************* -As defined at ``Documentation/ABI/testing/sysfs-class-rc``, those are +As defined at Documentation/ABI/testing/sysfs-class-rc, those are the sysfs nodes that control the Remote Controllers: diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst index 4d56c0528ad7..b8698b85bd80 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst @@ -199,6 +199,10 @@ still cause this situation. - ``p_area`` - A pointer to a struct :c:type:`v4l2_area`. Valid if this control is of type ``V4L2_CTRL_TYPE_AREA``. + * - struct :c:type:`v4l2_rect` * + - ``p_rect`` + - A pointer to a struct :c:type:`v4l2_rect`. Valid if this control is + of type ``V4L2_CTRL_TYPE_RECT``. * - struct :c:type:`v4l2_ctrl_h264_sps` * - ``p_h264_sps`` - A pointer to a struct :c:type:`v4l2_ctrl_h264_sps`. Valid if this control is @@ -334,14 +338,26 @@ still cause this situation. - Which value of the control to get/set/try. * - :cspan:`2` ``V4L2_CTRL_WHICH_CUR_VAL`` will return the current value of the control, ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default - value of the control and ``V4L2_CTRL_WHICH_REQUEST_VAL`` indicates that - these controls have to be retrieved from a request or tried/set for - a request. In the latter case the ``request_fd`` field contains the + value of the control, ``V4L2_CTRL_WHICH_MIN_VAL`` will return the minimum + value of the control, and ``V4L2_CTRL_WHICH_MAX_VAL`` will return the maximum + value of the control. ``V4L2_CTRL_WHICH_REQUEST_VAL`` indicates that + the control value has to be retrieved from a request or tried/set for + a request. In that case the ``request_fd`` field contains the file descriptor of the request that should be used. If the device does not support requests, then ``EACCES`` will be returned. - When using ``V4L2_CTRL_WHICH_DEF_VAL`` be aware that you can only - get the default value of the control, you cannot set or try it. + When using ``V4L2_CTRL_WHICH_DEF_VAL``, ``V4L2_CTRL_WHICH_MIN_VAL`` + or ``V4L2_CTRL_WHICH_MAX_VAL`` be aware that you can only get the + default/minimum/maximum value of the control, you cannot set or try it. + + Whether a control supports querying the minimum and maximum values using + ``V4L2_CTRL_WHICH_MIN_VAL`` and ``V4L2_CTRL_WHICH_MAX_VAL`` is indicated + by the ``V4L2_CTRL_FLAG_HAS_WHICH_MIN_MAX`` flag. Most non-compound + control types support this. For controls with compound types, the + definition of minimum/maximum values are provided by + the control documentation. If a compound control does not document the + meaning of minimum/maximum value, then querying the minimum or maximum + value will result in the error code -EINVAL. For backwards compatibility you can also use a control class here (see :ref:`ctrl-class`). In that case all controls have to diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst index 4d38acafe8e1..3549417c7feb 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst @@ -441,6 +441,16 @@ See also the examples in :ref:`control`. - n/a - A struct :c:type:`v4l2_area`, containing the width and the height of a rectangular area. Units depend on the use case. + * - ``V4L2_CTRL_TYPE_RECT`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_rect`, containing a rectangle described by + the position of its top-left corner, the width and the height. Units + depend on the use case. Support for ``V4L2_CTRL_WHICH_MIN_VAL`` and + ``V4L2_CTRL_WHICH_MAX_VAL`` is optional and depends on the + ``V4L2_CTRL_FLAG_HAS_WHICH_MIN_MAX`` flag. See the documentation of + the specific control on how to interpret the minimum and maximum values. * - ``V4L2_CTRL_TYPE_H264_SPS`` - n/a - n/a @@ -657,6 +667,10 @@ See also the examples in :ref:`control`. ``dims[0]``. So setting the control with a differently sized array will change the ``elems`` field when the control is queried afterwards. + * - ``V4L2_CTRL_FLAG_HAS_WHICH_MIN_MAX`` + - 0x1000 + - This control supports getting minimum and maximum values using + vidioc_g_ext_ctrls with V4L2_CTRL_WHICH_MIN/MAX_VAL. Return Value ============ diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions index 429b5cdf05c3..35d3456cc812 100644 --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions @@ -150,6 +150,7 @@ replace symbol V4L2_CTRL_TYPE_HEVC_SPS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_HEVC_PPS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_AREA :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_RECT :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_FWHT_PARAMS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_VP8_FRAME :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_VP9_COMPRESSED_HDR :c:type:`v4l2_ctrl_type` @@ -395,6 +396,7 @@ replace define V4L2_CTRL_FLAG_HAS_PAYLOAD control-flags replace define V4L2_CTRL_FLAG_EXECUTE_ON_WRITE control-flags replace define V4L2_CTRL_FLAG_MODIFY_LAYOUT control-flags replace define V4L2_CTRL_FLAG_DYNAMIC_ARRAY control-flags +replace define V4L2_CTRL_FLAG_HAS_WHICH_MIN_MAX control-flags replace define V4L2_CTRL_FLAG_NEXT_CTRL control replace define V4L2_CTRL_FLAG_NEXT_COMPOUND control @@ -569,6 +571,8 @@ ignore define V4L2_CTRL_DRIVER_PRIV ignore define V4L2_CTRL_MAX_DIMS ignore define V4L2_CTRL_WHICH_CUR_VAL ignore define V4L2_CTRL_WHICH_DEF_VAL +ignore define V4L2_CTRL_WHICH_MIN_VAL +ignore define V4L2_CTRL_WHICH_MAX_VAL ignore define V4L2_CTRL_WHICH_REQUEST_VAL ignore define V4L2_OUT_CAP_CUSTOM_TIMINGS ignore define V4L2_CID_MAX_CTRLS 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 0d1c3a820ce6..1f8625b7646a 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -1000,6 +1000,10 @@ blobs in userspace. When the guest writes the MSR, kvm copies one page of a blob (32- or 64-bit, depending on the vcpu mode) to guest memory. +The MSR index must be in the range [0x40000000, 0x4fffffff], i.e. must reside +in the range that is unofficially reserved for use by hypervisors. The min/max +values are enumerated via KVM_XEN_MSR_MIN_INDEX and KVM_XEN_MSR_MAX_INDEX. + :: struct kvm_xen_hvm_config { @@ -1419,7 +1423,7 @@ fetch) is injected in the guest. S390: ^^^^^ -Returns -EINVAL if the VM has the KVM_VM_S390_UCONTROL flag set. +Returns -EINVAL or -EEXIST if the VM has the KVM_VM_S390_UCONTROL flag set. Returns -EINVAL if called on a protected VM. 4.36 KVM_SET_TSS_ADDR @@ -8258,6 +8262,24 @@ 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. +7.37 KVM_CAP_ARM_WRITABLE_IMP_ID_REGS +------------------------------------- + +:Architectures: arm64 +:Target: VM +:Parameters: None +:Returns: 0 on success, -EINVAL if vCPUs have been created before enabling this + capability. + +This capability changes the behavior of the registers that identify a PE +implementation of the Arm architecture: MIDR_EL1, REVIDR_EL1, and AIDR_EL1. +By default, these registers are visible to userspace but treated as invariant. + +When this capability is enabled, KVM allows userspace to change the +aforementioned registers before the first KVM_RUN. These registers are VM +scoped, meaning that the same set of values are presented on all vCPUs in a +given VM. + 8. Other capabilities. ====================== diff --git a/Documentation/virt/kvm/arm/fw-pseudo-registers.rst b/Documentation/virt/kvm/arm/fw-pseudo-registers.rst index b90fd0b0fa66..d78b53b05dfc 100644 --- a/Documentation/virt/kvm/arm/fw-pseudo-registers.rst +++ b/Documentation/virt/kvm/arm/fw-pseudo-registers.rst @@ -116,7 +116,7 @@ The pseudo-firmware bitmap register are as follows: ARM DEN0057A. * KVM_REG_ARM_VENDOR_HYP_BMAP: - Controls the bitmap of the Vendor specific Hypervisor Service Calls. + Controls the bitmap of the Vendor specific Hypervisor Service Calls[0-63]. The following bits are accepted: @@ -127,6 +127,19 @@ The pseudo-firmware bitmap register are as follows: Bit-1: KVM_REG_ARM_VENDOR_HYP_BIT_PTP: The bit represents the Precision Time Protocol KVM service. +* KVM_REG_ARM_VENDOR_HYP_BMAP_2: + Controls the bitmap of the Vendor specific Hypervisor Service Calls[64-127]. + + The following bits are accepted: + + Bit-0: KVM_REG_ARM_VENDOR_HYP_BIT_DISCOVER_IMPL_VER + This represents the ARM_SMCCC_VENDOR_HYP_KVM_DISCOVER_IMPL_VER_FUNC_ID + function-id. This is reset to 0. + + Bit-1: KVM_REG_ARM_VENDOR_HYP_BIT_DISCOVER_IMPL_CPUS + This represents the ARM_SMCCC_VENDOR_HYP_KVM_DISCOVER_IMPL_CPUS_FUNC_ID + function-id. This is reset to 0. + Errors: ======= ============================================================= diff --git a/Documentation/virt/kvm/arm/hypercalls.rst b/Documentation/virt/kvm/arm/hypercalls.rst index af7bc2c2e0cb..7400a89aabf8 100644 --- a/Documentation/virt/kvm/arm/hypercalls.rst +++ b/Documentation/virt/kvm/arm/hypercalls.rst @@ -142,3 +142,62 @@ region is equal to the memory protection granule advertised by | | | +---------------------------------------------+ | | | | ``INVALID_PARAMETER (-3)`` | +---------------------+----------+----+---------------------------------------------+ + +``ARM_SMCCC_VENDOR_HYP_KVM_DISCOVER_IMPL_VER_FUNC_ID`` +------------------------------------------------------- +Request the target CPU implementation version information and the number of target +implementations for the Guest VM. + ++---------------------+-------------------------------------------------------------+ +| Presence: | Optional; KVM/ARM64 Guests only | ++---------------------+-------------------------------------------------------------+ +| Calling convention: | HVC64 | ++---------------------+----------+--------------------------------------------------+ +| Function ID: | (uint32) | 0xC6000040 | ++---------------------+----------+--------------------------------------------------+ +| Arguments: | None | ++---------------------+----------+----+---------------------------------------------+ +| Return Values: | (int64) | R0 | ``SUCCESS (0)`` | +| | | +---------------------------------------------+ +| | | | ``NOT_SUPPORTED (-1)`` | +| +----------+----+---------------------------------------------+ +| | (uint64) | R1 | Bits [63:32] Reserved/Must be zero | +| | | +---------------------------------------------+ +| | | | Bits [31:16] Major version | +| | | +---------------------------------------------+ +| | | | Bits [15:0] Minor version | +| +----------+----+---------------------------------------------+ +| | (uint64) | R2 | Number of target implementations | +| +----------+----+---------------------------------------------+ +| | (uint64) | R3 | Reserved / Must be zero | ++---------------------+----------+----+---------------------------------------------+ + +``ARM_SMCCC_VENDOR_HYP_KVM_DISCOVER_IMPL_CPUS_FUNC_ID`` +------------------------------------------------------- + +Request the target CPU implementation information for the Guest VM. The Guest kernel +will use this information to enable the associated errata. + ++---------------------+-------------------------------------------------------------+ +| Presence: | Optional; KVM/ARM64 Guests only | ++---------------------+-------------------------------------------------------------+ +| Calling convention: | HVC64 | ++---------------------+----------+--------------------------------------------------+ +| Function ID: | (uint32) | 0xC6000041 | ++---------------------+----------+----+---------------------------------------------+ +| Arguments: | (uint64) | R1 | selected implementation index | +| +----------+----+---------------------------------------------+ +| | (uint64) | R2 | Reserved / Must be zero | +| +----------+----+---------------------------------------------+ +| | (uint64) | R3 | Reserved / Must be zero | ++---------------------+----------+----+---------------------------------------------+ +| Return Values: | (int64) | R0 | ``SUCCESS (0)`` | +| | | +---------------------------------------------+ +| | | | ``INVALID_PARAMETER (-3)`` | +| +----------+----+---------------------------------------------+ +| | (uint64) | R1 | MIDR_EL1 of the selected implementation | +| +----------+----+---------------------------------------------+ +| | (uint64) | R2 | REVIDR_EL1 of the selected implementation | +| +----------+----+---------------------------------------------+ +| | (uint64) | R3 | AIDR_EL1 of the selected implementation | ++---------------------+----------+----+---------------------------------------------+ diff --git a/Documentation/virt/kvm/devices/arm-vgic-its.rst b/Documentation/virt/kvm/devices/arm-vgic-its.rst index e053124f77c4..0f971f83205a 100644 --- a/Documentation/virt/kvm/devices/arm-vgic-its.rst +++ b/Documentation/virt/kvm/devices/arm-vgic-its.rst @@ -126,7 +126,8 @@ KVM_DEV_ARM_VGIC_GRP_ITS_REGS ITS Restore Sequence: --------------------- -The following ordering must be followed when restoring the GIC and the ITS: +The following ordering must be followed when restoring the GIC, ITS, and +KVM_IRQFD assignments: a) restore all guest memory and create vcpus b) restore all redistributors @@ -139,6 +140,8 @@ d) restore the ITS in the following order: 3. Load the ITS table data (KVM_DEV_ARM_ITS_RESTORE_TABLES) 4. Restore GITS_CTLR +e) restore KVM_IRQFD assignments for MSIs + Then vcpus can be started. ITS Table ABI REV0: diff --git a/Documentation/virt/kvm/devices/arm-vgic-v3.rst b/Documentation/virt/kvm/devices/arm-vgic-v3.rst index 5817edb4e046..e860498b1e35 100644 --- a/Documentation/virt/kvm/devices/arm-vgic-v3.rst +++ b/Documentation/virt/kvm/devices/arm-vgic-v3.rst @@ -291,8 +291,18 @@ Groups: | Aff3 | Aff2 | Aff1 | Aff0 | Errors: - ======= ============================================= -EINVAL vINTID is not multiple of 32 or info field is not VGIC_LEVEL_INFO_LINE_LEVEL ======= ============================================= + + KVM_DEV_ARM_VGIC_GRP_MAINT_IRQ + Attributes: + + The attr field of kvm_device_attr encodes the following values: + + bits: | 31 .... 5 | 4 .... 0 | + values: | RES0 | vINTID | + + The vINTID specifies which interrupt is generated when the vGIC + must generate a maintenance interrupt. This must be a PPI. diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index c56d5f26c750..ae8bce7fecbe 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -196,7 +196,7 @@ writable between reading spte and updating spte. Like below case: The Dirty bit is lost in this case. In order to avoid this kind of issue, we always treat the spte as "volatile" -if it can be updated out of mmu-lock [see spte_has_volatile_bits()]; it means +if it can be updated out of mmu-lock [see spte_needs_atomic_update()]; it means the spte is always atomically updated in this case. 3) flush tlbs due to spte updated @@ -212,7 +212,7 @@ function to update spte (present -> present). Since the spte is "volatile" if it can be updated out of mmu-lock, we always atomically update the spte and the race caused by fast page fault can be avoided. -See the comments in spte_has_volatile_bits() and mmu_spte_update(). +See the comments in spte_needs_atomic_update() and mmu_spte_update(). Lockless Access Tracking: diff --git a/Documentation/wmi/acpi-interface.rst b/Documentation/wmi/acpi-interface.rst index 06fb7fcf4413..f1b28835d23c 100644 --- a/Documentation/wmi/acpi-interface.rst +++ b/Documentation/wmi/acpi-interface.rst @@ -89,6 +89,9 @@ Similar to the ``WExx`` ACPI methods, except that it controls data collection instead of events and thus the last two characters of the ACPI method name are the method ID of the data block to enable/disable. +Those ACPI methods are also called before setting data blocks to match the +behaviour of the Windows driver. + _WED ACPI method ---------------- diff --git a/Documentation/wmi/driver-development-guide.rst b/Documentation/wmi/driver-development-guide.rst index f7e1089a0559..99ef21fc1c1e 100644 --- a/Documentation/wmi/driver-development-guide.rst +++ b/Documentation/wmi/driver-development-guide.rst @@ -96,6 +96,10 @@ on a given machine. Because of this, WMI drivers should use the state container design pattern as described in Documentation/driver-api/driver-model/design-patterns.rst. +.. warning:: Using both GUID-based and non-GUID-based functions for querying WMI data blocks and + handling WMI events simultaneously on the same device is guaranteed to corrupt the + WMI device state and might lead to erratic behaviour. + WMI method drivers ------------------ |